聊聊分布式数据库TDSQL的技术架构

news2024/9/21 4:57:21

大家好，我是飞哥！

咱们很多读者都是在互联网公司工作，大部分同学会有一种认知偏差，总以为互联网的业务对技术的要求是最高的。但其实不然。

比如在对延时的要求上，高频量化交易就比互联网的延迟要求要高得多。在数据库上，银行、证券、电信在这些行业中对数据库的要求也比互联网高得多。拿银行举例，银行的系统里是连一分钱都不能错的，而且即使是十几年前的交易记录也必须能够查出来，对安全性的要求就更不用说了。

在过去很长的一段时间里，这些行业选择数据库基本上就是 Oracle 和 IBM 的天下，各家企业在选型时基本就是 Oracle 和 DB2 之间二选一。但前几天看到 IDC 发布了《中国分布式关系型数据库 2023 年厂商评估》的报告，很高兴看到国内数据库已经发展的非常的好了，老东家腾讯云的 TDSQL 也跻身进了领导者位置，并在国内市场上取得了第一的成绩。

IDC 是全球最顶级的市场研究和咨询机构。它通过大量的数据进行市场分析，对科技行业里的各种技术各家厂商进行分析。为企业提供专业的咨询服务。这家公司的分析报告是非常权威的，在市场中认可度非常的高。

那么什么是分布式数据库，其分布式、强一致性、高可用以及无损升级等特性又是如何实现的呢。今天我们在这篇文中使用 TDSQL 技术架构来进行学习和理解。

传统的 Oracle 和 DB2 都属于传统的单体数据库架构。由于数据的进一步的大规模的增长，这种传统架构出现了不少的弊端。一个弊端就是扩展性问题。单机的性能再强存储再大都不可能承受这些行业里的大规模的存储和计算需求。

虽然可以通过分库分表的方式来一定程度提供扩展性，但这种扩展性对应用不透明。应用需要知道底层的集群、库、表的实现细节，代码写起来很脏，后期也不好维护。另一个弊端是存储和计算没有分离，总有一个资源是浪费的。

另外还有个更重要的原因是漂亮国脾气很不稳定，动不动就封锁咱一下，搞得国内各行各业都担惊受怕。在银行、证券、电信这种支柱型的行业里，数据是容不得出一点差错的。所以近年来，这些行业都在积极地在国内寻找平替产品。

所以数据库行业需要一些国内的产品出来解决以上问题。

在腾讯早在 2002 年的时候，也主要是使用 Mysql 来存储腾讯的计费等数据，但后来由于业务的快速发展，用户量越来越大，增值业务收入规模也越来越大，对可用性的要求水涨船高，就开始自研分布式数据库，大约到了 2012 年的时候 TDSQL 就形成了雏形，在公司内部提供金融级的高一致性、可靠性的服务。

在 2014 年的时候，腾讯系微众银行成立。在做存储技术选型的时候，经过反复的测试验证，发现 TDSQL 已经满足了银行对一致性、可用性的需求。开始采用 TDSQL 作为核心业务的底层存储。

后面公有云蓬勃开始发展的时候，TDSQL 自然就作为腾讯分布式关系型数据库被推向了很多银行、金融机构。截止到 2023 年，在 4000 多家国内的各种金融、公共服务、电信、证券等行业得到了应用，服务了30家金融机构完成核心系统的替换，中国十大银行中七家都应用了 TDSQL。

TDSQL 是一个对应用层透明的分布式数据库。应用可以像使用单机数据库一样简单地使用，不必像分库分表那样关心底层的划分策略。数据库自己内部封装事务、分片、灾备、扩展性等功能。

从这个架构图中可见，用户请求只需要和负载均衡通信即可，完全不用关心数据库底层的实现。

而在架构内部主要是三部分组成，一是管理节点、二是计算节点、三是存储节点。没错，现代的分布式存储都是计算和存储相分离的。这样可以做到可以单独进行扩展。

当有用户请求到来时，负载均衡组件会把请求发送给 SQL 引擎。从用户视角来看，它看到的是一张整体上的表。

SQL 引擎会对用户输入的 sql 语句进行词法、语法解析，还需要处理分布式场景下的全局自增字段等逻辑。然后根据 MetaCluster 中存储的元信息决定将请求发往后面的哪些数据节点。这里要注意的是，用户访问的表实际上是可能被分布在后台的多个 SET 内的，用户对此并不知情。所以 SQL 引擎会向多个数据节点发起请求，各个节点返回后，SQL 引擎进行聚合后返回给用户。

这是分布式数据库的首要目标，对用户屏蔽分布式，只在逻辑上提供整张的表访问，简化用户使用数据库的方式。

由于 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。整个容灾切换机制都无需人为干预，通过这种方式实现高可用。