一篇文章搞懂CAP理论

C : 一致性。任何的读写都应该看起来是“原子”的，或串行的。写后面的读一定能读到前面写的内容。所有的读写请求都好像被全局排序。

A：可用性。对任何非失败节点都应该在有限时间内给出请求的回应。

P：分区容忍性。允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失。

        《深入分布式缓存》这本书毕竟主要是写缓存的，分布式理念都是点到为止，但这里CAP我觉得还是比较重要的，个人做下自己的理解分析(个人理解可能有毒鸡汤，如有发现还请指出)：

        CAP是分布式系统设计理论，所以在进行架构设计时，整个系统要么选择CP，要么选择AP（分布式系统分区必然会出现，所以严格上CA并不能贯穿，因而都不被考虑）。但在实际设计过程中，如果从整个系统的角度去选择CP还是AP，就会发现顾此失彼，无论怎么做都是有问题的。所以我个人认为：CAP应该称之为分布式数据取舍设计理论。是根据数据类型划分做的分布式系统设计。每个系统不可能只处理一种数据，而是包含多种类型的数据，有的数据必须选择CP，有的数据必须选择AP。举个例子：

        以会员系统为例，会员系统包含账号数据（用户ID、密码）、会员信息数据（兴趣、爱好、性别、自我介绍等）。通常情况下，会员账号数据需要选择CP（分区一致性<数据出现分区，但该数据必须一致，加锁执行数据更新与同步，放弃更新期间的可用性>），而会员信息数据会选择AP（分区可用性<数据出现分区，但该数据可以暂时不一致，保证可用性>场景：例如有AB两个节点，发生了分区现象，用户请求A节点将爱好改为“篮球”, 后面又请求了次，落在B节点，将爱好改为"游泳"。这样访问A节点，爱好为“篮球”，访问B节点爱好为“游泳”），如果限定整个系统为CP，则不符合会员信息数据的应用场景；如果限定整个系统为AP，则又不符合会员账号数据的应用场景。

        几乎看过的所有书和教学视频都说分布式项目CA是无法保证的。如果站在系统稳态层面去分析，P分区现象一定会出现，所以CA确实无法贯穿。但如果站在系统暂态层面去分析，因为在系统整个运行周期中，大部分时间都是正常的，发生分区现象的时间并不长。而当系统处于非分区状态下时，我们是可以保证CA的。所以我们可做一些操作，从而让分区故障在一定时间后自修复，使系统重新达到CA的状态，这里base理论便是很好的补充。

base : 基本可用 : 分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

软状态 : 允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是CAP理论中的数据不一致。

最终一致性 : 系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

基本可用：我认为这是对CP理论的延伸。就是在涉及核心业务时（账号密码修改后的用户登录）,放弃部分业务的可用性（用户爱好的数据不一致）。

软状态 : 这根本就是AP理论的描述，比如：爱好同时存在“篮球”,“游泳”两个数据。

最终一致性 : 这就是AP理论的延伸了。比如：爱好数据在当天0点所有节点间做数据同步，以一定策略，比如更新时间最近的数据为准。将所有节点的数据同步。

综上所述：我们的设计目标就是：1.优先保证核心业务可用。2.在满足1的前提条件下，尽量保证非核心业务可用性。3.数据最终一致性（相当于系统数据的自修复）。

转载于:https://my.oschina.net/u/4075510/blog/3007744