直播回顾丨TBase多中心多活与高可用方案实践-创新互联

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

关注“腾讯云数据库”公众号，回复“0428陈爱声”，即可下载直播分享PPT。

TBase多中心多活与高可用方案实践_腾讯视频

大家好，我是陈爱声，目前负责腾讯云TBase产品实施和运维相关工作。

今天的主题是TBase多中心多活与高可用方案的实践，集中围绕着多中心多活以及高可用切换方案进行讲解，分享的方案都已经有实施案例。

分享总共分四个部分：

第一部分：介绍TBase的服务组件，即TBase由哪些服务组件组成，这些服务组件在部署的时候有哪些要注意的地方，以及部署的拓扑结构是怎样的。

第二部分：TBase多活部署的介绍，在这个章节里会涉及到两地两中心部署，VPC隔离、主备读写分离，各种方案的介绍。

第三部分：节点级故障的切换，比如我们在单机的实例里面，主节点故障了，备节点如何切换过来。针对TBase来说，由于它的服务组件非常多，每个服务组件也有主备节点，这一章节中将详细讲述各个组件故障，影响力的范围，以及它是怎样进行切换的，切换完以后对整个服务的影响。

第四部分：中心级的故障切换，这个章节主要讲述应用场景，为什么会存在中心级的切换，以及它的切换成本。中心级切换这个是最难实现的，整个切换成本以及切换的复杂度非常大。

PartⅠ TBase服务组件概述

我们先看下TBase的服务架构，下图我相信经常关注TBase的同学，应该对这张图并不陌生。我今天会重点对这张图里各个服务组件进行非常详细的介绍。

图中我们可以看到整个TBase由三大组件组成，最左边是GTM组件，右上角是CN组件，下面是DN组件，接下来将详细介绍下这三个组件，以及它部署的时候应该注意的地方。

首先我们看最左边的GTM组件，这个是做什么用的呢？这个实际上跟全局事务ID的（分发器）一样。在使用单机的时候，事务管理是放在内存里面的，TBase是一个分布式数据库，也有事务ID的管理，事务ID的管理是通过一个叫GTM的组件来进行管理，所有你的请求，不管是读还是写，你首先要拿到这样一个事务ID，来实现读写的一致性。

GTM的组件在部署的时候是支持一主多备的，图上只是画了一主一备的，但部署的时候它可以支持一个主多个备，主备的复制级别可以配置成强同步，也可以配置成异步。GTM只有主能够提供服务，备机永远不会提供服务，备机的作用就是拿来同步主节点上有两个信息，一个是事务ID，第二个是GTM上有全局的序列，我们要请求序列访问时它也必须要访问这个GTM，所以GTM的负载主要来自于这两方面：

• 全局事务ID的请求；
• 序列的请求。

GTM对CPU的需求比较高，一个实例里面如果它有几十个节点、上百个节点的时候，所有节点都向它请求事务ID，那么它主要消耗就是在CPU，所以在要求部署GTM节点时首先要考虑这台机器必须具备多个核。那么到底有多少个呢？就看你的请求量，如果你是高并发业务的话，那么你的CPU的核数需要更多，它甚至可以运行到几十个。虽然GTM只有主能提供服务，但基本上已经能够覆盖所有业务的请求，每秒会达到千万级的请求。

GTM同时也会写日志，虽然GTM对磁盘IO性能要求不高，但还是有一定IO的保证，在部署GTM的时候，大家一定要注意如果是和别的服务在一起的时候，要有一定的IO量给它，最好有一个独立的磁盘，哪怕是一个比较普通的sas盘也可以，它虽然不需要那么多，但它一定要保证，没有保证可能会导致请求失败。内存可以适当，因为基本上服务是很轻的，对内存的计算量是要求不会很高，一般像几十个核的CPU上面可能就配个64G的内存，可以配个200G空间的SSD或者那种sas盘就可以满足一个GTM的部署要求。最简单的就是一主一备，就可以实现高可用。

接下来我们再谈一下右上角的CN，这个是协调节点。在其他的分布式数据库上也可能叫PROXY节点，CN可以有多个主提供服务，是业务连接的入口，即应用程序要连哪个IP，连哪个PORT就是到CN这边来，比如说我们这里可能有三个IP，三个PORT，那么任何一个IP、一个PORT都可以提供给应用程序连接，他们都是对等的。那么CN上面存储的是什么？存储的是元数据，我们定义的库、表、用户、视图等等之类，这些元数据都会存在于每个CN上面，除了这个之外还有一个非常重要的信息，上面每一个CN节点还存有一份全局的路由信息，那么为什么要存路由信息呢？是因为所有的应用SQL请求，需要根据路由信息才能计算SQL要发到那一个存储节点。CN在部署的时候，一般最少两个，或者你可以部署一个，但是需要部署一个CN备机，就是CN需要主备，建议每一个CN有主备，CN做为分布式事务的协调者，CN故障，分布式事务就会存在问题，这个时候如果有备机的话那很简单，备机切换为主，就能够保证这个事务继续往下面执行。

CN在部署的时候有硬件的要求，一般要求CPU的核数比较多，如果有业务类型是必须把数据拉到CN节点进行计算等等之类的，那么它对内存的要求比较高，大多数计算是可以推到DN下面执行。磁盘的要求也就我刚才前面所说的，如是果需要数据拉回CN落盘计算，即需要配置高性能SSD盘。如果你有物化视图，那么这些物化视图的数据实际上是会存在CN的，那你的CN要有比较大的存储空间才可以。CN部署建议二个及以上，然后都有主备，主备之间可以配置强同步，这样的话一旦有故障你就可以切换过来，把事务继续运行下去。

最下面Datanode是DN节点。DN节点是拿来存用户数据的，用户数据是我们所有的用户连接CN以后，他所有的请求会全部推到下面的DN上来，那么它是怎样推的呢？它根据上面CN路由的信息，推到一个DN某个节点来，会把这个数据保存在Datanode，每个Datanode就是一个分片，如有一亿条数据，有4个分片，那么合理分片存储后，大概每个分片2500万条数据左右。Datanode在部署时最少要一主一备，哪怕是单中心也是最少要一主一备，因为不管哪一个分片故障，没有备机的话相当于你整份数据就少了四分之一，实际上就是数据不完整了，相当于数据缺失了，这个跟CN没有备机的情况下，CN节点坏了都没关系，实际上只要连接到另一个好的CN就可以。那到底要多少个分片呢？这个就取决于我们的业务，DN节点部署也是需要按单机的实例节点的规范来做基本规划，比如说你要求每一个节点尽可能不要超过多少个T，超过了以后实际上对你运维成本是很高的。

DN总体上是对硬件最苛刻的，机器要求CPU核心多、内存大，IO要好，因为它是直接计算存储，简而言之按照单机有什么样好的配置就照着用就可以。

关于服务组件的介绍我总结如下图，方便大家理解。

PartⅡ TBase多活动部署介绍

接下来我们进入第二个章节，TBase多活部署介绍。我们可以看一下部署的拓扑结构，首先看的第一张图是一种传统的主备的部署模式。

图上显示可理解为不管是南北异地也好、还是同城双中心也好，它永远只有一个主中心，也就是最上面只有一个主中心能够提供一个读写的能力，其他的节点都只能提供一个只读的能力。如果要求主备强同步，那么同城双中心署，控制延迟在3毫秒以内，对于大多数业务是能接受的。异地主备节点虽然也可以配置成强同步，但是实际上大延迟对业务的影响是非常大的，会导致TPS下降得非常厉害。比如说从北方到广州，那么它的时延往往都是在30到50毫秒之间，根据不同网络质量，1个请求来回就是100毫秒，这样一个延迟基本上是不能接受，服务器原来一条数据更新，就是几个毫秒，现在一下子来回变成100毫秒，这样你的硬件不管怎样提升都没办法满足你的业务需求。

还有一点，我们的应用可能需要数据导到消息中间件，比如说最常见的（KAFKA），主备部署结构，只有主节点能够做到逻辑解析，这个本身是PG的技术限制，只有主节点才能做到逻辑解析，然后把这些数据解析到（KAFKA），异地的不管是同城的还是跨城的，它到异地的数据就没办法同步到消息中间件，那你在异地做消息交换的时候就必定成本会很高，每一个消息交换就只能在主中心完成。这个是传统主备的部署方式的架构。

接下来我分享下双活的部署架构，这是一个双活的部署架构，那么双活的部署架构是什么样的呢？

大家可以看到南边一套完整的实例，北边也是一套完整的实例，这两套是完全独立的，你可以把它理解为两套互不相干的实例一样，但是我们又想把这两套实例绑定在一起，认为它是两套一模一样的数据库，里面存的数据都是一样的。这里采用了南北的双向同步的技术，也就是逻辑复制技术，南边的机器和北边的机器这两个实例他们之间是通过逻辑复制来实现双向的数据同步，这里南北都可以提供读写，数据都是可以同步到消息中间件，从而可以实现本地化访问，不管我的应用在哪里，或者和别的应用做数据交换。

对于原来是单中心应用，现在把业务库拆成南北以后，有一些共享的数据，这里要拆分是比较困难，现在共享的数据不拆开，南边放一份，北边放一份，使用双活数据同步从而实现双中心多活支撑。

传统的主备部署和双活部署架构，他们连接的都是指向一个物理IP，就像我们前面说到的CN节点。但如果发生故障，连接物理IP就改变了，这对应用来说它是有入侵性的，应用要不断的修改数据库连接的IP，那么我们又改进了一种架构，我们基于TBase，再加上腾讯云的另外一个组件就是VPCGW，重新规划了一种新的部署架构。

如上图所示，我们在最前面会加上一个VPC，相当于加上一个虚拟网络，所有的微服务不管是读还是写，都有一个VIP，然后由这个VIP再路由CN节点，这样就可以实现连接透明性。另外VPCGW还能支持多个CN接入节点负载均衡。

这里我来总结下双活与主备的差异。

1. 实例数：双活是有两个完全独立的实例，而主备只有一个实例。
2. 写入属性：双活是双向的，主备是单向。
3. 应用接入：路由会变得很简单，所有应用都是在单中心内完成数据交换。
4. 异构数据同步：双活两边都可做数据交换，用主备的话就是一半。
5. 运维系统部署：双活运维系统本地化部署，主备是跨了南北，运维系统也要跨南北，运维比较复杂，切换时需要运维系统和实例一起切换，这个的切换成本就会非常的高。

那么双活和主备对比有哪些优势呢？

1. 同步方向：双活数据同步双向的，主备是单向的。
2. 同步粒度：同步配置的级别，主备必需基于实例级别，双活本身可以表级，也可以库级。
3. 本地可写：双活两边实例都可以写，主备只有一个中心可以写。
4. 本地数据同步到异构数据库：双活都是支持的，而主备是不支持。
5. 南北切换成本：双活数据库不需要切换，但主备必须要切换，如果数据同步配置为异步级别，那么切换后数据怎样去补全回来？这个实际上是很难的一项工作，虽然双活也是异步的，它切换以后，可能在另外一端的数据也不一定能够过来，但故障修复后，它是可以自动同步差异数据过来的，这一部分不需要主动干预的，只要你是在应用在逻辑里能够规避这种冲突的话，那你基本上可以用双活这种方案来实现一个非常轻量级的切换成本。
6. 硬件的利用率：主备只有一个中心可写，硬件的利用率低，双活是双中心可写，利用率比较高。
7. 业务体验性：双活是本地更新，延迟低，各地域体验性一致，而主备南北访问延迟差异大，业务体验差。

那么双活带来挑战是什么？

1. 性能比不上物理复制的，这个是一个挑战，需要利用多通道进行复制。
2. 数据冲突问题，逻辑复制会带来一些冲突的问题，比如南边的单号、北边的单号冲突，需要在业务层面进行解决。
3. DDL同步，逻辑复制是不同步DDL，需要有专用的工具来同步DDL，给运维带来挑战性。

PartⅢ 节点级故障切换

接下来这个章节会给大家重点介绍下关于节点级故障的切换方案。

1.GTM备故障。

如果GTM主备是强同步配置，则系统选择新的备GTM。

如果没有备GTM,就会影响GTM数据同步，影响业务访问，那要对它同步模式进行降级，由原来的主备强同步变成异步。

2.GTM主节点故障

影响事务ID获取，系统不可用，这时需要选择日志同步最新的备机切换为GTM主。

切换完后还要修改路由，每一个DN、CN的GTM路由信息都修改需要。

GTM复制级别降级处理，如果切换后没有GTM备机，降级成功以后才能够对外提供服务。

3.DN备节点的故障

DN备故障，只读服务能力失效，这种故障发生时怎样去切换呢？

这其实很简单，由于我们前面加了一个VIP，这个VIP只要指向CN主就可以继续访问。

如果故障节点备机是有多个的话，把另外一个备机加进只读平面，则只读取也能继续使用。

原来主备是强同步的，如果这里没有可用备机，主备同步就必须要降级，降为异步，不然数据写不进来。

4.DN主节点的故障

系统进行主备倒换，从多个同步备机就从中选出最新的备机来作为一个新主，另外你也可以人工强制倒换过去。

修改所有节点的访问路由信息，指向新的DN节点

如果该DN节点主备切换后无备节点可用，则需要对原来的强同步进行降级为异步。

如果有只读平面，则只读平面还要修改指向主平面。

5.CN备节点故障

如果CN节点配置为强同步，同时有新的CN备节点存在，则需要选择新的备CN升级为强同步节点。

如果没有新CN备节点，复制级别要降级为异步模式。

如果只读平面所有节点不完整，则只读VIP切换指向CN主节点。

6.CN主节点故障

故障的CN不影响其它CN主节点对应提供服务，VIP会将故障的CN主节点从负载均衡表中删除。

CN故障节点进行主备切换，从可用的备节点中选择新的主进行切换。

修改各个节点中访问故障CN节点的路由信息表。

切换后如果没有可用的备CN节点，则节点的同步级别需要调整为异步复制 。

如果备平面VIP对应的CN备机列表无IP可用，则系统修改只读平面的VIP指向CN主节点。

PartⅣ 中心级故障切换

介绍完三个节点，我们可以再来看一下中心级。

这里举个例子方便大家理解，如对外光纤全部给挖断了，或者整个实例是不能用的。如图所示，南北网络可能已经是不通了，北边不能用，只剩下南边可用了，这个时候怎么办呢？我们只要修改最上层的微服务访问路由即可，可能是一个DNS变更，由于数据是近乎同步的，它能够读到的数据还是一致的，也可以提供读写服务，而对于还没有同步过来的数据，在网络或者系统正常后，差异的数据会自动同步过来。

如果使用主备同步数据，由于南部跨地域的物理位置决定不可能使用同步复制，在发生故障时，基本上是不可能去切换的，因为你的切换成本太高了，首先管控平台要进行切换，再次数据库要切换，后期的数据如何去修复是很困难的。

从中心级的故障切换来看，多活部署的架构，异地切换时数据库不需要做任何操作。对于微服务来说，是切DNS，等故障恢复，数据同步完成以后，只要把DNS回切回去，把流量切回去就可以了。对于业务可用性，体验性要好，双活切换成本低，提供了一种相对轻量级的成本，让这种真正的跨南北的切换成为可能。

PartⅤ Q&A

Q：主备节点个数如何选择？

A：双活的部署南中心的DN节点肯定都是一主一备或者是一主两备，北中心也是一主一备或者一主两备，因为两边都是可以写。所以它部署的时候实际上是两套完全独立的实例，需要在本地提供高可用的保障。

Q：CN有没有搞主备的必要性？

A：CN多个是要解决压力负载均衡的问题，而主备还解决分布式事务的连续性的问题，CN是会参与一些分布式事务的，比如说我们建表，建数据库，CN是做一个协调节点，如果一次事务有两条数据，有一条是插入到DN1，有一条是更新到DN2，那么就属于分布式事务，那么CN就要管理这些事务，如果没有主备，一担CN主完全故障不可用，则分布式事务就无法继续下去。如果你是业务类型里是有分布式事务，还是建议CN节点有主备节点存在。

Q：多活是否支持强同步，延迟有多大？

A：多活是没有强同步方式的，多活是基于逻辑复制的，只能采用异步同步模式，延迟大小，比如从北京到广州的话，数据从这边到那边可见的延迟大概在200毫秒，但实际它是异步的，对你的业务不影响。也就是说，你的前端用户感觉是很快，慢就慢在后端的数据同步那里，基本上如果你的网络是可靠的，性能没影响的情况下，你一条数据从南到北的话，这个由于物理网络决定，也就大概在200毫秒左右。

Q：双活这种结构从目前来看，大的是解决一个什么样的问题呢？

A：当前很多业务他们单中心的，几百种业务可能1000多套实例全部放在一个中心里，不管是北京的、还是广州、全部部署在广州或者全部堆在北京，那么异地连接过来开销比较大，延迟比较大。但是把它拆开，北京就放在北京，广东就放到广东，这样的话你是把业务库拆开了，但实际上由于原来在单中心的时候他们的交互在一个中心完成，那么他们之间交互的延迟是很低的，你拆分之后对于需要不同系统交换数据的应用，延迟变大，双活刚好解决用户体验延迟问题。

VPCGW组件是腾讯云另一个产品，这个不包含在TBase里面。可以购买腾讯云的TCE平台。

Q：运维管理系统是否为开源工具实现？

A：主备切换都是自己开发的工具，我们的运维系统是自研的，这个没有用到第三方现在组件，因为目前来看，外面第三方的一些工具还是很难满足整个复杂运维管控系统，所以我们的运维管控系统是自研的。

Q：单机和分布式的有哪些区别？

A：分布式可以实现多个分片在线扩展，处理更多的并发请求，存储数据量也更大，满足业务不断扩大的需求。而单机的只能扩展备机数量，但如果数据量和访问量压力不大的情况下，单机的运行效率要好于分布式，运维也比分布式要简单。

以上是今天的分享和Q&A的解答，感谢大家的聆听。

TBase是腾讯TEG数据库工作组三大产品之一，是在开源的PostgreSQL基础上研发的企业级分布式HTAP数据库管理系统。通过单一数据库集群同时为客户提供高一致性的分布式数据库服务和高性能的数据仓库服务，形成一套融合完整的企业级解决方案。大家在数据库领域遇到相关问题时，欢迎随时留言。

往期推荐

微信支付用的数据库开源了

特惠体验云数据库