第五章数据复制这一章进入分布式数据的第一站。核心问题是同一份数据放在多台机器上如何保持一致Kleppmann 的论点是复制带来可用性、低延迟和可扩展性但代价是一致性难题——而不同的复制模型本质上是在一致性与可用性之间做不同程度的妥协。本章结构先讲三种复制模型单主、多主、无主再讲复制滞后带来的各种一致性保证最后讲多主和无主复制中的冲突处理。一、为什么需要复制复制Replication指在通过网络连接的多个节点上保存同一份数据的副本。动机有三高可用性一个节点挂了其他节点还能服务低延迟把数据放在离用户近的地方可扩展性读请求可以分散到多个副本核心权衡复制带来好处但也引入了一个根本问题当一个副本更新时其他副本如何跟上如果跟不上读到的就是旧数据。这就是一致性问题也是本章的主线。二、三种复制模型1. 单主复制Single-Leader Replication也叫主从复制Master-Slave、主动-被动复制。工作方式所有写请求发送到主节点Leader主节点写入本地存储并把变更发送给从节点Follower从节点按顺序应用变更读请求可以发送到主节点或从节点优点简单无写冲突广泛使用MySQL、PostgreSQL、MongoDB、Kafka缺点主节点是写瓶颈主节点故障需要切换failover同步 vs 异步复制同步主节点等从节点确认后才返回成功优点从节点保证有最新数据缺点一个从节点慢整个写入就慢异步主节点立即返回不等从节点优点写入快缺点主节点故障可能丢数据半同步折中等至少一个从节点确认实际选择全同步太慢全异步可能丢数据常见做法半同步或异步 监控从节点故障基于日志的复制从节点记录已处理的日志位置故障恢复后从该位置继续主节点故障Failover这是分布式系统中最棘手的问题之一确认主节点真的挂了超时网络分区无法区分选举新主节点通常由共识算法如 Raft完成重新配置系统客户端、从节点都要知道新主节点处理旧主节点可能还有未复制的写入常见问题脑裂Split-brain两个节点都认为自己是主节点丢数据旧主节点未复制的写入丢失超时设置太短导致误切换太长导致服务中断2. 多主复制Multi-Leader Replication也叫主动-主动复制Active-Active。工作方式多个节点都可以接受写入每个主节点把变更发送给其他主节点读可以从任意主节点优点写可用性高一个主节点挂了其他还能写适合多数据中心每个数据中心有本地主节点写入本地异步同步缺点写冲突两个主节点同时修改同一数据冲突解决复杂使用场景多数据中心部署离线客户端如日历、笔记应用协同编辑如 Google Docs冲突处理策略避免冲突让同一数据的写入路由到同一主节点最后写入胜出LWW用时间戳但时钟不可靠自定义逻辑应用层合并CRDT无冲突复制数据类型数学上保证可合并冲突检测自动检测困难通常需要应用层参与3. 无主复制Leaderless Replication也叫去中心化复制。工作方式没有主节点客户端直接写多个副本读也从多个副本读代表Dynamo、Cassandra、RiakQuorum 机制设 n 个副本写入需 w 个确认读取需 r 个节点只要 w r n读到的数据一定包含最新写入例如 n3, w2, r2写入 2 个读取 2 个必有重叠常见配置n3, w2, r2平衡n3, w3, r1写慢读快n3, w1, r3写快读慢读写修复Read Repair读取时发现副本不一致修复旧副本反熵Anti-Entropy后台进程定期比较副本同步差异无主复制的挑战冲突处理同多主需要版本向量检测并发写入Quorum 不保证线性一致性三、复制滞后与一致性保证单主复制中如果读从节点可能读到旧数据。这就是复制滞后Replication Lag。Kleppmann 提出了一系列一致性模型从弱到强1. 写后读一致性Read-After-Write Consistency保证用户写完自己再读一定能读到自己的写实现读自己的写时从主节点读或记录用户最后写入的时间戳只读更新的副本注意跨设备时不适用2. 单调读Monotonic Reads保证用户读到新数据后不会再读到旧数据实现同一用户固定读同一副本对比没有它用户可能时光倒流3. 一致前缀读Consistent Prefix Reads保证因果相关的写入按顺序被看到问题分区后不同分区的因果顺序可能错乱实现把因果相关的数据放在同一分区4. 最终一致性Eventual Consistency保证停止写入后所有副本最终会一致问题最终是多久没有上限适用对一致性要求不高的场景一致性强度谱系强一致性线性一致性 ↑ 顺序一致性 ↑ 因果一致性 ↑ 写后读 / 单调读 / 一致前缀读 ↑ 最终一致性四、多主与无主复制中的冲突1. 冲突的类型写-写冲突两个节点同时修改同一数据读-写冲突读的同时有写2. 冲突解决策略1最后写入胜出LWW用时间戳取最新问题时钟不可靠可能丢数据代表Cassandra 默认2版本向量Version Vectors记录每个节点的版本号检测并发写入需要应用层合并3CRDT数学结构保证合并可交换、可结合例子G-Counter、PN-Counter、OR-Set代表Riak、Redis4应用层解决最灵活但复杂例子购物车合并取并集3. 冲突的根源多主和无主复制允许并发写入网络分区导致副本之间无法通信时钟不同步导致 LWW 不可靠五、复制模型的对比维度单主多主无主写节点一个多个任意写冲突无有有写可用性低主节点挂高高读一致性可强弱弱Quorum 可调复杂度低高中代表MySQL、PG多数据中心Cassandra、Dynamo适用通用多数据中心、离线高可用、写密集六、本章的核心思想总结主题核心观点复制模型单主最简单多主/无主可用性高但需处理冲突同步 vs 异步同步保证一致但慢异步快但可能丢数据Failover分布式系统最棘手问题之一脑裂和丢数据风险一致性保证写后读、单调读、一致前缀读、最终一致性冲突处理LWW、版本向量、CRDT、应用层Quorumw r n 保证读到最新但不保证线性一致三个贯穿全书的判断复制是一致性与可用性的权衡越强的一致性越低的可用性和越高的延迟。没有免费的高可用多主和无主复制提高了写可用性但引入了冲突处理复杂度。一致性是谱系而非二元从强到弱有多种模型选哪个取决于业务需求。七、这一章在全书中地位第五章是分布式数据的第一章为后续铺路第六章数据分区复制和分区通常结合使用每个分区有多个副本第七章事务复制滞后导致的一致性问题需要事务隔离级别来约束第八章分布式系统挑战网络、时钟、进程暂停是复制问题的根源第九章一致性与共识线性一致性和共识算法是复制问题的终极答案一句话概括本章数据复制是分布式系统的基石。单主复制简单但写可用性低多主和无主复制可用性高但需处理冲突。复制滞后带来一系列一致性问题从写后读到最终一致性构成了一个从强到弱的谱系。理解这些模型和保证才能在实际系统中做出正确选择。