| 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，National University of Singapore的Seth Gilbert和Massachusetts Institute of Technology的Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。 |
|
| ## CAP理论概述： |
|
| 一个分布式系统最多只能同时满足一致性、可用性和分区容错性这三项中的两项。 |
|
| #### Consistency:一致性 |
|
| 指的是“all nodes see the same data at the same time”,即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一样，指的是数据的一致性。 |
|
| 对于一致性，可以分为从客户端和服务端两个不同的视觉。从客户端来看，一致性指的是并发访问是更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致性。 |
|
| 一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意考虑并发读写的场景。 |
|
| 从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。 |
|
| ###### 三种一致性策略 |
|
| 对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。 |
|
| 如果能容忍后续的部分或者全部访问不到，则是弱一致性。 |
|
| 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。 |
|
| CAP中不能同时满足的一致性指的是强一致性。 |
|
| #### Availability:可用性 |
|
| 可用性指的是“Reads and writes always succeed”,即服务一直可用，而且是正常响应时间。 |
|
| 对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以一般衡量一个系统的可用性的时候，都是通过停机时间来计算的。 |
|
|
|
|
|
|
|
|
|
淘宝的系统可用性可达5个9，意思是可用性水平为99.999%，即全年停机时间不超过 (1-0.99999)*365*24*60 = 5.256 min， |
|
| 好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等不好体验。一个分布式系统，上下游设计很多系统如负载均衡、web服务器、应用代码、数据库服务器、网络等等都会影响可用性。 |
|
| #### Partition tolerance:分区容错性 |
|
| 分区容错性是指“the system continues to operate despite arbitrary message loss or failure of part of the system”。即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 |
|
| 分区容错性和拓展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求应用虽然是分布式应用，但运行起来像一个整体。比如有个别的web服务器或者数据库服务器宕机了，各部分的系统仍能正常运行。 |
|
| ## CAP取舍 |
|
| ### CA without P |
|
| 即舍弃分区容忍性，这个是不存在的。因为分布式环境，网络分区是一个事实。关系型数据库就是保证了可用性和数据一致性。一旦关系型数据库要主备同步（异地灾备），集群部署等就要把P考虑进来。 |
|
| 所以对于一个分布式系统，P是一个基本的要求，CAP三者之间只能在CA之间做权衡。 |
|
| ### CP without A |
|
| 如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。 |
|
| 一个保证了CP而舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户体验，等到所有数据一致后再让用户访问。比如Redis、HBase和Zookeeper也是优先保障CP的。 |
|
| ### AP without C |
|
| 需要高可用并允许分区，则需要放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。 |
|
| 这种情况会发生在淘宝、京东、12306的购买商品上，查看的时候显示有商品，到实际下单的时候却发现商品买完了。 |
|
|
|
| ## 按实际业务进行取舍 |
|
| 技术有没孰优孰劣之分，需要根据实际业务与业务相契合的方案。 |
|
| # Base理论 |
|
| Base是Ebay的架构师Dan Pritchett于2008年在CAP的基础上提出的理论。Base理论的核心思想是即便无法做到强一致性，但每个应用都可以根据自身业务的特点，使用适当的方法来使系统达到最终一致性。 |
|
| Base理论是由Basically Available(基本可用)、Soft State(软状态)和Eventually Consistent(最终一致性)缩写而成。 |
|
| ### Basically Available:基本可用 |
|
| 基本可用是指分布式系统出现了不可预知的严重故障(如服务器宕机，部分网络中断)，但还是能用的。 |
|
| 相比正常的系统而言： |
|
| 1. 响应时间上会延长：正常情况的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可能需要2秒以上 |
| 2. 功能上的损失：比如在双11等电商促销期遇到服务器宕机了，只能保证80%的客户能正常访问。（现在有kubernetes云服务器的自动扩容技术，这种故障会越来越少见） |
|
| ### Soft State:软状态 |
|
| 软状态是相对ACID中的原子性而言的。 |
|
| 原子性要求多个节点的数据副本都是一致的，这是一种“硬状态”。比如关系型数据库，集群中的redis和Zookeeper,每个节点中的数据副本都是强一致性的。 |
|
| 软状态是指：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本不一致，存在数据延时。比如mysql的异步复制(Asynchronous replication) |
|
| ### Eventual Consistency:最终一致性 |
|
| 上面说的软状态不能一直是软状态，必须有一个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制、方案设计等因素。 |
|
| ##### 因果一致性 Causal consistency |
|
| 因果一致性指：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。与此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。 |
|
| ##### 读己之所写Read your writes |
|
| 读己之所写指：节点A在更新完一个数据，它自身总是能访问到自身更新过的最新值，而不会看到旧值。 |
|
| ##### 会话一致性Session consistency |
|
| 会话一致性指：对系统数据的访问过程框定了在一个会话当中；系统能保证在同一个有效会话中实现“读己之所写”的一致性。也就是说，执行更新操作后，客户端能够在同一个会话中始终读取到该数据的最新值。 |
|
| ##### 单调读一致性Monotonic read consistency |
|
| 单调读一致性指：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不会返回更旧的值。 |
|
| ##### 单调写一致性Monotonic write consistency |
|
| 单调写一致性指：系统能够保证来自同一个节点的写操作被顺序地执行。 |
|
| ### 总结：互联网商城主要以Base理论作为分布式的基础理论 |
|
| 参考资料： |
|
| [1] Towards Robust Distributed Systems, Eric Brewer, 2000 （CAP理论起源原文） |
|
| [2] Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web, Seth Gilbert&Nancy Lynch, 2002 （CAP验证原文） |
|
| [3] [Base: An Acid Alternative |
| In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability](https://queue.acm.org/detail.cfm?id=1394128), Dan Pritchett, 2008 （Base理论原文） |
|
| [4] [分布式系统的CAP理论], Hollis,2015 |