📚 课程目录第1章副本机制概述

1. 副本机制概述

副本机制，说白了就是「多存几份」。你想想看，一个系统里只有一份数据，那这台机器挂了，数据就丢了，服务也就停了。多存几份，一台挂了还有别的顶上。

我刚开始做分布式系统时，总觉得副本就是简单的「复制粘贴」。后来踩了不少坑才明白——副本机制是分布式系统的基石，也是很多复杂问题的根源。今天咱们就来聊聊，副本到底是什么，它带来了什么好处，又付出了什么代价。

副本（Replica），就是数据的多个拷贝。每个拷贝都包含相同的数据内容，分布在不同的物理节点上。

举个例子：你有一张用户表，里面有 100 万条记录。如果只放在一台机器上，那叫单点。如果把这 100 万条数据复制到 3 台机器上，每台都存一份完整的，这就是 3 副本。

核心定义：副本 = 数据的冗余拷贝，分布在不同的故障域（机器、机架、机房）中。

副本的粒度可以不同。可以是整个数据库的副本，也可以是一个分片（shard）的副本，甚至是一条记录的副本。不同的系统有不同的选择，但本质都一样——用空间换时间，用冗余换可靠。

副本不是白存的，它解决了三个核心问题。我按重要性排个序：

系统不能因为单点故障就不可用。这是副本最直接的作用。

我记得有一次线上事故，一台数据库服务器硬盘坏了。幸好我们有 3 副本，客户端自动切换到另一台，业务几乎无感知。如果只有单副本，那至少得停机恢复几个小时。

高可用的核心指标是可用性百分比：

当然，这只是理论值。实际还要考虑网络分区、副本同步延迟等因素。

容错和高可用是两回事。高可用是说「系统还能用」，容错是说「系统能容忍错误」。副本让系统在部分节点失效时，仍然能正确提供服务。

我曾经遇到过一个场景：机房断电，整个机柜的机器都挂了。因为副本分布在不同的机柜，甚至不同的机房，所以数据没丢，服务也没中断。这就是容错的价值。

容错能力取决于副本的分布策略：

我的建议：生产环境至少 3 副本，且分布在不同的故障域。2 副本其实很尴尬——一台挂了，另一台的压力翻倍，很容易也挂掉。

副本不仅能提高可靠性，还能提升读性能。你想想看，读请求可以分散到多个副本上，每个副本分担一部分流量。

举个例子：一个系统每秒有 10 万次读请求。单台机器扛不住，但如果有 5 个副本，每台只需要处理 2 万次。这就是水平扩展。

不过要注意，写性能反而会下降。因为每次写入都要同步到所有副本。这个矛盾，后面会详细讲。

副本不是免费的午餐。每多一份副本，就多一份成本。我把它总结为「三座大山」：

这个最直观。3 副本就是 3 倍的存储空间。100TB 的数据，3 副本就需要 300TB 的磁盘。

我见过一个团队，为了省钱只做 2 副本。结果一次磁盘故障，数据恢复花了 3 天。省下的存储成本，全赔在运维上了。

这是最头疼的。多个副本之间，数据必须保持一致。但网络有延迟，节点可能故障，怎么保证所有副本的数据一模一样？

强一致性要求所有副本同步完才返回成功。这会导致写入延迟很高。弱一致性允许副本之间暂时不一致，但读到的可能是旧数据。

我曾经在一个支付系统里，因为选择了弱一致性，导致用户看到余额和实际余额差了 5 分钟。虽然最终一致了，但用户体验很差。后来改成了强一致性，写入慢了 30%，但再也没出过问题。

避坑指南：一致性不是越强越好。强一致性会降低可用性（CAP 定理）。要根据业务场景选择合适的一致性模型。金融交易要强一致，社交动态可以弱一致。

副本同步需要网络带宽。数据量越大，副本越多，网络压力越大。而且副本之间的数据对比、修复、重新均衡，都需要计算资源。

我见过一个极端案例：某个系统副本数从 3 增加到 5，网络带宽直接打满，正常业务都受影响。最后不得不限流，分批同步。

下面这张图，把副本机制的核心脉络梳理清楚了：

这张图把副本机制拆成了三个维度：定义、作用和代价。作用又细分为高可用、容错、性能扩展；代价则包括存储成本、一致性开销、网络与计算开销。底部的说明框点出了核心权衡——副本不是越多越好，要在可靠性与成本之间找到平衡。

嗯，这就是副本机制的全貌。后面我们会深入每个细节，看看不同的一致性模型怎么选，副本同步策略怎么设计，以及实际项目中怎么权衡这些因素。