【分布式篇】什么是CAP定理？

要求

CAP 定理

Consistency 一致性：访问分布式系统中任意节点，总能返回一致的结果
- Every read receives the most recent write or an error
Availability 可用性：分布式系统总能向客户端返回响应
- Every request receives a (non-error) response, without the guarantee that it contains the most recent write
Partition tolerance 分区容忍：当分布式系统节点间通信发生了消息丢失或消息延迟，仍然允许系统继续运行
- The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

CAP 定理：最多三选二，无法兼得，通常在 CP 或者 AP 之间做出选择

扫描二维码关注公众号，回复： 15183787 查看本文章

不一致的产生

client 向 Node1 写入新值 v1

写入成功 Node1 更新成 v1

Node1 在没有将变更同步到 Node2 时，就向客户端返回了应答

client 发起向 Node2 的读操作

返回了旧值 v0（不一致）的结果

保证一致性

client 向 Node1 写入新值 v1

写入成功 Node1 更新成 v1，此时不能立刻向 client 返回应答，而是需要将 v1 同步到 Node2

同步 v1 成功

此时才能向 client 返回应答

如果此时 client 再去访问 Node2，不会出现不一致的情况

保 CP 失 A

当发生了网络分区，Node1 与 Node2 已经失去了联系，这时仍想对外提供服务（保 P）

client 向 Node1 写入新值 v1

写入 Node1 成功，但无法同步至 Node2

这时为了保证一致性，Node1 不能向 client 返回应答，造成操作挂起无法完成（失去可用性）

保 AP 失 C

当发生了网络分区，Node1 与 Node2 已经失去了联系，这时仍想对外提供服务（保 P）

client 向 Node1 写入新值 v1

写入 Node1 成功，但无法同步至 Node2

为了保证可用性，向 client 返回了应答（但牺牲了一致性）

一致性级别

CP 和 AP 之间需要做权衡，其实根据需求不同，也可以将一致性划分成几个级别，在这些级别里做一个权衡。

强一致性：系统写入什么，读出来的也会是什么，但实现起来往往对性能影响较大，例如之前 CP 的例子
- 例如：火车站售票，有就是有，没有就是没有，不能出现不一致的情况
- 典型算法：Paxos、Raft、ZAB
弱一致性：系统写入成功后，不承诺立刻可以读到写入的值，也不承诺具体多久后数据能达到一致，还可以细分为：
- 会话一致性，同一个客户端会话中可以保证一致，其它会话不能保证
- 用户一致性，同一个用户中可以保证一致，其它用户不能保证
- 例如：网上购物，在商品详情页看到库存量还有好多，下单的瞬间才被提示“库存量不足”，实际上商品详情页展示的库存并不是最新的数据，只是在某个流程上才会做准确的检查
最终一致性：是弱一致性的特例，保证在一定时间内，能够达到一个一致的状态
- 例如：转账，转账完成后，会有一个提示，您的转账会在 24 小时内到账，一般用户也能接受，但最终必须是一致的
- 典型协议：Gossip