作者： 代晓磊_Mars
TiDB的多活一直是各个将TiDB用到核心场景的互联网公司都在努力实现的高可用方案。为了实现分布式数据库的可用性要求，通常采用多中心部署方案，以保证高可用和容灾能力。多中心部署方案包括同城主备集群，同城双中心，同城三中心、两地三中心等多种部署模式。
同城多中心方案一般硬性要求：
（1）数据中心距离在 50 km 以内，通常位于同一个城市或两个相邻城市
（2）数据中心间的网络采用2条光纤专线连接，并且要求延迟小于 1.5 ms，并且长期稳定运行
（3）双专线且带宽大于 10 Gbps。
在讲多活之前先给大家普及几个概念：
- RPO：Recovery Point Objective，数据恢复点目标，也就是说业务能容忍数据丢失量，核心业务一般要求RPO=0。
- RTO：Recovery Time Objective，恢复时间目标，也就是说业务能接受的最大不可用时间，一般都要求RTO<30s。
- Muti-raft：raft是分布式一致性算法，tikv的底层多个region副本(默认3副本)是通过日志复制来实现数据同步，并且靠多个raft group(成员有“身份”)来投票来获得leader/follwer身份，tikv的数据写入是靠raft group中的多数节点写入成功才算成功。
所以在多活的场景中的建议：
- 服务器容灾：至少提供 3 台服务器来避免单host宕机导致的集群不可用。
- 机架容灾：至少提供 3 个机柜来避免单机柜(rack)故障导致的集群不可用。
- 机房容灾：至少提供 3 个数据中心来避免单数据中心(DataCenter)故障导致的集群不可用。
- 城市容灾：至少规划 3 个城市来避免单城市灾难引发的集群不可用。
注：这也是俗话说的鸡蛋不要放在一个篮子里的原因。
主备集群
这里主要提到的是基于TiCDC的同城、跨城的数据同步。
这些对于所有核心tidb都放在同一个机房的公司，如果机房孤岛或者其他灾害问题，业务无法及时恢复。所以说TiDB集群的主备集群需求是重要的需求。TiCDC作为TiDB生态中重要的一环，通过ticdc cluster实时拉取tikv的changelog并且应用到下游集群，从而实现了同城/跨城的主备集群数据同步，有了主备集群，一是可以将部分不需要太实时的读取流量切到备用集群，来缓解主TIDB集群的读取压力。二是一旦核心机房有问题，备用集群就可以立即接管服务，因为经过了ticdc这层同步中间件，所以RPO受主库写入情况，以及ticdc sink速度的限制，存在 RPO！=0的情况，RTO肯定是能做到小于30s的，因为这个只是探测和切换的时间是由自动脚本或者监控来控制，所以可以实现主集群不可用时的及时切换。
PS：本文主要讲基于Placement-rule的多中心方案，所以这种“异步复制”的ticdc工具就不展开讲了，如果大家有想对TiCDC更加深入的了解，去年我写过一篇：TiCDC应用场景解析 的文章，大家可以跳转详细看看。
下面要讲的几套多城多活方案，都是基于Placement-Rule配置实现的同一套TiDB跨多城/多数据中心的部署架构。
同城双中心
其实在TiDB 4.0版本就出现了使用Placement rule来配置的集群(这套同城双中心的方案官方没有放出来)，不过在TiDB的5.4版本出现了一种基于自适应同步（即 Data Replication Auto Synchronous，简称 DR Auto-Sync）同城两中心部署方案，下面主要介绍下这个自适应同步方案架构。
部署架构
通过查看上面的集群部署架构图：
（1）这套架构将一套TiDB集群部署在同一个城市的2个IDC机房(注意要满足硬性要求)，一个是主数据中心(PRIMAY IDC)，一个是从数据中心(DR DC)
（2）集群采用 4 副本模式，其中主数据中心放 2 个 Voter 副本，从数据中心中放 1 个 Voter 副本 + 1 个 Learner 副本，也就是3个voter和1个没有投票资格的Learner，并且Leader在主数据中心
（3）自适应同步，TIDB集群的复制模式可以自动在sync/async/sync-recover三种状态之间自适应切换。
- 在默认的同步模式(sync)下，Raft来保证从数据中心中至少有一个副本保持跟主数据中心同步，这样的情况下，如果主数据中心不可用（2个 Voter 都不可用），这时raft是没法选出 Leader的，这至少数据不丢（RPO=0），因为从数据中心有最新的数据，只是如果要把从数据中心当作新主来使用时需要tikv-ctl来恢复，这个时候恢复时间就不好评估了(RTO>N)，关于如何恢复？参考我之前的写过的：TiDB集群恢复之TiKV集群不可用。
- 如果从机房网络故障时，超过PD参数wait-store-timeout(默认60s)，主从中心间的数据同步就会切换到async(异步复制模式)，在这种情况下，raft算法优先保证主数据中心的2个副本写入(Voter的多数派写入成功，事务可以提交)，从数据中心靠异步复制获取的不是最新的数据。这是主机房读写都正常(RPO=0 & RTO=0)
- 当从机房网络故障恢复时，主从数据中心的同步由异步切换到sync-recover(恢复同步)，此时不保证 DR 与 PRIMARY 完全同步，随着恢复的进行，从region会不断的将状态汇报给 PD，当 TiKV 的所有 Region 都完成了同步复制模式的切换，PD 将集群复制状态切换为 sync。
特点：
（1）同城双中心，在同步模式下能实现RPO=0，如果从数据中心不可用，不影响（RTO=0）
（2）在非同步模式下，如果主数据中心不可用，不能实现RPO=0，RTO也不可控可能分钟或者小时，需要tikv-ctl工具来操作将从数据中心多久提升为主数据中心。
同城三中心
同城三中心方案应该是当前最常规的高可用方案，需要同城有三个机房或者云厂商的三个可用区，数据中心间的数据同步通过内部的raft复制协议完成。同城三数据中心可同时对外进行读写服务，实现了任意中心发生故障不影响可用性。
简易架构图
通过查看上面的集群部署架构图：
（1）这套架构将一套TiDB集群部署在同一个城市的3个IDC机房，所有数据中心都有tidb/pd/tikv，所有的数据中心都可以接受读写服务。
（2）集群采用默认 3 副本即可，并且3个数据中心都有region的Leader/Follower副本。基于raft的多数派写入逻辑，至少有2个数据中心有最新的数据，所以任何一个数据中心不可用，不会产生任何数据丢失 (RPO = 0)，但是在不可用数据中心的Leader副本会触发raft的leader选举，该选举新Leader有一定的时间，差不多在在30s内，所以RTO<30s。
（3）该架构受机房间网络的速率、稳定性等硬性条件关联紧密，比较适合读多写少，或者对写入不“敏感”的业务。就算数据中心延迟稳定在1.5ms内，数据写入需要保证多数派写入的情况下，肯定会发生跨数据中心的写入，这时写入延迟肯定大于基本的网络延迟：1.5*2=3ms，所以写入敏感的业务慎用；对于读取场景，如果请求的region leader在另外的数据中心，也会受网络延迟影响，读取按照具体的业务场景也可以选择follower/steal read。
集群架构特点：
所有数据的副本分布在三个数据中心，具备高可用和容灾能力，读写性能受数据中心之间网络延迟的影响较大，所以同城三中心的架构需要适配具体的业务场景来应用。
两地三中心
两地三中心是以本地的2个读写数据中心、异地灾备中心的高可用容灾方案，相比同城多中心方案，两地三中心可以应对城市级自然灾害，具有跨城级高可用能力。
下图为集群部署架构图，具体如下：
通过查看上面的集群部署架构图：
（1）集群采用两地三中心部署方式，分别为北京 IDC1机房(本地读写机房)，北京 IDC2机房(本地读写机房)，西安 IDC3机房(异地灾备机房)；所有数据中心都部署tidb/pd/tikv。
（2）集群采用 5 副本模式，其中 IDC1 和 IDC2 分别放 2 个副本，IDC3 放 1 个副本，可以通过PD调度实现所有的Leader region都在北京的2个读写数据中心，所以读写都在北京本地，读写性能跟同城三中心类似，取决于数据中心间的网络情况，西安的数据中心只有follower节点，还保留了一份异步的数据。
（3）副本间通过 Raft 协议保证数据的一致性和高可用，对用户完全透明。
集群架构特点：
（1）本地两中心可同时对外提供服务，资源利用率更高。
（2）可保证任一数据中心失效后，不发生数据丢失（RPO=0），可用性也可以在分钟级别恢复（RTO分钟级）。
（3）如果本地两中心不可用，那就剩下西安的数据中心，由于raft的配置，西安的数据中心可能没有获取到最新的数据，也就是说不能保证RPO=0，因为多数的副本不可用，集群不可用，所以RTO的时间也是借助tikv-ctl实现数据恢复后的总时长。
（4）两地三中心需设置 5 副本，数据冗余度增加，增加硬盘空间成本。
总结
如果只有同城双机房，本人使用过基于ticdc的主备方案，真正意义上的多活，还是同城三中心。
注：本文主要参考TiDB集群已有方案，文中多图都来自于tidb官网