分布式CAP定理和BASE定理

CAP定理

目前的大型网站系统几乎都是分布式的，而分布式系统难以实现整个系统的强一致性。
1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：

• Consistency 一致性
• Availability 可用性
• Partition Tolerance 分区容错

Eric Brewer表示这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
原文见参考资料，有图解。

C 一致性

一致性指标要求用户的读写操作始终正确，即写入的数据在读出来时与写入时一致。
可以理解为主库写入从库读出时需要保证从库已同步主库数据。

A 可用性

可用性指标要求每个正常请求必须有正常的响应，不可忽略。
可以理解为像主库从库请求，都得返回正常响应。

P 分区容错

由于分布式系统的特性，服务器间的通信可能出现异常，分区容错指标需要兼容这种异常情况。
可以理解为主从库网络断连，要兼容主库写入而从从库读的情况。

Eric Brewer证明不可兼容

假设C、A、P同时满足，即读写结果正确、请求有正常响应、分区容错。
验证流程：

1. 客户端将数据写入主库
2. 主库与从库网络断连，同步失败
3. 客户端从从库读数据

此时分区容错如果不能保证，系统就崩了；
如果要保证读写结果始终正确，就不能在从库返回，因为从库不知道正确结果；
如果要返回结果，那结果肯定不正确；
综上，CAP无法同时保证。

CAP如何取舍

在分布式系统中，一般而言网络（或节点）出现问题是常态，系统崩溃是不能接受的，所以分区容错是必须要保证的。
在此基础上，只能从C.一致性和A.可用性中作出取舍。

CA舍弃P
单点系统基本是这样，但不分区不能算分布式系统了。

CP舍弃A
保证强一致性舍弃可用性，那么在网络异常期间服务（或部分服务）可能不可用。

AP舍弃C
保证可用而舍弃强一致性，在网络异常期间服务可以正常使用，但数据可能不是实时同步的而是本地旧数据。

可见，总要舍弃一个的时候，保证AP舍弃C是比较合理且使用范围比较广的。在这种情况下，服务在异常期间始终保持可用，但局部数据不一致；在异常结束后数据可以恢复一致。
绝大多数分布式网站系统在三者中的取舍是 P.分区容错>A.可用>C.数据强一致，因为很多时候短时间数据不一致对于用户而言是可接受的。
一些特殊系统比如金融行业等的分布式系统，可能对数据强一致要求比较高，在无法全部保证时会舍弃可用性，暂停服务。

BASE定理

在CAP定理的基础上，延伸出比较现实的用于保证分布式系统高可用的BASE定理。
BASE是指服务保证基本可用（Basically Available），可以存在软状态（Soft State），最终能够达到一致性（Eventual Consistency）。
BASE定理是当前分布式系统牺牲强一致性确保高可用的支撑思路。

Basically Available 基本可用

出现系统故障时，允许服务部分不可用。
比如在某网站点了个赞，但是5秒之后才出现反馈，而且是“服务异常请重试”。这表示服务确实有异常，但并非完全不可用——至少还有反馈。

Soft State 软状态

允许系统存在可用的中间状态。
即允许在数据同步期间，用户的同一请求得到的数据不同（但服务整体还可用），因为处理请求的服务的数据同步状态可能不同。

Eventual Consistency 最终一致

强调系统数据最终能够达到一致状态，相对强一致性的系统，这是一种弱一致性。
也就是说虽不要求实时一致的数据同步，但最终应当进入一致状态。

总结

分布式CAP定理和BASE定理启发我们，分布式系统的理想状态是无法实现的。但我们可以做出取舍，设计出高可用兼顾部分一致性的分布式系统：

• 分布式系统需要保证P.分区容错
• 当CAP无法全部满足时，在CA中取舍，但舍并不代表完全不要
• 对于我等Web开发而言，尽量保证A.可用性，但并不代表必须100%保证可用，也并不代表不需要保证C.一致性
• 尽量保证异常状态下系统基本可用
• 尽量保证中间状态下系统可用

参考资料

An Illustrated Proof of the CAP Theorem
分布式系统原理九：CAP理论和BASE理论 | 成长之路

本文搬自我的博客，欢迎参观！