分布式技术栈–CAP理想到BASE现实

引言

分布式技术是互联网的基石。特别是对于亿级访问网站，单机后台远不能满足需求，分布式技术提供了多机、多级负载均衡和水平伸缩的技术可能。但是分布式系统相对于单机系统，业务交互变得更加复杂和不确定性。

1 CAP理想

分布式面临的问题域，归纳起来主要分为三点：一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）。这也是分布式需要解决的三个问题，以首字母开头，又称CAP理论。

1.1 一致性

数据在一个副本更新了，其他副本都要得到跟新。主要可分为强一致性和弱一致性，其中CAP理论中的一致性是指强一致性。
强一致性
强一致性是指对数据的任何一个副本的修改，都会立即同步到整个系统，后续请求都是最新数据；如同操作同进程数据的一致性。强一致性对并发和可用性提出挑战，基本很难同时满足强一致性、可用性和分区容错。
弱一致性
弱一致性是对数据的副本的修改，不确保同步到整个系统，后续请求未必是最新数据。就是无需一致性，这是最容易实现的。

1.2 可用性

系统提供的服务一直处于可服务状态，每次请求都能获取到非错的响应。

1.3 分区容错性

当系统中有节点因网络原因无法通信时，系统依然可以继续运行。

1.4 CAP权衡

仔细分析CAP理论，在现实中是无法同时三者兼顾的，所以通常三者舍一存二。
CA without P
同时要求强一致性和可用性。但是这时就不再是分布式系统，而是单机系统了！所以分布式是不可能不考虑分区容错。
CP without A
牺牲可用性、同时满足强一致和分区容错是可行的，很多分布式关系数据库的分布式事务就是这种。
AP wihtout C
牺牲强一致性、同时满足高可用和分区容错也是可行的，很多NoSQL就是这种模型。

2 BASE现实

由于CAP无法同时满足，理想丰满、现实骨干。于是BASE原则成了CAP的中庸选择，即基本可用(Basically Availble)、软状态/柔性事务(Soft-state)、最终一致性(Eventual Consistency)。

2.1 基本可用

分布式系统在出现不可预知故障的时候，允许损失部分可用性。
相对于CAP要求的系统可用，这里强调的是允许部分不可用。例如当某个区域的服务器宕机后，允许这个区域的用户出现不可用，但其他大部分区域是可用的，在CAP理论中这是不允许的。又如电商网站在一些节日大促购物高峰的时候，为确保购物系统的稳定性，部分消费者可能会被引导到一个降级页面(例如没有商品评论数据的页面)。

2.2 软状态/柔性事务

允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
软状态是一种弱一致性要求。例如分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现；此外，某些时刻副本数目可能大于或小于三也是软状态的表现。

2.3 最终一致性

系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
最终一致性是弱一致性的特例、强弱一致性的中庸结果；也是软状态的终极目标。例如分布式存储中的副本数虽然某个时刻有波动，但是最终会达到稳定数目状态。