标签：可用性 CAP Base 分布式系统 一致性 数据 节点
| # CAP理论 |
|---|
| 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 |
标签：可用性,CAP,Base,分布式系统,一致性,数据,节点 来源： https://www.cnblogs.com/EricRaw/p/15200938.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。