为帮助开发者更好地了解和学习分布式数据库技术，2020年3月，腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙《你想了解的国产数据库秘密，都在这！》，邀请数十位鹅厂资深数据库专家每周二和周四晚上在线深入解读TDSQL、CynosDB/CDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践等。三月为TDSQL专题月，本文将带来直播回顾第二篇《破解分布式数据库的高可用难题：TDSQL高可用方案实现》。

大家好，今天我分享的主题是TDSQL多地多中心高可用方案。TDSQL是腾讯推出的金融级分布式数据库。在可用性和数据一致性方面，基于自主研发的强同步复制协议，在保证数据的跨IDC双副本的同时，具备较高的性能。在强同步复制的基础上，TDSQL又实现了一套自动化容灾切换方案，保证切换前后数据零丢失，为业务提供7×24小时连续高可用服务。

事实上，不光是数据库，任何对可用性有较高要求的系统都需要具备高可用的部署架构。这里面会涉及到一些专业术语如：异地、多活、双活、选举等，今天的分享中都会讲到，除此之外还包括我们耳熟能详的两地三中心、两地四中心、同城双活等概念。值得一提的是，今天这次分享不光是对数据库，对任何高可用系统的部署架构都具有参考借鉴的意义。

本次分享我们会介绍TDSQL的几种典型部署架构，以及各种架构的优缺点。因为在实际生产实践中，会有各种各样的资源条件限制，比如同城有一个机房和有两个机房的容灾效果就完全不一样。再比如虽然有两个机房，但是这两个机房的规格相差比较大，有的机房可能网络链路比较好，而有的机房可能网络链路比较差，等等…所以，如何在有限的资源条件下搭建一套性价比高或者说效能比高TDSQL，是我们这次分享要探讨的主要内容。

在正式切入正题前，我们先回顾一下上一次分享有关TDSQL的核心特性以及整体架构。

好，接下来我们先看一下TDSQL核心特性。

我们今天的重点聚焦在“金融级高可用”上。TDSQL如何做到99.999%以上的可用性呢？所谓五个九的高可用意味着的是，全年不可用时间不可超过5分钟。我们知道，故障是一种无法避免的现象，同时故障也是分级的，从软件故障，操作系统故障，再到机器重启、机架掉电这是一个灾难级别从低到高的过程，对于金融级数据库需要考虑和应对更高级别的故障场景，如：整个机房掉电甚至机房所在的城市发生地震、爆炸等自然灾害。如果发生这类故障，我们的系统首先能否保证数据不丢，其次在保证数据不丢的前提下需要多久恢复服务，这都是金融级高可用数据库需要考虑的问题。

TDSQL数据库一致性：强同步机制是最核心的保障

首先，我们回顾一下TDSQL的关键特性—强同步机制，它是TDSQL保证数据不会丢、不会错的关键，并且相比于MySQL的半同步复制，TDSQL强同步复制的性能更是接近于异步

那么这个高性能强同步是如何工作的呢？强同步复制要求任何一笔应答业务成功的请求，除了在主机落盘成功以外，还需在至少一个备机落盘成功。所以我们看到，一个请求到了主机之后，立刻发送发给备机，当两台备机中的一台应答成功之后主机才能应答业务成功。也就是说任何成功应答给前端业务的请求一定会有两个副本，一份在主节点上，另外一份在备节点上。所以，强同步是数据多副本的关键性保障。TDSQL通过引入了线程池模型与灵活的调度机制，将工作线程异步化，实现了对强同步的性能大幅提升，改造后其吞吐量接近于异步。

第三部分，开始切入我们的正题，这一章我们将介绍比较典型的几种部署方案，那些耳熟能详的名词：同城三中心，两地三中心，异地多活，同城双活分别代表什么意义，或者说能带来什么样的效果呢。接下来就为大家一一将这些问题的答案揭开。

l “同城三中心”架构

第一部分是同城三中心架构。同城三中心顾名思义：在一个城市有A、B、C三个机房，TDSQL仍采用“一主两备”结构，很显然我们需要将三个数据节点分别部署在三个机房，其中主节点在一个机房，两个备节点分别部署在另外两个机房。

每个IDC提供两台高可用的LV5做负载均衡系统。为什么每台IDC都要放一个LV5？因为每个IDC有自己的业务，对应都需要有一个独立的负载接入。从接入层看三个机房是一个相对平行的对等架构，三个机房都放了自身的业务，可能第一个机房支撑的是一个全国大区的业务，第二个机房是另外一个大区，对等就是这样的含义。这种架构比较简单，整体也比较清晰。

这个图里面没有画出管理节点，我们刚刚也说了管理节点可以看做整个集群的大脑，负责判断当前的全局态势。三个机房很明显需要部署三颗大脑，之所以是“三”刚刚也讲过，当其中一个大脑出问题的时候，另外两个可以形成多数派，完成相互投票确认将故障大脑踢除。

“同城单中心”架构

“同城单中心”架构的场景有几种情况：

第一种场景是IDC资源比较紧张，只有一个数据中心。这种场景下做不到跨机房部署，只能按照跨机架方式部署，当主节点故障或者主节点所在的机架故障，能够自动切换。

第二种场景是业务追求极致的性能，甚至不能容忍跨IDC网络延迟。虽然现在的机房之间都是光纤网络，相隔50km的两个机房之间的网络延迟也只有不到1ms。但有些特殊的业务甚至无法忍受1毫秒的延迟。这种情况下我们只能将主备部署在同一机房。

第三类是作为异地灾备机房。作为灾备储存一般也没有实际业务访问，更多的可能是做备份归档，因此对它的资源投入比较有限。

第四种是作为测试环境，这个就不多说了。

“两地三中心”架构

接下来跟大家聊一聊这次分享的主角——“两地三中心”架构，它是银行常见的部署方式，更是监管要求的基本部署架构。这种架构通过同城两个数据中心加异地一个数据中心，在较低的成本下，提供较好的可用性和数据一致性。在节点异常、IDC异常都能做到自动切换，非常适合金融场景，是TDSQL重点推荐的部署方式。

部署方式方面，我们从上往下看，分别是同城两个机房和异地一个灾备机房。最上层是集群的大脑管理模块，分别跨三个机房部署。

管理模块的部署可以采用“2+2+1”也可以“1+1+1”的方式。我们知道，如果按照“2+2+1”的部署方式，当第一个机房故障时，还剩下“2+1”颗大脑，“2+1”比5的一半要多，剩下的“2+1”形成多数派将故障节点踢掉，同时继续提供服务。

继续往下看，我们看到数据节点采用的是“一主三备”的模式，并且是跨机房强同步，同机房异步。为什么同机房这里是异步，不能做强同步？如果同机房是强同步的话，由于它和主节点距离上要比另外两个跨机房的备节点近（IDC1、IDC2之间相隔了平均至少50公里），业务每次发送给主节点的请求都是这个同机房的强同步节点率先应答，最新的数据永远都只会落到同机房的备节点。而我们希望数据的两个副本应该位于相隔50km以上的不同机房，这样才能保证跨机房主备切换时数据能够保持一致。

可能有人会问，这个 IDC1 配置的异步节点和不放没有区别。这里解释一下为什么有了这个异步节点后更好呢。我们考虑一种情况，当备机房IDC2 发生了故障，备机房里面的两个节点全部宕机，IDC 1 这里的master节点就成单点了。此时，如果开启强同步，由于没有备机应答，主节点依然无办法提供服务；但如果关闭强同步继续提供服务，数据存在单点风险，如果这时主节点发生软件硬件故障，数据就再也无法找回。一个比较好的方案是：给IDC1增加了一个跨机架的异步节点，当IDC2挂掉之后，这个异步节点会提升为强同步。这样在只剩下一个机房的前提下，我们仍然能够保证一个跨机架的副本，降低主机的单点风险。

看完主城两个机房，我们再看看异地灾备机房。作为异地灾备机房，一般是和主节点相隔500公里以上，延迟在10ms以上的机房。在这样的网络条件下，灾备节点和主城之间只能采用异步复制的方式同步数据，因而异地灾备节点承担的更多是备份的职责，日常不会有太多正式业务访问。虽然表面上看有点花瓶，没有它却也万万不行。假如有一天发生了城市级别故障，灾备实例仍可以为我们挽回99%以上的数据。正是由于灾备节点和主节点的这种异步弱关系，才允许我们的灾备实例在备城是一个独立部署的单元。

异地灾备机房除了作为异步数据备份外，另外一个重要的职责是：当主城的一个机房故障，通过和主城另外一个正常的机房形成多数派，将故障机房踢掉进而完成主备切换。部署在异地的这个大脑，在大部分时间都不参与主城的事宜，只有在主城的一个机房发生故障时才介入。正常情况下，主城的模块访问主城的大脑，备城的模块访问备城的大脑，不会交叉访问导致延迟过高的问题。

“两中心”架构

聊完“三中心”，我们再来聊聊“两中心”架构。具体来说，同城只有两个机房，根据我们上一个PPT的经验，在两机房部署TDSQL需要按照同机房异步，跨机房强同步的方式部署。因而采用四节点的模式，分布式在2个IDC。

然而“两中心”架构有个需要权衡的地方是，只有部署在备机房而且故障的不是备中心，才能实现自动跨IDC容灾。但如果是备中心故障，事实上，在同机房异步，跨机房强同步的方式下，不管是部署在主机房还是备机房，假如发生故障，无法顺利完成多数派选举以及自动故障切换，要么强同步节点无法被提升形成多数派，要么多数派随机房故障而故障，需要人工介入。因而在高可用要求的场景下，一般更为推荐“两地三中心”等7*24小时高可用部署架构。

标准化高可用部署方案总结

最后我们总结一下今天的分享：

● 首先，对于跨城市容灾一般建议在异地搭建独立的集群模式，通过异步复制实现同步。主城和备成可以采用不同的部署方式，如主城一主三备，备城一主一备的方式灵活自由组合。

● 现网运营的最佳方案是同城三中心加一个异地灾备中心，其次是金融行业标准的两地三中心的架构。这两种架构都能轻松实现数据中心异常自动切换。

● 如果只有两个数据中心，做不到任意数据中心异常都能自动切换，需要一些权衡。

不光是对于数据库系统，任何做一种高可用系统都需要做基于部署架构方面的考量，这就是本次分享的全部，谢谢大家。

Q&A

Q：同城主备切换一次多长时间？

A：30秒以内。

Q：两地三中心的主城是不是设置成级联？

A：这个问题非常好，如果从主城的视角看，这显然是一个级联关系，数据先由主城的master同步到主城的slave，再通过主城的slave同步到备城的master，一层层向下传递数据。

Q：请教一下强同步会等SQL回放吗？

A：不会等，只要IO线程拉到数据即可。因为基于行格式的binlog是具备幂等写的，我们通过大量的案例证明它是可靠的。此外，增加了apply反而会使得平均时耗的上升和吞吐量的下降。最后，假如apply有问题，TDSQL的监控平台会立刻识别并告警，提醒DBA确认处理。

Q：备机只存binlog不回放，性能上跟得上主吗？

A：备机拉取binlog和回放binlog是两组不同的线程，分别叫IO线程和SQL线程，并且两组线程互不干扰。IO线程只负责到master上下载binlog，SQL线程只回放拉取到本地的binlog。上一个问题说的是强同步机制不等待回放，并不是说到备机的binlog不会被回放。

Q：同城三中心写存储节点都在IDC1，那么在IDC2的业务延迟是不是很大？

A：同城机房现在都是光纤传输，时耗基本都是做到1毫秒以下，完全没必要担心这种访问时耗。当然，如果机房设施比较陈旧，或者相隔距离间的网络链路极为不稳定，为了追求卓越性能可能需要牺牲一部分容灾能力。

Q：一主两备，SQL引擎做成故障切换有VIP方式吗？

A：当然有，多个SQL引擎绑定负载均衡设备，业务通过VIP方式访问TDSQL，当SQL引擎故障后负载均衡会自动将其踢掉。

Q：这样不是三个业务各自写一个库吗？

A：不是的，三个业务都写到主库。SQL引擎都会路由到主库，一主两备。TDSQL强调任何一个时刻只有一个主提供服务，备机只提供读服务不提供写服务。

Q：同城多副本，多SET对同城IDC之间网络要求有什么？

A：5毫秒以内的延迟。

Q：如果两个强同步主从可以设置其中一个返回？

A：TDSQL强同步默认机制就是等待一台强同步的备机应答。

Q：中间一个节点挂了，异地节点会不会自动连接到主节点？

A：当然会。

Q：强同步和半同步复制相比的优势是什么？

A：强同步跟半同步复制相比，最直观的理解可能有人会问，强同步不就是把半同步的超时时间改成无限吗？其实不是这样的，TDSQL强同步这里的关键不是在解决备机应答的问题，而是要解决这种增加了等待备机的机制之后，如何能保证高性能、高可靠性。换句话说，如果在原生半同步的基础上不改造性能，仅把超时时间改成无限大的时候，其实跑出来的性能和异步比甚至连异步的一半都达不到。这个在我们看来也是无法接受的。相当于为了数据的一致性牺牲了很大一部分性能。

TDSQL强同步复制的性能是在原生半同步的基础上做了大量的优化和改进，使得性能基本接近于异步，并且能实现数据零丢失——多副本，这是DSQL强同步的一个特点。上一期的直播我们介绍了，TDSQL如何实现高性能强同步的。比如经过一系列的线程异步化，并且引入了线程池模型，并增加一个线程调度的优化等。

Q：仲裁协议用的哪一个？

A：多数派选举。

好的，如果后续有其他问题的话，欢迎在我们技术交流群里面沟通，今天的直播到这里就结束了，再见。谢谢大家！