和一群技术爱好者聊聊分布式，结果......

近期，2022 WOT全球技术创新大会在北京圆满落幕。今年的WOT大会是51CTO为中国技术社区精心打造的WOT 2.0升级版，纵览全球最新技术趋势，紧跟国家重点技术战略方向，邀请各行业顶尖技术领袖把脉未来，深度分享独家技术干货。

随着云计算时代的到来，越来越多的行业正面临新型企业级信息化以及快速实现国产化的转型升级需求。凭借高性能、可扩展、高可用等特性，分布式数据库正在成为各行业数字化转型的重要支撑。腾讯云数据库专家团携企业级分布式数据库TDSQL亮相WOT《分布式数据库前沿技术》专场，分享腾讯云数据库在分布式数据库前沿技术方面的一些探索实践。

金融级分布式数据库一致性技术及应用实践

腾讯云数据库专家架构师，汪泗龙

好的架构设计能够帮助分布式数据库在使用过程中展现出更高的性能。在分享分布式事务和分布式事务一致性之前，汪泗龙先为大家解答了事务究竟要解决哪些问题。他认为事务要解决的问题主要有两点，一是保证数据的正确性；二是提高并发效率。二者同样关键，不存在为了提高并发效率而牺牲数据正确性的情况，反之亦然。

分布式数据库不仅要解决分布式事务的问题，还要解决全局写读冲突，从而实现全局的一致性读，汪泗龙接着为大家详细介绍了TDSQL实现全局一致性读的具体方案。

具体来看，汪泗龙重点介绍了MC的工作原理，MC是TDSQL自研的轻量化GTM，负责生成一个全局的唯一序列，支持插件式部署。以两个SET插入的事务模型为例，相对于普通的TDSQL两阶段事务只多了两次和MC之间的交互，其他流程保持一致。

当TDSQL发起一个分布式事务，在CLIENT发起插入后，这里会再加入一个阶段，获取全局最大的GTS作为事务开启的标志，这时再带着MAX_GTS发起插入。当插入成功后，GTS也会写入到全局XID_LOG里。GTS是标识的全局唯一序列，XID是唯一标识全局事务的标签，两者相互独立。在COMMIT发起后进入两阶段提交，此时需要对PREPARE阶段进行判定，通过XID_LOG日志来作为全局提交成功的标识。

在PREPARE成功后，PROXY和MC会进行第二次交互，生成COMMIT_GTS，也会写到全局XID_LOG里，同时会伴随事务的COMMIT写入到TDSQL REDO日志中。相对于XA的START和COMMIT，TDSQL为了实现全局的MVCC特性，改写了XA的语法，增加部分关键词，同时对内核做了微量调整。

汪泗龙提到在该方案中，数据库和MC的通信量非常少，整个过程中基本只有两次非常轻量的通信，某些场景下当TDSQL进行一个不涉及两分片的事务时，比如说只涉及一个分片，则会对第二次获取COMMIT_GTS进行优化，进一步减少和MC通信。简言之，TDSQL实现分布式事务和分布式全局一致性的方案，是把INNODB自身的MVCC和全局GTS进行全局映射，从而实现全局轻量级的GTM+全局的MVCC。

MC提供全局时间戳服务，可以支撑千万级TPS，支持集群级别部署模式，也支持实例级别部署模式，客户可以按需做选择配置。同时，它的吞吐量是远高于数据库实例的，不会成为系统瓶颈。

此外，汪泗龙基于TDSQL在真实场景中的应用，介绍了分布式事务和一致性极限优化的场景。点击观看视频，完整获取讲师分享内容吧！

分布式数据库在金融敏态业务的技术探索与实践

腾讯云数据库高级工程师，韩硕

在TDSQL升级版引擎中，一个最重要的特性就是能够做到对业务无感知的扩缩容，扩容期间对于业务请求几乎无性能抖动。韩硕概括道，存储节点的扩缩容流程是通过执行管控节点下发的分裂、合并、迁移、切主等任务来完成的。

韩硕以扩容为例，介绍了TDSQL升级版引擎实现对业务无感知扩缩容的技术细节。管控节点TDMetaCluster首先会向region副本所在的存储节点TDStore下发分裂任务，将数据量超过阈值的region一分为二。其中分裂点的计算需要考虑尽可能将数据量以及数据的读写热点分裂均衡。整个分裂流程也遵循两阶段提交，MC作为协调者，region的所有副本作为参与者，保持全员成功或者失败，避免部分副本分裂成功部分失败的半提交状态。

分裂过程是对region所管辖的数据范围元信息进行变更，而数据的分布并无变化。也就是说，分裂只能够让每个TDStore节点上的region数量增加，region变得更均匀。要想达到水平扩展的效果则需要接下来的迁移任务，韩硕老师也详细分享了迁移任务实现的具体流程。

迁移任务通过raft协议的增减副本逻辑来完成，首先向新增的TDStore节点上创建一个空的region新副本，空的region副本会触发快照装载（install snapshot）流程，从leader副本上生成并传输快照数据（snapshot data）过来，形成临时的有序SST数据文件，然后将这些临时SST数据文件插入到新增的TDStore节点的LSM-tree的合适位置，从而完成数据的迁移。最后再选取一个旧的region副本进行删除。迁移任务实现了数据以region副本的形式在新旧TDStore节点之间的自动均衡，即存储节点集群的水平扩容。

事务读写请求是由leader副本来承担的，follower副本只负责遵循raft协议来同步leader副本上接收的数据，从而达到多副本间的数据一致性。也就是说对于同一个region副本而言，其leader上的计算开销和IO开销通常是大于follower的。因此我们对每个region不同角色的副本的开销负担进行统计预估，然后通过下发切主任务，让开销热度较大的leader副本尽量均匀分布在不同的TDStore节点上，将热度打散，从而达到负载均衡。

韩硕重点强调了在扩缩容期间做到对业务无感知的关键在于要做到region调度与事务的并发。也就是说，上述region调度任务在执行的同时，不能阻塞事务的正常执行。以分裂任务为例，简单来讲，在分裂过程中我们需要将分裂前副本上活跃事务的相关上下文信息进行相应的分裂，然后将属于分裂后新region的事务上下文信息传输过去，如下图所示。

而被分裂的事务，也相应增加了一个参与者（即新分裂出的region）。由于region的分裂动作对于上层的SQLEngine是无感知的，那么在事务的两阶段提交流程中，SQLEngine向TDStore上的协调者region发送prepare请求时，就必须相应地更新事务的参与者列表，从而保证新增的参与者上的事务数据一起提交落盘。

此外，韩硕还介绍了TDSQL升级版分布式事务的实现原理、优化方案等。点击观看视频，完整获取讲师分享内容吧！

TDSQL PG版分布式数据库在HTAP场景的设计与探索

腾讯云数据库高级工程师，吕夫洋

吕夫洋从事务一致性设计演进的角度，为大家展示从 PG 到 PGXC、PGXL，再到 TDSQL PG 版事务一致性的设计与实现。

在PostgreSQL单机事务中，存储事务 ID(‘Xid’)作为全局事务唯一标识符。PostgreSQL 使用事务快照来保证正确的全局多版本可见性，事务快照记录全局当前事务状态，保留还在运行的活跃事务链表。其中，全局最小活跃事务 ID 标志着在全局最小活跃事务 ID 之前已经发生过的事务，不管提交还是回滚，事务的结果都是可见的；而下一个未使用的事务 ID 意味着在此事务 ID 之后都是在获得这个快照时还没有发生的事务，后面事务的内容及结果都是不可见的。

PGXL 分布式事务把多个PG实例以不同的角色，组织成了基于PostgreSQL的MPP分布式集群。此时，PGXL需要处理全局所有节点的事务状态。PGXL提供了一个比较基础的分布式事务原型，但设计中存在资源消耗过大、吞吐量扩展性差等性能问题。

基于以上事务一致性的探索，TDSQL PG 版选择使用全局时钟机制，即 GTM 维护并提供全局统一时间戳 GlobalTimestamp(“GTS”)破局。具体来看，逻辑时钟从零开始内部单向递增且唯一，由 GTM 维护，定时和服务器硬件计数器对齐；硬件保证时钟源稳定度；同时多个 GTM 节点构成集群，主节点对外提供服务；主备之间通过日志同步时间戳状态，保证 GTS 核心服务可靠性。

除此之外，GTM 不再维护全局事务状态，每个实例维护自身事务 ID，而 跨节点两阶段事务维护事务对应不同节点事务 ID 的映射关系，从而解决 GTM 吞吐量的扩展性问题。

在一个HTAP系统中，衡量HTAP架构的好坏，除了TP业务、AP业务吞吐量的标准之外，还有TP业务和AP业务的扩展性。除此之外，吕夫洋还提到了两个重要的标准，一个是TP业务和AP业务之间资源隔离的程度，二是AP业务能够处理的数据的新鲜度。

如何做到资源隔离，让 AP 和 TP 业务之间互不影响，或者尽量减少AP业务和TP业务之间的影响，是一个很关键的问题。吕夫洋为大家介绍了多平面读写分离的解决方案。对每个节点来说，不管是 CN 还是 DN 都是有备机的，而且一般在生产环境中是一主多备。这样每个集群中的每个节点都可以在管控的界面中选择同步备节点，组成一个只读的平面。这样业务就可以选择刚创建的只读平面来承接一些只读的负载，例如正常在主平面上承载的 TP 高并发操作以及短周期的事务，在只读平面上可以承接一些比较复杂的 query 查询，提供 AP 的业务能力。这样就可以达成一个 TP、AP 之间比较小的资源冲突和抢占，从而实现比较完整的 TP 和 AP 之间的资源隔离。

此外，吕夫洋详细介绍了各阶段方案的技术实现细节。点击观看视频，完整获取讲师分享内容吧！

﹀

﹀

﹀

-- 更多精彩 --

金融数字化转型落地实践，腾讯云数据库的三问三答

干货！分布式数据库在金融核心场景的落地实践

↓↓点击阅读原文，了解更多优惠