分布式系统的CAP理论、BASE理论

 

CAP理论

在一个分布式系统中，

• Consistency（数据一致性）
• Availability（服务可用性）
• Partition tolerance（分区容错性）

三者不可兼得，最多只能同时满足两点，没法三者兼顾。

 

一致性(Consistency)

分布式系统中的数据应该保持一致。

比如用户更改信息，主库执行更改，自动同步到从库，用户再次查询信息时，在从库查到的信息要是修改后的信息，这时数据库主从节点的数据是一致的。

比如A、B各自都有10万元，A转账给B 1万元，要么操作成功A为9万元、B为11万元，要么操作失败A、B都还是10万元，操作前后的数据得对得上。
 

一致性分类

• 强一致性：strong consistency，任何时刻，所有用户都能读取到最近一次成功更新的数据，即所有用户读取到的数据都是最新的。优点是数据一致、数据不会出错，缺点是效率低下。
• 弱一致性：weak consistency，用户读取到的数据不一定是最近一次成功更新的数据（不一定是最新的数据）。
• 最终一致性：eventual consistency，用户最终可以读取到最新的数据。

分布式系统难以保证数据的强一致性，一般都是保证最终一致性。

 

可用性(Availablity)

系统负载过大时，是否还能处理、响应请求，eg. 原来qps（每秒访问量）是1000，现在飙到10000，系统依然扛得住、可用。

可用指的是在正常时间范围内处理完每个请求，不管是让请求快速失败、还是服务降级，都算可用。

 

分区容错性(Partition-torlerance)

一个节点崩溃、故障，其它节点不受影响。

常见的做法是增加机器数量，做集群，少数节点挂掉，集群整体依然可用。

集群节点越多，分区容错性越强，但完成节点间数据同步所需的时间也越长，节点IO压力大，数据一致性越得不到保证（越差）。

 

情况分析

1、满足AC，不满足p

满足A=>在指定时间内处理完请求，满足C=>完成节点间的数据同步

要在指定时间内处理完请求、并完成数据同步，那集群节点就得少，节点多了同步要花大量时间、时间不够，集群节点少所以不满足P。

 

2、满足CP，不满足A

满足C=>保证数据同步的时间开销，满足P=>集群节点多

节点又多、还要等这些节点都完成数据同步，那就不能保证在正常时间范围内处理完请求，所以不满足A。

 

3、满足AP，不满足C

满足A=>指定时间内处理完请求，满足P=>集群节点多

节点又多、还要在指定时间范围内处理完请求，那集群节点之间的数据同步就得不到保证，所以不满足C。
 

一台机器肯定是不行的，一旦该机器发生什么故障，系统就瘫痪了，都要做集群保证分区容错性（P，高可用），所以都是在A、C之间取舍。

• CP：适合支付、交易类，要求数据强一致性，宁可业务不可用，也不能出现脏数据，比如银行、金融类业务。
• AP: 信息流服务等普通互联网业务，比如大学选课系统，高考、四六级查分系统，电商系统，不要求数据强一致，可用即可。
   

选择注册中心时，看项目业务对数据一致性、服务可用性哪个需求更高

• ZK保证了数据一致性，但选举新的leader时集群不能对外提供服务，不满足可用性。满足CP，不满足A。
• Eureka是去中心化的，集群中每个节点的地位一样，少数节点挂了，其它节点不受影响，依然能对外提供服务，保证了可用性；但每个节点都需要从其它所有的节点同步数据，容易受网络故障影响，不满足数据一致性。满足AP，不满足C。

 

BASE理论

BASE理论：实现强一致性往往会严重降低系统性能，导致可用性降低，系统可以根据业务特点，采取适当的方式实现最终一致性。
 

BASE理论是一致性和可用性的权衡结果，主要涉及三点

• Basically Available：系统基本可用
• Soft State：软状态，允许系统中的数据存在中间状态、暂时没有完成数据同步。对于耗时操作，状态字段往往会设置进行中、处理中这样的中间状态。
• Eventually Consistent：最终一致性，数据最终能达到一致的状态。