破解分布式数据库的高可用难题：TDSQL高可用方案实现

腾讯云数据库 TencentDB • 2023-01-02 • 云技术社区 • 264 阅读

腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中，3月12日张文的分享已经结束，没来得及参与的小伙伴不用担心，以下就是直播的视频和文字回顾。

关注“腾讯云数据库”公众号，回复“0312张文”，即可下载直播分享PPT。

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

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

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

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

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

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

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

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

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

看完强同步，我们接下来再回顾一下TDSQL的核心架构。负载均衡是业务的入口，业务请求经过负载均衡到达SQL引擎模块，SQL引擎再将SQL转发到后端数据节点。图中的上半部分是集群的管理调度模块，作为集群的总控制器承担着资源管理、故障调度等工作。所以，TDSQL整体分为：计算层、数据存储层，以及集群管理节点。集群管理节点我们之前强调过，一个集群部署一套就行，一般是3个、5个、7个这样的奇数个部署。为什么是奇数呢？因为当发生灾难的时候，奇数个能够形成选举，话句话说，比如3个节点部署在3个机房，其中有1个机房故障的话，而另外两个机房可以互通并且都连不上第三个机房，就可以对第三个机房故障达成共识将其踢除。我们可以把三个机房的管理模块理解为集群的三颗大脑，这组大脑坏掉一个后，如果剩余的大脑能够在数量上达到初始数量的一半就可以继续提供服务反之则不行。

二、高可用集群的部署实践

以上是对TDSQL一些核心特性的回顾，接下来我们看一下各个模块在机型上的选择。对于计算与存储相分离的分布式架构数据库，我们该如何选择机器？我们知道，要想让一个IT系统发挥出最大的价值，就是要尽可能地榨干机器的资源，让这些资源物有所值效能比高。如果这个机器CPU跑得很满，但是IO没有什么负载，或者说内存配128个G但实际上只用了2个G。这种就属于效能比非常低的部署，无法发挥出机器以及系统的整体性能。

首先是LVS模块，首先作为接入层它不是一个TDSQL的内部组件，TDSQL的SQL引擎兼容不同的负载均衡，比如软件负载LVS、硬件负载L5等。作为接入层的负载均衡一般都是CPU集型服务，因为它需要维护管理大量链接请求，相对较为耗CPU和内存。所以这里推荐的配置中CPU比较高，16vCPU，32G内存，一定是万兆网口。到了今天，网卡设备的成本已经非常低了，所以一般都给装配万兆网卡。而vCPU这里强调的是逻辑核16核就可以（可能实际物理核只有8个），因为我们大部分程序都是多线程的。

我们再看计算节点。如果集群规模较小，同时资源相对比较紧张，计算节点可以跟存储节点复用机器，因为存储节点的机型基本能够满足计算节点的需求，一个16vCPU，32G+内存，万兆网口。

说完了接入层和计算层，下面我们再看看数据存储层。存储节点负责数据存取，属于IO密集型服务，建议用PCI-E的SSD，并且需要独站物理机。对于数据库来说，我们推荐部署在真实的物理机上，相比虚拟机更为稳定。此外，有条件的建议再做一层Raid0，让数据节点的读写能力更为强劲。有些同学肯定会问，数据节点为什么不做一个Raid5、Raid10而直接做Raid0。因为TDSQL本身已经是一主多从的架构，甚至可以加更多从机，在磁盘阵列这里我们就没必要继续做冗余，无限冗余只会让效能比降低。作为数据节点，这里推荐的配置是32vCPU，64G内存。数据节点采用的Innodb引擎是一个优先使用缓存的引擎，也就是说大内存对性能的提升具有显著的作用。所以，这里推荐大内存，万兆网，PCI-E的SSD的机型。

接下来是管理节点：推荐配置是8核CPU、16G内存，万兆网口。管理节点任务比较轻，一个集群也只需要少量的管理节点。如果说没有物理机用虚拟机也可以，配置相对于前面的计算、存储节点明显可以低一些。

备份节点的话，硬盘越大越好，它主要负责存储冷数据，用普通的SATA盘就可以。

以上机器的型号不用太关注，是腾讯内部的一个编号，没有什么实际意义。这里简单做一个总结，计算节点依赖CPU和内存，对磁盘没有太多要求。存储节点虽然对CPU内存也要求较高，但它更强调IO的强劲（需要PCI-E的SSD）。

通过刚刚的介绍希望可以帮助大家进一步加深对TDSQL，尤其是这种计算存储相分离的数据库的认识。从机型配置的解读我们可以清楚的了解，怎样的机型搭配能够让系统的性能发挥最佳。

总结起来，如果机型正确搭配，业务也按照规范使用，那么就可以轻松发挥出数据库强劲的性能，即以较低的运营成本获取较高的业务支撑能力。海量的业务都是伴随着现金流，比如说广告、游戏、电商，一套低成本的系统如果在满负荷工作下轻松高效处理这类业务请求，带来的经济效应是比较可观的。

三、跨城跨机房级别容灾部署方案

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

1. “同城三中心”架构

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

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

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

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

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

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