CAP 原则
CAP 原则是 Consistency (一致性)、Availability (可用性) 和 Partition-tolerance (分区容错性) 的缩写,它是分布式系统中的平衡理论。
一致性要求所有节点每次读操作都能保证获取最新数据。
可用性要求,系统提供的服务必须处于可用状态,对于用户的请求能够在有限的时间内返回结果。
分区容错性要求被分区的节点在遇到网络分区故障时候,仍然需要正常对外提供服务。
事实上,任何系统只可同时满足其中两个,无法三者兼顾,即所有分布式系统只能满足 CP 或者 AP
Base 理论
BASE 是 Basically Available (基本可用)、Soft-state (软状态)和 Eventually Consistent (最终一致性) 的缩写,是对 CAP 原则的一致性和可用性进行权衡之后得到的结果。
其核心思想是即使系统无法做到强一致性,但应用可以采用适当的方式使系统达到最终一致性。
Basically Available (基本可用) 即表示系统在出现故障时候,还能够提供部分服务。
Soft-state (软状态) 与硬状态相反,表示系统不同节点之间的数据存在中间状态,可能存在一定的延时,但不影响系统的整体可用性。
Eventually Consistent (最终一致性) 描述系统之间的数据副本,经过一段时间的同步之后,最终达到一个一致的状态。
一致性解决方案
分布式事务一致性解决方案分为两种类型:
- 强一致性
即事务的操作是同步进行,包括:两阶段提交协议、三阶段提交协议。
- 最终一致性
包括 TCC 模式、补偿模式、可靠事件模式
两阶段提交协议
当一个事务跨越多个节点时,需要引入一个协调者去控制每个节点的操作结果。即事务管理者(协调者)负责控制所有资源管理者(参与者)准备流程和提交流程。
第一阶段:协调者向参与者发起准备命令,询问参与者是否预提交成功(执行操作,但不提交)。
第二阶段:协调者根据参与者的响应结果,发起提交命令或者回滚命令(有参与者没有准备好或者执行失败)。
缺点:
同步阻塞:参与者需要听从协调者的调度,在此期间处于阻塞状态;
单点故障:协调者若发生故障,参与者将一直等待;
数据不一致:协调者向参与者发送 commit 请求时发生故障,导致一部分参与者执行了 commit 请求。
三阶段提交协议
在两阶段提交基础上,引入超时机制解决同步阻塞问题
并加入预备阶段,尽早发现有问题的参与者,只有预备节点完成,才会执行后续的准备和提交阶段。
缺点:
数据不一致:参与者无法及时收到协调者请求时,会默认 commit。
TCC 模式
将任务拆分为三个操作:Try、Confirm、Cancel
具体流程:第一阶段主业务调用全部从业务服务的 Try 操作,并且记录操作日志。第二阶段,当从业务服务全部成功,再执行 Confirm 操作,否则执行 Cancel 逆操作。
补偿模式
通过定时任务、重试机制实现数据的最终一致性
可靠事件模式
借助消息队列,保证消息投递的有效性,实现数据最终一致性。
正反消息机制:
- 主业务向从服务发起业务调用,先记录 待发送 状态至数据库中,并向消息队列投递消息;
- 主业务根据消息队列的响应结果成功与否进行判断,响应成功将消息改为 已发送 状态,否则改为 结束 状态
- 消息队列向从服务发送消息,根据从服务 ACK 结果进行判断;ACK 响应成功进行下一步,ACK 响应失败或者超时,消息队列或者定时任务将待发送的记录进行重发。
- 从业务消费成功,向主服务发送已完成消息,主业务将记录改为 已完成 状态。
参考
《高可用可伸缩微服务架构:基于Dubbo、Spring Cloud和ServiceMesh》