理解CAP理论
CAP理论,是分布式系统架构绕不开的一个基本指导理论,相信每一个想成为架构师的你都有所耳闻.CAP理论是一套指导人们在设计分布式系统时进行取舍的原则.
什么是CAP理论
CAP理论,是一个经过分布式领域公认的定理,原文是一个叫Eric Brewer的教授对于分布式引擎的猜想
t is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance.
就是说,一个分布式系统,不可能同时满足Consistency(一致性) ,Availablity(可用性) 和Partition-tolerance(分区容错性),最多只能满足其中的两个(AP或CP),所以又有说法叫"CAP不可能三角"
P- 分区容错性
The system will continue to function when network partitions occur.
翻译: 当出现网络分区后，系统能够继续“履行职责”。
分区容错性强调的是集群对分区故障的容错能力,具体来说,就是在节点之间出现任意数量消息丢失或者高延迟的情况下,系统仍然能正常工作.
因为分布式系统与单机系统不同,涉及到多节点之间的通讯和交互,而网络故障或节点故障是难以避免的,而放弃分区容错性等于放弃系统之间的调用,那么就不是分布式系统了,所以在CAP三选二中,P是必选项.
C - 一致性
A read is guaranteed to return the most recent write for a given client.
翻译: 对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。
一致性强调的是多节点组成的分布式系统,能像单节点一样运行,具体来说就是一个写操作的成功返回,意味着之后所有的读请求都能必须读到这个写入的数据;如果写操作返回失败,则之后的读操作不能读到写入的数据.
当然,一致性在实际设计的时候,还分为最终一致性和序列一致性.
A - 可用性
A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).
翻译: 非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）
可用性定义了三个关键点: 完全可用,有限时间,返回结果.
可用的数据不一定是最新的数据,但是保证一定在有限时间内返回.这个"有限",就是不同系统设计的时候设定好的运行指标,如Mysql的返回可能要求1秒内,而OLAP系统可能是1分钟内返回即可.
如何正确看待CAP不可能三角
CP
在追求一致性的道路上,数据库系统为了保证事务的正确性和一致性,曾经提出过一个ACID理论,在强调分布式一致性的时候,难免要被抓出来一起比较.
ACID即:
-
Atomicity(原子性): 一个事务中的操作要么全部完成,要么全部不完成,不会在中间某个环节Atomicity(原子性): 一个事务中的操作要么全部完成,要么全部不完成,不会在中间某个环节结束.
-
Consistency(一致性): 事务开始和事务结束后,数据库的完整性没有被破坏.
-
Isolation(隔离性): 多个事务之间允许同时进行,有不同级别的隔离
-
Durability(持久性): 事务处理结束后,对数据的修改是永久的.
可以看到ACID中的A强调的是原子性,跟CAP中强调可用性的A不同,对于Consistency的要求也不一样,CAP强调一致性,而ACID强调完整性.
虽说二者是关公战秦琼没有可比性,但是二者都强调事务的一致性,那么如何实现分布式系统多个节点的事务呢?
分布式系统为了实现分布式事务,可能会采取两阶段提交或TCC(Try-Confirm-Cancel) 或来保证节点之间的ACID.实现分布式事务.
两阶段提交协议需要一个协调者(cordinator),第一阶段提交请求(又称投票阶段),各节点根据自身情况做出响应,cordinator统计各节点的返回,一般过半数确认后进入下一个阶段,提交阶段.然后由所有节点执行相同的cordinator的统计结果.
TCC(Try-Confirm-Cancal),从名字看就是分为尝试提交,确认提交和取消提交三种操作,尝试提交是每个节点尝试(Try)写入请求,然后返回写入成功或失败(Confirm),一旦有写入失败的节点出现,则写入成功的节点执行取消写入操作.(Cancel)
与两阶段提交不同的是,TCC不需要协调者,而且两阶段提交在投票期间每个节点需要预留写入的锁,在投票期间不可写入,难以实现单个写入粒度的锁;TCC则没有这个问题.但是TCC要求为每个写入操作提供一个补偿机制,来撤销写入.实现起来较为复杂. 而且不管是两阶段提交还是TCC,在追求一致性的时候都有多余的操作,对于要求有效时间内返回结果的A,显然就不能保证了.
哪些系统追求的是CP?
HBase,MongoDB,Zookeeper等
AP
CP强调的是一致性,为了保证节点间的一致性,有投票和同步环节,这些节点间的通信操作,影响了写入操作本身的耗时,对于强调可用性的A来说,写入操作可能要求的是立刻返回,一致性同步可以随后再做.读操作只要立刻读到正确的数据,不一定要求最新.
AP系统不要求强一致性,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性.
这就是BASE理论的思想,Basically Avaliable(基本可用),由老版本数据保障基本可用,Soft State(软状态) 指的是同步过程中的中间态. Eventually Consistent(最终一致性),指的是最终存在一个一致性的"硬状态",最终完成了同步.
分布式系统实现基本可用的4板斧就是: 流量削峰,延迟响应,体验降级,过载保护.
实现最终一致性也通常有几种做法: 读时修复, 写时修复, 异步修复.
哪些系统追求的是AP?
Nacos,Eureka …
总结
CAP 不可能三角只是指导分布式架构在选型的时候对于一致性和可用性要有所取舍的,其粒度是数据而不是系统,不能奔着设计一个CP系统或AP系统去盲目的只考虑一致性或可用性,而是根据不同的业务数据在两者之间灵活选用.比如说对于网购系统来说,“余额”,"账单"等涉及钱的模块可以考虑CP,而用户个性签名,文章动态等不追求强一致性的数据,则考虑AP. 而且也并不是严格3选2,还是在掌握理论的基础上,具体业务具体设计.