聊聊分布式数据库TDSQL的技术架构( 二 ) _数据库

这是分布式数据库的首要目标，对用户屏蔽分布式，只在逻辑上提供整张的表访问，简化用户使用数据库的方式。
由于 SQL 引擎只负责计算，不负责存储，本身是无状态的。该节点只需要重点关注 CPU 和内存相关的性能优化即可。在硬件上，也可以选择计算型的硬件。
SET 是分布式数据库实例。一个 SET 内部包含了 Master、Slave 节点。每个 SET 中存储哪些数据是由 shardkey 来进行分散的。在数据接入的时候，TDSQL 采用 raft 协议的强同步复制， Master 接收到业务请求后，等待其中一个 Slave 应答成功后才会返回成功，否则不返回。通过这种方式实现强一致性。
在每个节点内部，都包含一个 Agent 和具体的 Mysql 实例。这种架构有点类似于微服务中 Mesh 架构中用 Sidecar 把微服务框架功能独立出来一样。Agent 和存储解耦，好处是 Agent 可以监控并上报 Mysql 的状态，而且系统升级的时候，也可以单独升级和重启 Agent，而不用重启 Mysql 进程，可以做到无损升级。
如果 Master 节点发生故障，它的 Agent 会上报它的异常给 MetaServer 。接着 Master 会降级成为 Slave 。再从剩下的 Slave 中选举一个出来作为 Master 。后面的请求就会发送给新的 Master 。整个容灾切换机制都无需人为干预，通过这种方式实现高可用。

文章插图
图片
以上就是 TDSQL 的强一致性、无损升级、高可用在架构上实现的原理。
另外还有一个我觉得在 TDSQL 中比较值得学习的一个点是它的扁鹊智能化 DBA 平台。我们大家在做自己的系统时也可以借鉴这个思路实现自己系统的高效运维。
当集群规模大了之后，必然会出现各种各样的问题。比如网络异常发生、SSD 衰老，如果这些问题全部依赖人工去排查和处理，效率太低了。而且未来分布式系统的规模会越来越大，所以人工维护必然需要被代替。以下是 TDSQL 的扁鹊平台架构。

文章插图
图片
DBA 靠这个平台可以发现各种集群中运行的问题。比如差 SQL、扩容异常、锁分析等等各种日常运维工作。更高效率的运维也是实现高可用的另一个关键要素。
最后，再次恭喜 TDSQL 登录中国分布式关系型数据库“领导者”类别，这份来自业界的高度评价十分难得。相信国产数据库未来一定会越来越强！