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

原生分布式，全部都是分布式，没有中心节点管控。
存算分离，计算跟存储完全分离，不在一个服务器上。
数据跟管控完全分离，数据层面完全不参与数据管理。

这些特性直接、简单，却在工程落地时遇到诸多挑战，主要是高性能、高可用、复杂调度三个方面。下面将着重分享我们在高性能、复杂调度方面遇到的挑战。

文章插图

首先是高性能方面的挑战。在架构上，要做到分布式的完全存算分离的架构，MC 作为集群内唯一一个中心的管控模块，必须承担全局授时源角色。

文章插图

在分布式事务的整体架构图中，可以了解到 MC 在事务过程中需要和存储层做网络交互，提供时间戳，这是关键路径。同时 TDSQL 的计算层和存储层都可以灵活扩缩容。存算分离、高扩展的两个特性也意味着 MC 必须要具有非常高的性能。

文章插图

文章插图

在复杂调度层面。我们设计成数据和管控完全分离的架构，数据完全存储在TDStore上，只负责数据流的读写。其他工作完全交由管控层去进行，MC 只需要监控整个集群的状态做出关于存储资源的决策。
TDSQL 在集群管控的探索与实践高性能方面的探索与实践
在高性能方面，我们采用非常经典的三段式协程架构，即一个协程收、处理、最后再发。这种架构在我们突破 60 万时就达到性能瓶颈。

文章插图

通过性能分析，我们意识到性能瓶颈集中在第二个协程里。于是我们将出现瓶颈的地方并行化。但第二个协程增加到一定时，下个瓶颈又出现，因为协程 1 是单管道模式，新的瓶颈点集中在协程 1 。

文章插图

我们在下个版本里做了一个略微复杂的 N 对 N 架构，也是多协程架构。基于此我们发现性能可以提升但 CPU 的消耗非常大。我们的设计目标是 MC 在性能方面有较强的表现，其性能数据能到达 500 万。但当时尽管达到 75 核，数据还是停留在 320 万。我们对此进行 perf 分析，发现问题主要来自 RPC 解析，因为 MC 主要网络框架的实现是基于 GRPC 的网络通讯，会有比较大的头部序列化和反序列化的性能开销。

文章插图

已知性能阻碍存在于网络框架，我们优化的目标就成为摆脱网络框架带来的性能限制。对此我们给时间戳的获取开发了 TCP ROW Socket 通道。因为时间戳数据结构有一个天然优势，即请求无状态、无依赖，只包含两三个整型字段。这时在网络上发来的任何请求，MC 只需要收到一个，回答一个，可以去定制化完成请求。
在弃用该框架后，性能提升飞快，在比较低的 CPU 开端的情况下，可以将性能提升到 450 万。但在后续过程中，我们发现瓶颈出现在请求进队列还有请求出队列的过程中。我们使用 Go Channel 作为消息的进出队列载体，Channel 虽然好用且轻量，但底层依旧带锁实现，push/pull 操作存在着百纳秒级别的开销。

文章插图

对此我们计划实现无锁队列，需要实现单生产者、单消费者模式的场景。基于这种场景，我们实现一个简单的信号量，作为两者之间的唤醒机制。使用该优化方案后，资源的消耗明显降低且达到更高的性能，峰值吞吐突破 750 万。

文章插图

最初 500 万的目标虽已完成，但我们团队仍认为性能数据还可以更好。以下为经典的 CPU 缓存的 MESI 状态转换图。一行 CPU 的 Cache Line 可以容纳 64 个字节，在我们的数据结构中，将其中多个 8 字节的变量放在同一个缓存，如果一个更新非常多，另一个更新的少，就会影响另一个原子变量的读写。从图片右边可知，在这里把变量的 8 字节对齐后，就解决 CPU 缓存行的问题，性能数据也从 750 万上升至 920 万。此时我们的目标是实现单中心的千万级别的性能数据。