共计 3108 个字符，预计需要花费 8 分钟才能阅读完成。
TDSQL 的整体架构和外围个性作为金融场景下不可或缺的数据强一致性的保障。咱们将 从四个方面来聊一聊数据一致性的保障：
1. 主备数据复制形式
2. 数据复制比拟：TDSQL 主备数据复制计划 VS MySQL 原生计划
3. 外围性能：容灾切换，数据强统一、0 失落 0 出错
4. 数据强一致性
TDSQL 主备数据复制：高性能强同步
首先在讲数据一致性之前，咱们先理解一下 MySQL 原生的数据复制的形式。
首先第一种是异步复制：主机在不等从机应答间接返回客户端胜利。这个在金融场景是不能承受的，这样的话相当于数据是没有多正本保障。
第二种是半同步：主机在肯定条件下等备机应答，如果等不到备机应答，它还是会返回业务胜利，也就是说它最终还会进化成一个异步的形式，这同样也是金融场景所不能承受的。
除此之外，原生半同步其实是有一个性能方面的缺点，即在跨 IDC 网络抖动的场景下，申请毛刺景象很重大。所以原生的异步复制和半同步复制都存在一些问题，并不能齐全适应金融场景。
TDSQL 引入了基于 raft 协定的强同步复制，主机接管到业务申请后，期待其中一个备机应答胜利后才返回客户端胜利。咱们一主两备下一条业务申请达到了主机之后必须等其中一个备机应答胜利，能力返回客户端胜利，否则这个申请是不会应答的。所以说，强同步是 TDSQL 最根底的一个个性，是 TDSQL 保证数据不会丢、不会错的要害。
讲到这里的话，可能有些同学会问，你们这个强同步其实也不简单，不就是在半同步的根底上把这个超时工夫改成无限大同时应答的备机设置为 1。并不是这样的，TDSQL 强同步这里的要害不是在解决备机应答的问题，而是要解决这种减少了期待备机的机制之后，如何能保障高性能、高可靠性。
换句话说，如果在原生半同步的根底上不革新性能，仅把超时工夫改成无限大的时候，其实跑进去的性能和异步比甚至连异步的一半都达不到。这个在咱们看来也是无奈承受的。相当于为了数据的一致性就义了很大一部分性能。
TDSQL 强同步复制的性能是在原生半同步的根底上做了大量的优化和改良，使得性能根本靠近于异步。
所以这里强同步强调的是，实现强同步的同时还具备高性能个性，所以确切地说是一个高性能的强同步。
那么咱们如何实现高性能的强同步？咱们持续往下看。这里 TDSQL 对 MySQL 主备复制的机制做了革新。首先，咱们先引入了一个线程池的模型。
原生的 MySQL 是——一个互联申请是一个线程，这样对操作系统的资源耗费还是很大的：5 千个连贯，5 千个线程。那 1 万个连贯，1 万个线程，操作系统能扛得住吗？必定扛不住。而且原生的数据复制的形式，其实串行化比拟高，比如说一个用户申请发过来后，等备机应答；这个过程中用户线程在这里是齐全不能做事的，只有等备机应答之后，它才可能返回前端。也就是说大量的线程都处于一个期待的状态，这是半同步效率低的根本原因。
引入了线程池模型之后，咱们还须要思考怎么调度线程池。咱们心愿 MySQL 保护一小部分工作的线程，比如说有 1 万个用户连贯，真正干活的可能就那么 100 个、50 个 MySQL 的工作线程。如果是非工作的线程，他在等 IO 应答时能够先去睡眠，并不让它去影响咱们的吞吐量。所以 TDSQL 对原生的复制做了革新，除了引入线程池模型，还减少了几组自定义的线程。
这个线程是做什么呢？当一笔用户申请过去之后实现了写操作以及刷新了 binlog，第二步他应该要等备机应答。这个时候被咱们新引入的线程组所接管，把这个用户对话保留下来，开释了工作线程，工作线程该干什么持续干什么，解决其余的用户连贯申请。真正备机给了应答之后，再由另外一组线程将它唤醒，回吐到客户端，通知客户端这个应答胜利了。
所以通过这样一个异步化的过程，相当于把之前串行的流程异步化了，这样就达到了靠近于异步复制的性能，这就是 TDSQL 在强同步的革新的外围。所以咱们这里强调不单单是一个实现强同步的过程，更是一个靠近异步性能的强同步。
再看一下革新之后的性能比照：异步 TPS 大略是 6 万左右，均匀时耗小于等于 10 毫秒。再看半同步，显著有三分之二的性能损耗，并且这个时耗稳定还是比拟大的，比如说 IDC 网络抖动一下。强同步一主两备模式下，首先性能曾经靠近于异步的性能，此外时耗并没有额定减少。
因为一主两备，除非两个机房网络同时抖动，否则的话强同步的时耗不会有显著稳定。所以咱们看到基于 TDSQL 的强同步实现了数据的多正本又保障了性能。
有了这个多正本保障，又怎么如何实现故障主动切换，数据不丢不错呢？这其实还是须要一套切换选举的流程。这就引出了 TDSQL 的容灾切换性能。
主动容灾切换：数据强统一、0 失落 0 出错
主动容灾切换在有了强同步个性的根底，就变得非常容易实现了。咱们先看一下这个结构图：
SQL 引擎将申请发给主节点，主节点被两个备机所同步，每个节点上都有对应的 Agent 上报以后节点的状态。这时，主节点产生了故障被 Agent 发觉，上报到 zk 被 Scheduler 捕捉，而后 Scheduler 首先会把这个主节点进行降级，把它变成 Slave。也就是说此时其实整个集群外面全是 Slave，没有主节点。这个时候另外两个存活的备机上报本人最新的 binlog 点，因为有了强同步的保障，另外两个备机其中之一肯定有最新的 binlog，那么两个备机别离上报本人最新的点后，Schedule 就能够分明的晓得哪个节点的数据是最新的，并将这个最新的节点晋升成主节点。
比如说发现 Slave1 的数据是最新的，这个时候 Schedule 批改路由，把主节点设置为 Slave1，实现了主备的切换。有了前述这个切换机制，保障了整个切换无需人为干涉，并且切换前与切换后的数据是完全一致的。这里做一个总结，正是因为强同步的保障，所以当主机产生故障的时候，咱们肯定是能够从一个备节点上找到最新数据，把它提成主节点。这就是 TDSQL 容灾切换的整个过程，容灾切换须要建设在强同步的根底上。
极其场景下的数据一致性保障
聊完了容灾切换，咱们再聊一聊故障节点的后续解决事宜。故障解决可能有几种状况：一种是故障当前，它还能活过来。比如说像机房可能忽然掉电了，掉完电之后它马上又复原。或者机器因为硬件起因不小心产生了重启，重启完之后节点是能够被拉起，被拉起之后，咱们心愿它可能迅速的再退出到集群中，这时数据其实是没有丢没有错的，咱们不心愿把节点故障之后又从新建一份数据，把之前的数据全抹掉。而是从它最初一次同步的数据为断点，持续续传前面的数据。带着上述问题，咱们看一下节点的故障后复原过程。
首先咱们思考一种场景，比如说 A 节点作为主节点，B、C 是从，失常去同步 A 节点的数据，A+1、A+2，接下来该同步 A +3。当 A + 3 还没有同步到从节点的时候产生了故障，这个时候依据 B、C 节点的数据状况，C 的数据是最新的，因而 C 被选成了主节点，进而 C 持续同步数据到 B。过了一阵，A 节点拉起了，能够重新加入集群。重新加入集群之后，发现它有一笔申请 A + 3 还没有来得及被 B、C 节点应答，但曾经写入到日志。这个时候其实 A 节点的数据是有问题的，咱们须要把这个没有被备机确认的 A + 3 的回滚掉，避免它未来再同步给其余的节点。
所以这里强调的是一个数据的回退，相当于每一个 Slave 新退出节点的时候，咱们都会对它的数据进行测验，将多写的数据回滚。当然刚刚的假如是运气比拟好，A 节点还能重启。有些时候 A 节点可能就挂了，这个机器就再也起不来了，咱们须要把这个节点换掉，即换一个新机器，比方：加一个 D 节点。咱们心愿它疾速重建数据并且对当火线上业务尽可能无影响。如何让它疾速去重建呢？当然是基于物理拷贝，而且它是从备机上去拉数据，这样它既不会对主节点产生影响，又可能疾速把数据重建好。
