CAP理论
- C (一致性): 对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致
- A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。
- P (分区容错性): 当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。
BASE理论
Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)
- 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
- 软状态:允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
- 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。
放弃了强一致性，强调最终一致性。
TCC
Try - confirm - chancel 执行流程为：尝试- 确认 / 取消
使用TCC要用TCC服务框架（ByteTCC、tcc-transaction），然后我们需要将一个接口逻辑写成三个接口，分别为：
- 执行尝试操作逻辑
- 执行确认操作逻辑，TCC服务会自动确认尝试操作是否完成，如果完成则执行确认操作
- 执行取消操作逻辑，TCC服务如果感知到Try操作失败，则执行取消逻辑
缺点: 大大提高了编程的复杂性,执行难度大.
2PC & 3PC
两段式提交 & 三段式提交，类似TCC，三段式提交用的少，因为多了一次操作效率低。
2PC two phase confirm
- 准备阶段： 协调者向所有参与者询问是否可以提交操作，并等待响应，如果各个参与者都执行成功就返回“同意”，如果有参与者执行失败，则返回“中止”
- 执行阶段：如果都返回同意，则协调者向参与者发送正式提交的请求；
如果有任一参与者返回“中止”，则向所有参与者发送回滚请求
优点：实现方便，原理简单
缺点：同步阻塞，单点故障问题，可能数据不一致。
3PC three phase confirm
- CanConfirm：协调者发送CanConfirm请求询问是否可以执行提交操作，参与者收到请求后判断是否可以执行，可以则返回Yes
- PreConfirm：如果全部返回Yes，则发送PreConfirm请求，参与者收到请求后开始执行，对应2PC中的准备阶段，如果成功执行事务，则返回ACK响应
- DoConfirm：协调者收到1所有参与者的ACK响应后，向所有参与者发送DoConfirm请求，参与者执行事务提交，并返回响应。
优点：引入超时机制，解决了单点问题和阻塞时间。
缺点：实现复杂，多了一层请求，效率低
MQ实现可靠消息最终一致性
最大努力通知是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果不影响主动方的处理结果。（例如用户注册成功后发送邮件、电商系统给用户发送优惠券等需要保证最终一致性的场景 ）
这个方案的大致流程就是：
- 系统 A 本地事务执行完之后，发送个消息到 MQ；
- 会有一个专门消费 MQ 的服务，这个服务会消费 MQ 并调用系统 B 的接口；
- 要是系统 B 执行成功就 ok 了；如果系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B, 反复 N 次，最后还是不行就放弃。
大致流程如下:
- A 系统先向 mq 发送一条 prepare 消息，如果 prepare 消息发送失败，则直接取消操作
- 如果消息发送成功，则执行本地事务
- 如果本地事务执行成功，则想 mq 发送一条 confirm 消息，如果发送失败，则发送回滚消息
- B 系统定期消费 mq 中的 confirm 消息，执行本地事务，并发送 ack 消息。如果 B 系统中的本地事务失败，会一直不断重试，如果是业务失败，会向 A 系统发起回滚请求
- mq 会定期轮询所有 prepared 消息调用系统 A 提供的接口查询消息的处理情况，如果该 prepare 消息本地事务处理成功，则重新发送 confirm 消息，否则直接回滚该消息
使用阿里的RocketMq可以实现该功能 , 适用场景: 用户注册成功后发送邮件、电商系统给用户发送优惠券等需要保证最终一致性的场景
相关文章
