📚 课程目录第2章跨区复制原理

跨区复制原理：同步复制 vs 异步复制、跨区域网络延迟的影响、数据一致性模型

跨区复制，说白了就是把数据从 A 地搬到 B 地，而且得保证 B 地能随时顶上。我做了这么多年容灾，见过太多因为复制策略选错导致翻车的案例。今天咱们就把同步、异步、延迟、一致性这几个核心概念掰开揉碎了讲清楚。

这两种复制方式，本质上是在「数据安全」和「业务性能」之间做取舍。你想想看，每次写操作都要等远端确认，和写完本地就返回，这中间的差别可大了去了。

同步复制的逻辑很简单：主库写完，必须等备库也写完，才告诉客户端「写成功了」。我在某金融客户的项目中遇到过，他们核心交易系统必须用同步复制，因为一笔转账如果丢了，那可不是闹着玩的。

同步复制核心流程：
客户端发起写请求到主库
主库写入本地事务日志
主库将日志同步发送到备库
备库写入本地日志并返回 ACK
主库收到 ACK 后，才向客户端返回成功

优点很明显：主备数据完全一致，故障切换时零数据丢失。但缺点也致命——整个写操作的耗时取决于主备之间的网络延迟。如果两地延迟 50ms，那每次写操作至少多等 50ms，高并发场景下性能直接崩盘。

异步复制就灵活多了。主库写完本地就直接告诉客户端「搞定了」，然后把日志异步发给备库。备库啥时候收到、啥时候写完，主库不管。

我曾经帮一个电商平台做过架构优化，他们用的就是异步复制。双十一峰值每秒几万笔订单，如果用同步复制，数据库早就被拖死了。异步复制的好处就是主库性能几乎不受影响，但代价是——如果主库在日志还没传到备库时挂了，那这部分数据就丢了。

光速是有限的，数据在光纤里跑一圈需要时间。北京到上海直线距离约 1000 公里，光在光纤中的传播速度大约是真空中的 2/3，算下来单程延迟至少 5ms。但实际网络还要经过路由器、交换机、防火墙，再加上丢包重传，实测延迟通常在 30ms-50ms 之间。

我记得有一次帮客户做两地三中心方案，他们选了上海和深圳。测试时发现同步复制模式下，一个简单的 INSERT 语句耗时从 2ms 飙升到 60ms。业务方直接炸了：「这性能谁受得了？」后来我们改成了半同步复制，才勉强平衡了性能和一致性。

避坑指南：我曾经见过一个团队，把同步复制的超时时间设成了 1 秒。结果跨区网络抖动时，主库频繁超时，大量写操作失败，业务直接瘫痪。记住：同步复制必须配合合理的超时机制和降级策略，不能死等。

网络延迟对复制的影响主要体现在三个方面：

一致性模型决定了系统在故障时能给你什么样的保证。我习惯把常见的模型分成三类：

所有节点在任何时刻看到的数据都是一样的。同步复制就是典型的强一致性实现。但代价是可用性和性能会受影响。你想想看，如果备库挂了，主库是不是也得停摆？这就是 CAP 理论里的 trade-off。

异步复制属于这一类。系统保证「如果没有新的写操作，过一段时间后所有副本最终会一致」。这个「一段时间」可能是几毫秒，也可能是几分钟，取决于网络和系统负载。

我在做社交 Feed 流系统时用的就是最终一致性。用户发一条动态，几秒后好友才看到，完全能接受。但如果用在转账系统上，那就出大事了。

比最终一致性更强一些。它保证有因果关系的操作按正确顺序被看到。比如用户先发帖、再删帖，其他节点不能先看到删帖、后看到发帖。这个模型在分布式数据库中比较常见。

我的建议：选一致性模型时，别光看理论。先问业务方：「如果丢 1 秒的数据，你能接受吗？」如果答案是「不能」，那就老老实实上同步复制，然后想办法优化网络延迟。如果答案是「能」，那异步复制能省你很多运维成本。

最后说一句，没有银弹。我见过不少团队一上来就追求强一致性，结果系统上线后性能不达标，又匆匆忙忙改异步。我的习惯是：先搞清楚业务的核心诉求，再选复制策略。如果实在拿不准，可以用半同步复制做个折中——主库等至少一个备库确认，其他备库异步。这样既保证了基本的数据安全，又不会把性能拖死。