多地域容灾架构里的节点，核心分三类：数据节点、流量节点、仲裁节点，数据节点负责把数据复制到各个机房，流量节点负责把用户请求调度到正常地域，仲裁节点负责在脑裂时拍板谁说了算，三者的角色划分比选什么软件更重要，划分不清，再贵的方案也会在故障时互相踩踏。
多地域容灾架构怎么设计：节点角色先分工
容灾架构不是把服务器多买几台扔进不同机房就完事，你想想，每个城市机房里的机器都在跑，但谁听谁的？数据往哪儿写？用户来访问时谁接待？这背后就是节点的角色分工。
行业里有个常见比喻：主节点像公司里的总经理，从节点像副手，仲裁节点像董事会，总经理在时，所有重要决策都得他签字；总经理失联了，副手不能直接上位，得等董事会投票确认，放到容灾架构里，角色的边界越清晰,故障时的反应越快。
异地多活架构节点有哪些：从数据层到流量层的角色拆解
任何一个多地域容灾系统，往下拆都能拆出四层角色，每一层角色的职责不同,故障时的行为也不同。
- 流量接入节点：各省用户解析DNS后最先碰到它,按策略把请求分配到不同地域。
- 应用服务节点：接收请求、做业务逻辑，不存最终数据,保持无状态。
- 数据存储节点：数据库、缓存、消息队列，是容灾里最“重”的角色。
- 仲裁协调节点：独立于业务链路之外,监控心跳并对主从切换投票。
数据层节点：主从关系决定数据一致性
数据层是整个容灾架构里最不能含糊的节点，多地域部署时，MySQL主库通常固定在一个机房，从库在其他机房实时拉取binlog，Redis方面，一个地域写，另一个地域读，通过跨机房同步组件把数据同步过去，这里有个容易踩的坑：数据节点不能搞“双主”，两边都能写会发生冲突,业务上想改都找不到谁是权威。
流量层节点：让用户始终找到活着的节点
流量节点分两种：DNS层面的全局负载均衡（GSLB）和机房内部的负载均衡（SLB），GSLB负责大方向，比如北京用户走华北节点、广州用户走华南节点；一旦某个地域的节点被判定宕机，GSLB会摘掉它的IP，把流量转发到健康地域，SLB只管机房内部的机器分配，这两个节点是用户感知容灾切换的第一道门，但很多团队只关注数据同步，忽略了GSLB的探测策略，结果数据层完好,流量层把用户带到了错误的地方。
仲裁节点：专治“两边都觉得自己活着”
多地域部署一定会遇到一个问题：光缆被挖断，两个机房之间网络不通，但两边都还在运行，主节点觉得自己活着，从节点也觉得自己活着，业务上两边同时开始处理写请求,这就是脑裂。
仲裁节点就是用来打破僵局的，它不参与业务读写，只接受每个地域发来的心跳，心跳断了就投出关键的一票，仲裁节点本身也要高可用，通常用奇数节点部署，比如三个小规格的实例，或者直接采用对象存储上的分布式协调服务,绝不和业务节点混部。
节点角色划分背后：一致性与可用性的取舍
角色划分不是为了把架构图画得好看，而是为了在故障时有人能拍板，换句话说，多地域容灾架构里每一个节点的角色，都是在回答两个问题：数据能不能丢？业务停不停？
这两个问题没法同时满分,必须做取舍。
| 节点类型 | 倾向一致性（RPO=0） | 倾向可用性（RTO≤30秒） | 典型场景 |
|---|---|---|---|
| 数据主节点 | 同步复制，等从库确认再返回 | 异步复制，主库写完就返回 | 金融交易选同步，内容发布选异步 |
| 流量节点 | 精准探测，避免误切 | 快速摘除，宁可错杀 | 政务系统选精准，互联网业务选快速 |
| 仲裁节点 | 需要多数派确认后才切换 | 少数派也允许临时接管 | 强一致场景用多数派，高可用场景用廉价仲裁 |
多数情况下，容灾架构的主节点和从节点是清晰对应的：主地域的各项指标优于备地域，备地域平时不处理写流量，只负责同步数据和接住一部分读流量，这种角色划分的优点是脑子清楚，缺点是备地域的机器平时利用率不高,成本投入上比较吃亏。
因此出现了一种更“抠成本”的角色划分：多地轮流当主，每个地域都承担部分业务的写流量，比如华东地域负责用户模块的写，华北地域负责订单模块的写，从全局视角看，每个节点既是主也是备，这种划分对数据同步的要求更高，需要业务模块按数据维度拆得足够细,否则某一区域故障时还是会出现跨地域的读写延迟。
节点角色的切换与恢复流程
角色划分好了，得能转起来，整个切换过程可以用一套具体的操作路径来描述,这里以典型的主备切换为例：
- 监控系统发现主地域心跳丢失，仲裁节点发起投票,确认主地域不可信。
- 运维人员或在自动故障转移脚本中确认复制延迟是否在安全范围内。
- 调用云平台的原生切换接口，把VIP（虚拟IP）从主节点漂移到备节点。
- 业务侧同时更新连接池配置,或者在GSLB上把主地域的权重调整为0。
- 原主地域网络恢复后，以新主节点的从节点身份重新加入集群,不要立刻切回。
需要留意的是第二步。复制延迟没有归零就开始切换，意味着丢数据，你可以在切换命令执行前，先在主库上做一次flush logs，然后查看从库的seconds_behind_master参数，确认延迟为0后再执行stop slave并提升为新的主库。
容灾架构多少钱：和节点的数量直接挂钩
聊角色划分绕不开成本问题，多上一个节点，就要多买一套机器、多付一份机房租、多养一个运维人力来维护。容灾架构多少钱取决于你想让几个节点承担主要角色。
从行业常见配置来看,两种方案比较普遍：
- 两地三中心：主地域一个数据中心，备地域一个同城中心加一个异地中心，主中心承担全部写流量，同城中心负责快速接管,异地中心只冷备数据。
- 三地域五节点：三个地域的机房互为备份，每个地域内部再拆分逻辑角色,对应金融级业务或大型互联网平台。
在成本上，行业共识认为：两地三中心的成本大约是单机房部署的2.5倍到3倍，三地域五节点的成本又比两地三中心高出一倍左右，这些价格中超过一半来自数据节点的同步链路和带宽费用，因为跨地域的数据复制会持续消耗公网带宽，尤其是MySQL的binlog同步和Redis的AOF同步,基本上是24小时不停跑的。
如果预算有限，可以把仲裁节点降级为低成本的小规格实例，而把大头的钱花在数据节点和流量节点上，原因很简单：仲裁节点只是偶尔投一票，不需要高性能CPU；数据节点才是每一次读写都离不开的底层，本地盘比云盘便宜不少，但本地盘的数据持久性弱于云盘，建议备份节点使用云盘，主节点按业务需求选择,不要全盘追求低价格。
多活容灾适合什么场景：按业务特征对号入座
多地域容灾节点不是越多越好，这事取决于业务到底能不能接受“多地同时读、单地写”或者“多地分片写”的复杂度。
- 跨地域分片写，适合用户天然按地域聚集的业务，比如在线教育大区课表、内容社区按省份运营。
- 异地多读单写，适合核心交易系统，比如电商订单、银行账户查询。
- 同城主备加异地备份，适合对RPO要求极其严格的业务，比如医疗系统、支付通道。
反过来讲，如果你的业务是一个简单的官网或者访问量很低的后台系统，就不值得把节点拆出这么多角色来，拉两台不同地域的ECS，做一份定时备份，再挂一个对象存储存放冷备文件，已经是性价比最高的容灾方案了，这种轻量级的做法成本还不到复杂方案的五分之一,而恢复时间也完全够用。
本质上，节点的角色划分要考虑该节点应对的故障半径，故障半径是单台机器，就用主备；故障半径是一个机架，就用同城双活；故障半径是一整个城市，才轮到多地域容灾出场。角色的数量与故障半径匹配，才是正确的设计思路，如果为了“高级”而强行堆节点，最终只会让运维团队疲于奔命。
Q&A：多地域容灾架构怎么设计才能避免脑裂
问：多地域容灾架构怎么设计才能避免脑裂？
答：脑裂的根源是主节点和从节点之间失去联系后，都认为对方死了、自己还活着，避免手段有三个核心设计：一是设置仲裁节点，让两个地域谁拿到仲裁的多数票谁才接管，票数不足的地域即使活着也不提供服务；二是站在业务侧做更强的判断，比如仲裁节点持续三个心跳周期（通常是9到15秒）没收到主地域响应，才允许从地域升级；三是把数据写入的权限跟一个分布式锁绑定，升级从节点前必须抢到这把锁，抢不到锁的地域强制降级为只读，上述三点全做到,脑裂的概率就非常低了。
问：容灾节点角色怎么划分，主从仲裁各自承担什么职责？
答：主节点负责全部数据写入和强一致性读，从节点负责数据备份、只读流量分担和运行时监控，仲裁节点不承载业务数据，只维护集群的心跳状态并决定是否强制变更主节点，主节点要选在所有机房中网络条件最优的位置，从节点的复制链路要有独立于业务带宽的专线承载，仲裁节点的数量应为奇数且部署在第三个物理位置，避免两个机房只有两票导致平局，职责划分清楚之后，监控指标也要分节点看：主节点看写入时延和连接数，从节点看复制延迟和底层磁盘使用率,仲裁节点看心跳超时次数和切换记录。
问：容灾架构多少钱，两地域和三地域成本差多少？
答：标准的两地域容灾通常包含两个机房的各一套核心业务节点、一个中间件的仲裁节点和数据同步带宽，包年价格大约在二十万到五十万之间，三地域方案需要额外增加一个地域的全部节点、跨地域专线和更多的数据副本存储空间，价格大约在四十万到一百万以上，两者之间的差额主要来自数据节点数量增加带来的授权费和跨地域带宽成本，如果只是加了地域却没有独立的仲裁节点,当真正需要做故障切换时这部分钱省下来很容易吃大亏。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/626537.html
