TDSQL简介_原创精品文档.pdfVIP

TDSQL(TitanDistributeSQL)—一种分布式数

据库之容灾篇

一、传统的分库分表及由此引入的问题

由于业务数据量巨大以至于无法单表存储，于是，我们习惯了分库分表的方

式。最常用的莫过于按照QQ号的后三位分1000表，除此之外，还有按照大区

分表，按照时间分表，等等。于是我们习惯了下面这样一种SVR与DB交互的

架构结构。

图1—传统的分库分表存储

这个我们习以为常的数据库存储结构，其实包含了一些问题，本篇将主要讨

论主备一致性切换问题，并给出TDSQL主备切换的方式。问题如下：

1、主备的异步同步，在主机宕机的情况下，无法保证数据已经同步到了备

机。

2、人工切换，则对DBA同学的实时处理提出非常高的要求。

3、自动切换，可能出现不同SVR对于主DB的健康状态判断不一致，造成

不同SVR把数据写入到不同DB的情况即——脑裂。

4、即使通过仲裁节点来统一调度SVR连向主DB或者备DB，如果流程处

理的不好，也可能因为SVR感知切换的时间差在短时间内造成脑裂。

如何解决上面的问题，业界给出了很多的方案，例如国外有Galera这种通

过协议插件来实现一致性的方案（但这种方案在跨IDC时的性能非常差），国

内也有阿里RDS，TDDL，360的atlas中间件，但上述的方案要么在主备切换

的一致性，要么在主动切换，要么在性能上都会有或多或少的问题，因此我们在

参考上述方案的基础上实现了今天要给大家介绍的方案TitanDistributeSQL

—TDSQL。

二、TDSQL主备切换方案

2.1TDSQL容灾架构

图二、TDSQL容灾架构

图二是一个大家熟悉的具备调度能力的分布式集群，下面分别来介绍一个各

个模块的作用及如何互动。

DB——图中的绿色部分，是集群的核心部分，也就是mysql节点。为了实

现主备的强一致性和较高的性能，这里必须使用我们在Mariadb基础上进行二

次开发的MySQL。注意，只有主DB提供写服务，其它DB会被Agent自动设

置成只读。

Agent——监控模块，Agent监控MySQL节点的健康状况，并上报心跳

给Scheduler。

Node——每个MySQL进程和Agent要一起部署，二者组合在一起得到

一个最小的存储控制单元Node。

SET——为了实现容灾，通常使用一主N备个节点来组成一个最小的容灾存

储单元，主Node和备Node存储的数据一致，通过后面介绍的强同步来同步

数据。为了实现跨IDC容灾，不同的Node节点需要部署在不同的IDC。

Scheduler——调度模块，Scheduler接收Agent的请求，并判断该DB

是否宕机，如果宕机时间超过阀值，则会触发容灾流程。

Proxy——业务请求分发模块，其实是一个MySQL代理，适配MySQL协

议，并把请求发送到后端的。

Zookeeper——一个开源的一致性存储集群，在TDSQL架构中，所有控

制节点通过Zookeeper进行交互。

2.2TDSQL各个控制模块的容灾

1、Agent—Agent挂掉存在两种情况：

1、整个物理机器出现类似掉电的情况，在这种情况下是要做Node节

点的主备切换的，这个时候Agent在Zookeeper创建的心跳节点（一个

z