要求

  • 理解 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 之间做出选择

不一致的产生

client 向 Node1 写入新值 v1

【分布式篇】什么是CAP定理?_开发语言

写入成功 Node1 更新成 v1

【分布式篇】什么是CAP定理?_开发语言_02

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

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

client 发起向 Node2 的读操作

【分布式篇】什么是CAP定理?_客户端_04

返回了旧值 v0(不一致)的结果

【分布式篇】什么是CAP定理?_分布式系统_05

保证一致性

client 向 Node1 写入新值 v1

【分布式篇】什么是CAP定理?_分布式系统_06

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

【分布式篇】什么是CAP定理?_分布式_07

同步 v1 成功

【分布式篇】什么是CAP定理?_分布式_08

此时才能向 client 返回应答

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

 

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

保 CP 失 A

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

【分布式篇】什么是CAP定理?_分布式_10

client 向 Node1 写入新值 v1

【分布式篇】什么是CAP定理?_分布式_11

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

【分布式篇】什么是CAP定理?_客户端_12

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

保 AP 失 C

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

【分布式篇】什么是CAP定理?_分布式_13

client 向 Node1 写入新值 v1

【分布式篇】什么是CAP定理?_分布式系统_14

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

【分布式篇】什么是CAP定理?_开发语言_15

为了保证可用性,向 client 返回了应答(但牺牲了一致性)

【分布式篇】什么是CAP定理?_开发语言_16

一致性级别

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

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