分布式系统之CAP和BASE理论

CAP理论

2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上，首次提出了CAP猜想。

2002年，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP猜想的可行性。

所谓CAP理论，指的是分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition tolerance)这3个基本需求，最多只能同时满足其中的2项。

Consistency(一致性)

分布式系统中，为了提高容错性，每份数据均存在多个副本，且一般分布在不同节点上。

如果对第1个节点的数据成功进行了更新，而第2个节点上的数据副本没有成功同步，则发送到第2个节点的请求得到的数据仍然还是旧数据，即脏数据，此时数据存在不一致。

在分布式系统中，如果能够做到针对1个数据项的更新操作执行成功后，不同节点上的请求均能读取到最新的值，这样的系统被认为具有强一致性。

Availability(可用性)

可用性指的是分布式服务必须始终处于可用的状态，对于用户的每一个请求总能在有限的时间内返回结果。

• 有限的时间，如果超过了时间阈值，则认为不可用；
• 返回结果指的是需要返回正常的响应结果(成功或失败，而不是系统异常等令人困惑的结果)。

Partition Tolerance(分区容错性)

系统如果不能在有限时间内达成数据一致性，就意味着发生了分区的情况，当前操作必须在C和A之间做出选择。

CAP只能满足其中2个，那么取舍的策略有3种:

CA without P: 如果不要求P，则意味着不允许网络分区，放弃P就意味着放弃了系统的扩展性，而这违背了分布式系统设计得初衷。传统的关系型数据库RDBMS:Oracle、MySQL就是CA系统。

CP without A: 如果不要求A，相当于数据需要在各个节点间保持强一致性，当P发生时会导致数据同步时间无限延长(需要等待所有数据副本同步完才能正常访问服务)，如Zookeeper就是CP系统。

AP without C: 如果要保障高可用并允许网络分区存在，则必须放弃一致性。当P发生时，节点之间可能失去联系，为了保证每个节点均可以提供服务，各节点只能使用本地数据提供服务，而这样会导致全局数据的不一致性。如Consul等分布式配置中心就属于AP系统。

需要注意的是: 分布式系统一般不是严格的AP或CP系统。比如Kafka，虽然官方开发人员声称Kafka运行在一个数据中心，网络分区问题基本不会发生，所以是CA系统。

但现实情况是，即使运行在一个数据中心，网络问题理论上也是存在的，所以这是一个必须要考虑的点。那么，Kafka是AP还是CP系统呢？

其实，Kafka提供了一些配置，用户可以根据具体的业务需求，进行不同的配置，使得Kafka满足AP或者CP，或者它们之间的一种平衡。

比如下面这种配置，就保证强一致性，使得Kafka满足CP。任意写入一条数据，都需要等到replicate到所有节点之后才返回ack；接下来，在任意节点都可以消费到这条数据，即是在有节点宕机的情况下，包括主节点。

replication.factor = 3
min.insync.replicas = 3
acks = all

而下面的配置，就主要保证可用性，使得Kafka满足AP。对于任意写入一条数据，当主节点commmit了之后就返回ack；如果主节点在数据被replicate到从节点之前就宕机，这时，重新选举之后，消费端就读不到这条数据。这种配置，保证了availability，但是损失了consistency。

replication.factor = 3
min.insync.replicas = 3
acks = 1

还有一种配置是公认比较推荐的一种配置，基于这种配置，损失了一定的consistency和availability，使得Kafka满足的是一种介于AP和CP之间的一种平衡状态。因为，在这种配置下，可以在容忍一个节点（包括主节点）宕机的情况下，任然保证数据强一致性和整体可用性；但是，有两个节点宕机的情况，就整体不可用了。

replication.factor = 3
min.insync.replicas = 2
acks = all

对于这种配置，其实Kafka不光可以容忍一个节点宕机，同时也可以容忍这个节点和其它节点产生网络分区，它们都可以看成是Kafka的容错（Fault tolerance）机制。

除了上面的几个常用配置项，下面这个配置项也跟consistency和availability相关。这个配置项的作用是控制，在所有节点宕机之后，如果有一个节点之前不是在ISR列表里面，启动起来之后是否可以成为leader。当设置成默认值false时，表示不可以，因为这个节点的数据很可能不是最新的，如果它成为了主节点，那么就可能导致一些数据丢失，从而损失consistency，但是却可以保证availability。如果设置成true，则相反。这个配置项让用户可以基于自己的业务需要，在consistency和availability之间做一个选择。

unclean.leader.election.enable=false

BASE理论

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)的简写。

其实BASE理论就是CAP理论的延伸，其核心思想是即使无法做到强一致性(Strong consistency)，但每个系统可以采用适当的方式来使系统达到最终一致性(Eventually consistent)。

Basically Available(基本可用)

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性:

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
• 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

Soft state(软状态)

弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

Eventually consistent(最终一致性)

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

参考文献

https://www.cnblogs.com/duanxz/p/5229352.html
https://blog.51cto.com/u_15067225/2603718