分布式系统之CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

 

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：保证每个请求不管成功或者失败都有响应。
• 分区容错性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。

用 Redis Cluster 高可用架构举例：Redis 会将数据分片到多个实例 (按照 slot 存储) 中，即一个机房分担一部分数据。Master 负责写，Master 会自动同步到 Slave。

 Master 负责写， 并会自动同步到 Slave，如果 Master 写服务宕机，Slave 读服务会被提升为 Master ，这样设计是为了提高可用性（A）和容错性（P）。系统准许你一台机器或者整个机房都宕机，系统仍然能用。

但是你会发现，Master 1 的数据同步到 Slave2 上是跨机房，这样一来 Slave2 负责的读就会有延迟，Master1 要更新的数据还没有同步到他在另一个机房的备份前，读操作就是不一致的，这样设计显然是牺牲掉一致性（C）。

进一步分析，让同一组 Master - Slave 放在一个机房，同机房复制数据不是更快？这样能不能缓解数据一致（C）问题，答案是能，还有更好的解决一致性的办法就是不要 Master - Slave 组合，就一台机器，一台机器同时担任读写请求，没有延迟不存在数据一致性问题。这是时候如果宕机了怎么办？这样的架构下，那就真的是不可用了，解决了一致性（C）却牺牲了可用性（A）和容错性（P），太不划算了。

 

etcd通过raft共识算法保证一致性（C）和容错性（P），牺牲了可用性（A）：

• 通过二阶段提交，保证了数据的强一致性
• 通过备份机制保证了容错性
• 在网络发生分区时，牺牲了部分节点的可用性