CAP理论
概述CAP定义CAP理论的三选二的艰难抉择CA，AP，CP的实践者CAP的小结 base理论
概述base定义base与ACIDbase小结
原文请移步这里 【技术杂记】如何正确的理解CAP和base理论？
CAP理论概述
CAP原理是现在分布式系统的基石，好比是分布式领域的牛顿定律。所有的分布式系统都是基于CAP理论来考虑和设计的
In 2002, Seth Gilbert and Nancy Lynch of MIT published a formal proof of Brewer’s conjecture. The theorem states that networked shared-data systems can only guarantee/strongly support two of the following three properties
CAP理论的核心重点就是描述了一个分布式系统最多满足以下三个特征中的两个，所以在学习分布式系统和设计之前，我们必须了解和理解什么是CAP理论
CAP定义
Consistency（一致性，强一致性）
在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新 *** 作后，应该保证系统的数据仍然处于一致的状态。对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据更新成功后，却没有使其它的副本节点进行同步更新，造成后续读取的依旧是老数据（或称为脏数据）进而引起业务异常，这就是典型的分布式不一致的情况。在分布式系统中，如果能够做针对一个数据项的更新 *** 作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性。
Availability（可用性）
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个 *** 作请求总是能够在有限的时间内返回结果。这里的重点是"有限时间内"和"返回结果"。
有限时间内是指对于用户的一个 *** 作请求，系统必须能够在指定的时间内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。另外，"有限的时间内"是指系统设计之初就设计好的运行指标，通常不同系统之间有很大的不同，无论如何，对于用户请求，系统必须存在一个合理的响应时间，否则用户便会对系统感到失望。
返回结果是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出队请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。
Partition Tolerance（分区容错性）
通俗来讲，当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的，需要增加容错机制，办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。总结就是增加单节点副本来避免网络故障时分区带来的影响。
分区是因为集群节点之前无法通信，比如机房A无法跟机房B通信，从而造成机房A的节点有部分机房B没有的新数据，而机房B的节点也有部分机房A没有的新数据，但碍于无法通信，所以无法数据同步，从而造成数据的分区，每个分区的数据都不完整，只有合并在一起才是一个完整的数据；但情况也不仅限于通信故障，就比如数据同步时间过长，也有可能发生数据分区。
ACID中C与CAP定理中C的区别?
首先我要声明，这两个C肯定是有区别的：
ACID的C指的是事务中的一致性，在一串对数据进行修改的 *** 作中，保证数据的正确性。即数据在事务期间的多个 *** 作中，数据不会凭空的消失或增加，数据的每一个增删改 *** 作都是有因果关系的；比如用户A想用户B转了200块钱，不会出现用户A扣了款，而用户B没有收到的情况CAP的C则指的是分布式环境中，多服务之间的复制是异步，需要一定耗时的，不是即时瞬间完成。所以可能会造成某个节点的数据修改，将修改的数据同步到其他服务需要一定的时间，如果此时有并发请求过来，请求负载均衡到多个节点，可能会出现多个节点获取的数据不一致的问题，因为请求有可能会落在还没完成数据同步的节点上；而C就是为了做到在分布式集群环境读到的数据是一致的；当然这里的C也有分类，如强一致性，弱一致性，最终一致性
即ACID的C着重强调单数据库事务 *** 作时，要保证数据的完整和正确性;
而CAP理论中的C指的是对一个数据多个备份的读写一致性
CAP理论的三选二的艰难抉择
总之CAP的理论核心就是C , A ,P不能共存，只可能三选二，以求最大能保证的有利利益
因为长时间无法达成数据一致性，就可能造成数据分区，所以要满足P，就必须在A和C做出选择：
(不去满足一致性C)即我不追求数据强一致性，在集群节点某时刻出现数据不一致的情况下，我可以去保证分区容错性，容忍分区的出现，之后再做补偿 , 即做到AP(不去满足可用性A)即在可能发生数据分区的时候，在故障解决之前，我去停止集群节点的对外服务，避免出现对数据的增，删，改 *** 作，让数据不被改动，这样就不会导致数据的分区了,做到CP(不去满足分区容错性P)则代表当没有发生数据分区时，系统可以保证A和C，但是如果发生数据分区，因为不满足分区容错，即无法容忍分区的存在，就必定需要A,C二选一，最终只剩A或者C , 即 CA
所以我们可以知道
CA - 单节点系统满足一致性，可用性，因为单节点，自然没有P的问题，但是没有扩展性，非常容易遇到性能瓶颈，其实本质上单节点系统也不需要考虑CAP问题。CP - 满足一致性，分区容错性的系统，通常性能不是特别高，因为为了保证数据强一致性，必须等待所有节点完成数据同步才能对外提供服务。AP - 满足可用性，分区容错性的系统，通常可能对一致性要求低一些，性能高，一般追求最终一致性
从上面看来，P几乎是必不可少的，因为AC最终会退化成A或C，除非选择做一个单节点服务，但这样也就不是分布式集群系统了，CAP理论就没有卵子用了， 所以AC几乎就是一个最不好的选择，所以通常情况下的实践都是在CP或AP中做出选择。
CA，AP，CP的实践者
CA
单点部署的数据库，没有集群环境，必然可以保证数据的可用性和一致性
MySQL一般被归类为CA，但也看设置情况，如果是主从同步复制，基本就符合CA，如果是异步复制，那就不一定满足CA了CP
ZooKeeper就是CP的实践者，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）
Mongodb一般被归类为CPAP
Eureka遵循的就是AP, 因为针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不完全相同，但也并不会造成灾难性的后果，因为对于服务消费者来说，能消费才是最重要的，拿到的服务提供者即使不正错，大不了重试，那也好过因为无法获取服务提供者信息而不能去消费好
CAP的小结
分区是常态，无法避免，CAP三者不可共存，所以必然是三选二可用性和一致性是一对冤家，正是因为要做到高可用，所以才会出现不一致性(就因为存在了多个节点，才会出现数据复制和通信问题)；也正是因为出现不一致性，才可能要停止集群服务，防止出现分区很多情况，一些实践者并不完全的去追求CP或是AP, 他们可能是尽量的去保证可用性，也尽量的去保证一致性，同时又满足一定的分区 base理论
概述
eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出base理论，base理论是对CAP理论的延伸，核心思想就是分布式系统如果无法做到强一致性，那么就要根据自身情况，采用适合的方式让系统做到最终一致性
base理论就是对CAP理论中的一致性和可用性权衡之后的结果，指的就是分布式系统中，如果无法做到强一致性，那么就用最终一致性去代替，让分布式系统满足三个特性
基本可用（Basically Available）软状态（Soft State）最终一致性（Eventual Consistency） base定义
基本可用（Basically Available）
分布式系统如果出现不可预知的故障时，允许损失部分的可用性，但并不是整个系统都不可用，即保证系统核心服务可用即可；比如实际开发中，出现部分服务故障，我们可以让系统的响应时间适当变长，或者限流，降低消费，甚至是服务降级，让某个服务暂时无法提供服务软状态（Soft State）
系统中的数据可以存在中间状态， 并该中间状态不会影响到系统的可用性；换个说法就是允许系统中部分结点的数据同步存在时延问题，但这个时延不会影响到系统的可用性最终一致性（Eventual Consistency）
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到数据一致的状态。既最终一致性的本质是需要系统保证数据的最终一致性，而不每时每刻的强一致性。但也要保证非一致窗口时期不会对系统数据造成危害
base与ACID
ACID是传统数据库常用的设计理念，追求强一致性模型，例如银行的转账场景，最求数据的绝对可靠。而base支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。虽然ACID和base代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此ACID和base又会结合使用
base小结
总的来说，base理论面向的是大型高可用可扩展的分布式系统，是对CAP理论的一些弱化和妥协，为了保证可用性，对强一致性进行了削弱在了解了CAP和base理论之后，就可以自己去了解一下Redis, MongoDB, MySQL这些数据库怎么处理集群状态下的数据复制了，相信这也是一个很好的加深基础的问题；同时也可以去了解一下通常系统是怎么去实现最终一致性的，怎么解决非一致性窗口期间出现一些数据问题
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）