企业级分布式数据库 TDSQL 元数据管控与集群调度( 三 ) _分布式数据库

文章插图

为了进一步实现单中心的千万级别的性能数据，我们从业务场景进一步深挖。在整个集群中，MC 在时间戳方面是单一的提供者，而集群中众多的计算节点和存储节点会产生源源不断的请求，因此在分析生产者和消费者速度时，我们发现生产者速度远远跟不上消费者速度。为此我们进行了简单的改造，即来一批请求再消费一批时间戳，以批量请求方式去唤醒消费者。为了适应业务场景，我们还对该优化做了开关，运维人员可以根据业务场景的需求进行调节。执行批量化操作后，整体峰值已经提升至两千万，许多数据库实例的业务场景都无法到达这种高压力。

文章插图

下图为 TDSQL 原生数据库下，我们通过一系列优化手段达到 2000 万性能数据的过程。

文章插图

复杂调度方面的探索与实践由于实现数据面与管控面的分离，MC 要负责整个集群所有跟资源相关的管控。如图所示，图中画有 MC 的主要功能。
MC 需要负责时间戳的提供，管理全局的唯一 ID 的分配、DDL 的协调、计算层管控层资源的元数据以及数据分片的管理。在管控层的不同层面，所有跟管理调度相关的工作都集中在 MC。

文章插图

文章插图

为了实现复杂调度，我们首先划分资源层级，制定可用的具有可扩展性的基础框架，将 MC 模块从管理任务中释放。将每个资源层级必须划分清楚，使得数据路径上的所有模块只需要被动执行，不需要更新状态。我们从集群层面、复制组层面和副本层面进行划分，划分出许多子状态及子步骤。
比如在扩容过程中，有一个数据分片，副本分布在 123 三个存储节点中，如果要进行数据迁移使得一主两备变为 1234 分布，任意时刻这四个节点都知道自己要做的原子子步骤，整个迁移过程实现零感知。
迁移过程包含五个原子子步骤：先在节点 4 上创建新部分，再将新部分加入到原本的数据复制同步组中，去掉的副本的状态设置为 off line，最后再把该副本删除。在分布式数据库中随时可能有节点挂掉，但通过步骤划分，无论是 MC 挂掉还是 TDStore 挂掉，节点拉起来后都知道要如何操作。通过这样的机制，存储层对每个任务的推进或回滚完全无感知，全部由 MC 来做协调。

文章插图

该机制主要有以下三方面的效果：
首先是性能。该机制对性能提升的促进非常显著，在集群比较大时可以轻松支持 EB 级存储。比如在 500 万数据分片的量级下，MC 用 20 个核就能完全支持。通过数据状态与调度状态的分离，大大降低了 MC 负载。性能上的收益还体现在存储层上。在任意时刻它只需要接收到一个原子步骤即可。因此在代码层面，存储层不需要任何关注数据资源状态的代码，更有利于进行性能优化。
其次是健壮性。每个任务都是有限的状态机，任意一个参与者，如管控或存储，出现交互中断，都能够以确定方式进行任务的回滚或恢复。
最后是可扩展性。每个管控任务分为多个原子步骤进行，有利于以插件式方式去定义其他更多更复杂的任务。整个过程中只需要将原子步骤拼装组合，MC 就可以实现复杂调度。

文章插图

数据分布方面的探索与实践原始版本中，MC 对数据分布管理只有物理位置概念，基于扩展引擎和分布式协议打造的 KV 存储引擎，数据分片在整个分布式存储集群中按照主键从空到正无穷的字符序来进行分布。比如创建表或二级索引时，如果要表达成 KV 形式，主键和二级索引都有对应的 ID。存储层中以 Key 区间代表一个数据分片，如 01-02 数据分片，落在存储节点 1 上，02-03 数据分片，落到存储节点 2 上。这种情况下，同一张表的数据的主键和二级索引会落在不同的 TDStore 上，这就会造成很大的负面影响。
举个例子，有一张表，每天有大量不同的流水写入，有三亿行数据，业务为方便查询，做了 20 个索引。在最坏的情况下，20 个索引分别落在不同的 Region，又落在了不同的 TDStore。数据库使用者从操作上更新了一行，但可能会发展成 20 个涉及到 60 个参与者的分布式事务，带来 60 次同步的性能损耗。在这种情况下，我们针对经常出现的业务场景对两阶段提交进行优化，让更多的提交变成一阶段提交。