第3章冗余设计模式

冗余设计模式：主备、双活、多副本

聊到系统稳定性，冗余设计绝对是个绕不开的话题。我入行那会儿，带我的老大哥就跟我说过一句话：「别把鸡蛋放在一个篮子里，也别指望一个篮子永远不破。」这话糙理不糙，说白了就是冗余的核心思想——通过增加资源来换取可用性。

今天咱们就掰开揉碎了聊聊三种最常见的冗余模式：主备、双活、多副本。每种模式我都踩过坑，也尝过甜头，希望能帮你少走点弯路。

主备模式，你想想看，就像家里备了个灭火器。平时用不上，真着火了你得指望它管用。系统里也是一样：一台主节点干活，一台备用节点待命。

主节点挂了怎么办？备节点顶上。就这么简单。

核心特征：

我在项目中遇到过这么个事。有个金融系统，要求RTO（恢复时间目标）在30秒以内。我们用了主备模式，备机每秒钟从主机拉一次binlog。结果有一次主机磁盘坏了，切换倒是成功了，但备机因为同步延迟丢了3秒的数据。嗯，这里要注意——主备模式最大的坑就是「你以为备机数据是完整的，其实不一定」。

避坑指南：

我曾经在一个电商大促前检查主备切换，发现备机的CPU负载比主机高了20%。查了半天，原来是同步线程和业务线程抢资源。后来我养成了一个习惯：备机不仅要看数据是否同步，还得看它的资源水位是否扛得住切换后的流量。

主备模式有个明显的浪费——备机闲着。双活模式就不一样了，两台机器都干活，谁也别闲着。

双活，说白了就是两个节点同时提供服务。用户请求打到A也行，打到B也行。但这里有个关键问题：数据一致性怎么保证？

我见过最典型的场景是数据库双活。两个机房，各部署一套数据库，业务流量按地域分流。A机房写的数据，得实时同步到B机房。B机房写的数据，也得同步到A机房。听起来简单，做起来全是坑。

我的经验：

双活模式最怕「脑裂」。两个节点互相认为对方挂了，都抢着当主节点。我曾经在凌晨3点被叫起来处理过一次脑裂，两个机房的数据各写各的，最后花了整整一天才把数据合并回来。所以，双活一定要配一个靠谱的仲裁机制，比如用ZooKeeper或者etcd来做选主。

双活的优点很明显：资源利用率高，故障时切换几乎无感。但缺点也扎心——架构复杂度翻倍，运维成本直线上升。你想想看，本来维护一套系统，现在得维护两套，还得保证它们之间的数据一致性。

多副本模式，我习惯叫它「数据冗余」。跟前面两种模式不同，多副本关注的是数据本身，而不是服务节点。

举个例子，HDFS默认把每个数据块存3份。一份在本地机架，一份在同机架的另一台机器，一份在别的机架。为什么要这么折腾？因为硬盘会坏，机器会挂，甚至整个机架都可能断电。

多副本的典型实现：

我记得有一次帮一个客户做数据恢复。他们的MySQL用了异步复制，主库磁盘坏了，从库差了最后5分钟的binlog没来得及同步。客户问我能不能找回那5分钟的数据，我只能摇头。从那以后，我自己的项目里，核心业务一律用半同步复制。

注意：

多副本不是越多越好。副本多了，写入延迟会上升，存储成本也会翻倍。我一般建议：核心数据3副本，普通数据2副本，日志类数据1副本就够了。

说了这么多，咱们用一张表来总结一下：

维度	主备模式	双活模式	多副本模式
资源利用率	低（备机闲置）	高（两台都干活）	中（副本只读或备用）
故障切换速度	慢（需要切换）	快（无需切换）	视实现而定
数据一致性	容易保证	难（脑裂风险）	取决于复制策略
架构复杂度	低	高	中
适用场景	中小系统、预算有限	高可用、低延迟要求	数据持久化、容灾

聊完具体模式，咱们再往大了看看。冗余设计到底值不值得做？我的答案是：值得，但别盲目。

优点：

缺点：

我的建议：

别一上来就搞双活或多副本。先问问自己：我的系统允许多久的停机？数据丢了能接受吗？如果答案是「停机5分钟可以接受，数据不能丢」，那主备模式加半同步复制就够用了。别为了炫技把架构搞复杂，最后运维的人是你自己。

好了，关于冗余设计模式，今天就聊到这儿。下一章咱们讲讲限流和降级，那又是另一套保命手段了。