灾备与异地多活实战：两地三中心与单元化

"两地三中心"是个常用说法：两个城市、三个机房。比如同城两个机房（延迟低、互为主备），再加一个异地机房（防城市级灾害）。同城双活负责日常，异地那个负责极端情况兜底。

常见的两地三中心布局：
- 同城 A 机房：主用，日常扛流量
- 同城 B 机房：热备，和 A 实时同步，可随时顶上
- 异地 C 机房：冷备/灾备，防整个城市出事

为什么要"三"？
  两个节点之间判断谁活着容易脑裂，
  三个节点做多数派投票更稳。

关键是三个节点之间要能做"多数派决策"——断网时靠投票决定谁继续服务，避免两边都以为自己是主。

异地多活最理想的形态是单元化：把系统按用户切成多个"单元"，每个单元自成一体、自带数据库，用户请求落到哪个城市就由哪个城市的单元服务：

单元化的好处：
- 华南用户 → 广州单元，华南数据在广州
- 华北用户 → 北京单元，华北数据在北京
- 不用跨城读写，延迟低
- 一个城市单元挂了，把那部分用户切到别的城市

这样一来，跨中心的数据同步量大幅减少——每个单元大部分数据是自己管自己的，不用所有操作都跨城同步。这是让异地多活真正跑得动的关键设计。

如果同一份数据两个中心都能写，就会打架——A 中心改了用户名字，B 中心也在改，以谁为准？这就是多活最难的地方。常见做法是：关键数据只在一个中心写（归属单元写），其他中心只读；跨中心同步是单向的。

避免数据冲突的原则：
- 一个用户的数据只归一个单元写
- 跨中心只做复制同步，不双向写
- 真要跨单元操作，走异步消息，不实时强写

千万别图省事做"两边都能写"，事后数据合不拢比停服还难收拾。