【TDSQL(MySQL版)两地三中心金融级架构深度解析，老DBA踩坑落地经验】

引言

做数据库这些年，被问到最多的一个话题就是：你们那个两地三中心到底怎么搞的？真的挂了一个机房业务不会停吗？数据真的不会丢吗？

说实话，这些问题我都经历过。从最早单机房吭哧吭哧维护，到后面被迫上双中心，再到金融客户逼着做两地三中心，一路踩了不少坑。今天就把TDSQL（MySQL版）在实际生产环境里怎么部署两地三中心、各层怎么设计、出了问题到底怎么切，给大家掰开揉碎了讲一讲。

内容可能有点干，但都是真金白银踩出来的经验，建议收藏慢慢看。

一、先说说这个架构长什么样

两地三中心，听着挺唬人，其实拆开来看就三层意思：

一个是主数据中心，放你最核心的业务；一个是同城灾备中心，跟主中心在同一个城市但不同机房，两边用专线连着，延迟很低；还有一个是异地灾备中心，一般放到别的城市，专门防那种"整座城市出问题"的极端情况。

以我们实际部署的情况来说，主中心在深圳A机房，同城备库放在深圳B机房，异地中心放在上海。应用在主中心和同城中心都部署一套，也就是所谓的"双活"。用户请求进来，先过DNS，再过F5负载均衡，然后打到Proxy，最后落到TDSQL数据库。

数据库这边我们用的是一主三备。主库挂掉的时候，同机房的备库优先顶上来，跨机房的备库跟着重新挂接。这一套跑下来，只要不是三个地方同时炸，业务基本不会受太大影响。

二、一层一层拆给你看

1.DNS智能解析

DNS是流量的大门。你配置的解析策略直接决定了用户请求往哪走。

实际用的时候，我们会配智能解析规则——比如按地域、按运营商、按机房负载来做调度。更关键的是，DNS本身也是跨机房部署的，一个机房挂了不影响解析。还可以配策略控制流量是否允许跨机房，这个在容灾演练的时候特别好用。

2.F5负载均衡

请求过了DNS，下一跳就是F5。F5在这里就干一件事：把流量均匀地打到后面一堆Proxy上，别让某一台Proxy累趴下。

部署上，每个机房配两台F5，一主一备（Active + Standby）。两台之间互相盯着，一台挂了另一台秒切。F5还会做健康检查，后面哪台Proxy不健康了，直接摘掉，流量不往那走。

F5本身也是一主多从。如果整个机房的F5全挂了，流量会自动走到同城机房的F5上去，层层兜底。

3.Proxy代理层

Proxy是应用和数据库之间的"中间人"。对应用来说，它就像个普通MySQL，连上去就行，根本感知不到后面有多少个分片、主从怎么分布的。

Proxy最大的特点是——无状态。啥叫无状态？就是每个Proxy看到的数据完全一样，不存业务会话。这有什么好处？挂了就挂了，换个Proxy连就行，业务根本无感知。

我们每个机房放两台Proxy，总共四台。某一台挂了，F5检测到直接剔掉，应用连接池重连一下，秒级恢复。整个过程中用户端可能也就卡一下，刷新就好了。

4.数据库层（核心）

终于到了重头戏——数据库。这是整个架构里最金贵、也最复杂的一层。

TDSQL采用的是一主三备。写请求全部走主库，备库通过同步复制跟着主库跑。四个节点跨机房分布：主库在A机房，一个强同步备库在同城B机房，还有一个在同城C机房，异地备库可选配到上海。

这里有个关键设计——跨IDC强同步。啥意思？就是主库提交事务的时候，必须等至少一个同城备库确认写完了，才给应用返回成功。这一步保证了RPO=0，也就是主库哪怕瞬间蒸发，已提交的数据也不会丢。

备份我们也做了独立设计。每个节点都有备份，数据落到NAS上。主中心和同城中心各配一套NAS，异地中心看需要也可以加。

另外注意一点——复制是按实例为单位的。比如你有一个16分片的分布式实例，那这16个分片要作为一个整体复制到对端，分片数和拓扑结构必须保持一致。非分布式的简单一些，一个分片一套数据就完事了。

5.管理节点

管理节点里面最核心的是ZooKeeper，存着整个集群的路由信息、节点状态，可以说是整个系统的"大脑"。

ZK我们怎么部署？5台，2+2+1。主中心放2台，同城中心放2台，第5台放到异地的仲裁区。这个设计非常关键——任何一个机房挂了，剩下的节点还能凑出多数派（3台以上），集群还能继续选举Leader做决策。

还有个MC节点，负责全局一致性读，维护集群的逻辑时钟。部署的时候也得是奇数个，保证能选出结果。

其他还有一些辅助节点，像KEEPER、OSS这些，管配置、管监控数据的。生产环境一般4台管理服务器就够了。异地中心也放一套管理节点，配置可以低一点，但灾备切换的时候必须有。

三、数据怎么复制才不丢

数据复制是整个容灾的命根子。我们用的是两套策略：同城强同步、异地异步。

同城的两个机房之间，主库写事务必须等备库确认。这个过程会有延迟，但在专线环境下一般也就几毫秒，对性能影响可控。换来的是RPO=0——主库炸了，备库上数据一条不少。

异地为什么是异步？因为跨城延迟太高了，几十毫秒起步。如果等异地的确认，主库的写入性能直接被拖垮。所以异地用异步复制，允许少量延迟。反正异地是防"城市级灾难"的，真到那一天，分钟级别的RPO是可以接受的。

复制链路建好之后，系统会持续监控复制延迟。一旦延迟飙高，立刻告警，运维同学就可以介入看了。

四、出事了怎么切（重点）

说了这么多设计，真出问题了到底怎么切？这是大家最关心的。我们按故障级别一层一层说。

1.F5挂了

F5挂了最轻。本机房的Standby秒切成Active，业务无感知。如果整个机房的两台F5全挂了，流量自动走到同城机房的F5，继续往后转发。策略很简单：同机房优先，跨机房兜底。

2.Proxy挂了

Proxy挂了也简单。F5健康检查一检测， unhealthy的节点直接摘掉。应用的连接池发现连不上，自动重连到别的Proxy。因为Proxy无状态，换个节点继续用，数据不受影响。整个过程秒级搞定。

3.数据库主库挂了

这是最紧张也最考验架构的场景。整个切换流程大概是：

0. 故障检测——管理节点一直在给主库发心跳，超时了就判定故障。

1.备库选举——优先选同机房的备库（延迟最低、数据最全）。同机房没有就选跨机房的。

2. 原主库降级——把故障主库"踢下线"，防止它恢复之后抢主（脑裂）。

3. 新主库提升——备库升主，然后通知所有Proxy更新路由。

4. 重建复制——剩下的备库重新挂到新主库上，恢复一主三备。

这一套流程跑下来，RTO一般在30秒左右。快不快取决于当时业务负载——如果主库正在跑大量事务，回滚需要时间。

但数据不会丢。因为强同步保证了所有已提交的事务至少有两个副本，切的时候不会丢数据。这就是RPO=0的含义。

5.整个机房挂了

这是最恐怖的场景，但也是两地三中心存在的意义。

先说ZK。2+2+1的部署就是为了这一刻——挂了2个节点还剩3个，仍然满足多数派，ZK集群继续工作，路由信息不会丢。

再说数据库。主库在那个机房对吧？没了。这时候跨机房的备库会被选举为新主库。因为跨IDC是强同步，数据还是完整的（RPO=0）。只是切换时间会长一点——需要处理一些未完成的事务、回滚进行中的操作，所以比同机房切换多耗点时间，但一般不会超过30秒。

Proxy和F5我们前面说了，都是跨机房部署的，流量直接切到同城中心就行。应用双活部署，业务基本不中断。

所以你看，整个机房挂了，从DNS到F5到Proxy到数据库到管理节点，每一层都有高可用设计，都能切。这才是真正的"机房级容灾"。

6.同城网络断了

同城两个机房之间的网络断了，这种情况比较特殊。此时主库和同城备库的强同步链路断了，怎么办？

两条路：一条是退化为异步模式，主库不等备库确认了，继续跑业务。数据一致性会受点影响，但业务不停。另一条路是把异地的异步备库临时提升为强同步备库，维持强同步关系。

如果同城断网时间很长（十几二十个小时），可以考虑把业务临时回切到主中心单点跑。但要注意——异地是异步复制，两边的数据可能对不齐，恢复之后需要人工核对或者做数据校验。

五、几个血泪建议

最后说几个我们踩坑踩出来的经验，新手做两地三中心一定要看看：

1.ZK部署千万别偷懒

2+2+1不是随便定的，是经过验证的方案。仲裁节点一定要放在独立的位置，别和主库放一个机房。我们曾经为了省事把ZK都堆在一起，结果机房一挂，整个集群管理瘫痪。

2.监控告警必须到位

复制延迟、ZK状态、F5健康检查、Proxy连接数——这些指标一个都不能少。没有监控的容灾等于没有容灾，出事了你都不知道该切哪。

3.一定要做演练

纸上谈兵没用。建议每季度至少做一次主库切换演练，每年做一次机房级故障演练。不练不知道，一练全是问题。我们第一次演练的时候，发现Proxy路由更新慢了10秒，这问题不演练根本发现不了。

4.同城专线要冗余

强同步依赖同城网络，专线断了同步就变异步。建议双线冗余，两条不同运营商的专线，互为备份。同时持续监控网络延迟和丢包率。

六、最后说两句

两地三中心说起来复杂，其实核心思想就一句话：不要有任何单点。从DNS到F5到Proxy到数据库到管理节点，每一层都能挂、每一层挂了都能切。

TDSQL这套架构我们在金融客户那边跑了很久了，经历过大大小小各种故障，总体来说RPO能做到0，RTO控制在30秒以内，可用性5个9起步。当然，架构是一回事，运维是另一回事。再好的架构，不监控不演练，出事照样抓瞎。

希望这篇文章对你有帮助。如果有问题，欢迎留言交流，大家一起踩坑一起进步。

END

更多精彩，关注我，一起学习、成长