事务--01---CAP理论、 BASE 理论

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

CAP理论

背景:

2000 年 7 ⽉，加州⼤学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2年后，麻省理⼯学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 理论正式成为分布式计算领域的公认定理。

CAP 定理

⼀个分布式系统最多只能同时满⾜⼀致性（Consistency）、可⽤性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

1) ⼀致性（Consistency）

• ⼀致性指 “all nodes see the same data at the same time”，即更新操作成功并返回客户端
  完成后，所有节点在同⼀时间的数据完全⼀致。

2) 可⽤性（Availability）

• 可⽤性指“Reads and writes always succeed”，即服务⼀直可⽤，⽽且是正常响应时间。

3) 分区容错性（Partition tolerance）

• 分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或⽹络分区故障的时候，仍然能够对外 提供满⾜⼀致性或可⽤性的服务。
• 避免单点故障，就要进⾏冗余部署，冗余部署相当于是服务的分区，这样的分区就具备了容错性。

Consistency 一致性

一致性是指从系统外部读取系统内部的数据时，在一定约束条件下相同，即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同，可以将一致性的分类为如下几种：

• 强一致性：（strong consistency）
  任何时刻，任何用户都能读取到最近一次成功更新的数据。
• 单调一致性：（monotonic consistency）
  任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。
• 会话一致性：（session consistency）。
  任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值，会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。
• 最终一致性：（eventual consistency）
  用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。
• 弱一致性：（weak consistency）
  用户无法在确定时间内读到最新更新的值。

Availability 可用性

可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间.

• 对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的。
  
• 通常我们描述一个系统的可用性时，我们说淘宝的系统可用性可以达到5个9，意思就是说他的可用水平是99.999%，即全年停机时间不超过 (1-0.99999)36524*60 = 5.256 min，这是一个极高的要求。
• 好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。一个分布式系统，上下游设计很多系统如负载均衡、WEB服务器、应用代码、数据库服务器等，任何一个节点的不稳定都可以影响可用性。

CAP 权衡

通过CAP理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？

1.CA

首先在分布式环境下，网络分区是一个自然的事实。因为分区是必然的，所以如果舍弃P，意味着要舍弃分布式系统。那也就没有必要再讨论CAP理论了。

这种情况在分布式系统中几乎是不存在的。

• 所以，对于一个分布式系统来说。P是一个基本要求，CAP三者中，只能在CA两者之间做权衡，并且要想尽办法提升P。

2.CP

如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。

• 一个保证了CP而一个舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。

CP案例:

设计成CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。

• Redis
• HBase
• Zookeeper也是在CAP三者之中选择优先保证CP的。

Zookeeper 进行leader选举时集群都是不可用

3.AP

要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

AP案例:

所以，对于很多业务系统来说，比如淘宝的购物，12306的买票。都是在可用性和一致性之间舍弃了一致性而选择可用性。

• 淘宝的购物
• 12306的买票
  你在12306买票的时候肯定遇到过这种场景，当你购买的时候提示你是有票的（但是可能实际已经没票了），你也正常的去输入验证码，下单了。但是过了一会系统提示你下单失败，余票不足。这其实就是先在可用性方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，会影响一些用户体验，但是也不至于造成用户流程的严重阻塞。

舍弃的只是强一致性。退而求其次保证了最终一致性

很多网站牺牲了一致性，选择了可用性，这其实也不准确的。就比如上面的买票的例子，其实舍弃的只是强一致性。退而求其次保证了最终一致性。也就是说，虽然下单的瞬间，关于车票的库存可能存在数据不一致的情况，但是过了一段时间，还是要保证最终一致性的。

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。

适合的才是最好的

• 上面介绍了如何CAP中权衡及取舍以及典型的案例。孰优孰略，没有定论，只能根据场景定夺，适合的才是最好的。

涉及到钱财,C必须保证

对于涉及到钱财这样不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务，这是保证CA，舍弃P。比如前几年支付宝光缆被挖断的事件，在网络出现故障的时候，支付宝就在可用性和数据一致性之间选择了数据一致性，用户感受到的是支付宝系统长时间宕机，但是其实背后是无数的工程师在恢复数据，保证数数据的一致性。

还有⼀种是保证 CP，舍弃 A。例如⽹络故障是只读不写。

BASE 理论

• eBay 的架构师 Dan Pritchett 源于对⼤规模分布式系统的实践总结，在 ACM 上发表⽂章提出BASE 理论，BASE理论是对 CAP 理论的延伸，核⼼思想是即使⽆法做到强⼀致性（Strong Consistency，CAP的⼀致性就是强⼀致性），但应⽤可以采⽤适合的⽅式达到最终⼀致性（Eventual Consitency）。

核⼼思想: 是即使⽆法做到强⼀致性（Strong Consistency，CAP的⼀致性就是强⼀致性），但应⽤可以采⽤适合的⽅式达到最终⼀致性

1.基本可⽤（Basically Available）

基本可⽤是指分布式系统在出现故障的时候，允许损失部分可⽤性，即保证核⼼可⽤

• 电商⼤促时，为了应对访问量激增，部分⽤户可能会被引导到降级⻚⾯，服务层也可能只提 供降级服务。这就是损失部分可⽤性的体现。

双11当天,0点时,退货,注册,评论等功能是关闭的

2.软状态（Soft State）

软状态是指允许系统存在中间状态，⽽该中间状态不会影响系统整体可⽤性。分布式存储中⼀般⼀份数据⾄少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。

• mysql replication 的异步复制也是⼀种体现。
• Zookeeper在数据同步时,追求的并不是强⼀致性，⽽是顺序⼀致性

3.最终⼀致性（Eventual Consistency）

最终⼀致性是指系统中的所有数据副本经过⼀定时间后，最终能够达到⼀致的状态。弱⼀致
性和强⼀致性相反，最终⼀致性是弱⼀致性的⼀种特殊情况。

Zookeeper追求的⼀致性

Zookeeper是保证CP的, 但在数据同步时，追求的并不是强⼀致性，⽽是顺序⼀致性（事务id的单调递增）。

1.不能保证每次服务请求的可用性。

• 任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。所以说，ZooKeeper不能保证服务可用性。

2.进行leader选举时集群都是不可用。

• 在使用ZooKeeper获取服务列表时，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s,且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。

3.Zookeeper实现的是顺序⼀致性

• 每一个服务器的事务id是单调递增的
• Zookeeper服务器在同一个事务id顺序里面,数据是一致的.