分布式系统解决方案学习笔记

分布式系统解决方案学习笔记

应用场景

分布式事务需要服务与服务之间远程协作完成事务

分布式事务的CAP

C:一致性

1.写操作会有一定延迟
2.保证数据一致时会锁定资源，同步完成后释放资源
3.同步失败会返回错误信息，但不会返回旧数据

A:可用性

所有与请求都有响应，且不会响应错误或超时

P:容忍性

分布式容忍性是分布式系统的基本能力

1. AP:放弃一致性，追求可用性和容忍性
2. CP:放弃可用性，追求一致性和容忍性
3. CA:放弃容忍性，不进行分区，但这不算是分布式系统

BASE理论（AP扩展）
1.基本可用：出现故障保证核心功能可用
2.软状态：允许存在成功与失败间的状态（例如处理中），不影响系统使用
3.最终一致性：经过一段时间后，所有节点的数据会达到一致

分布式事务解决方案

2PC方案

基本概念：
两阶段提交协议，分为准备阶段和提交阶段
准备阶段：事务管理器给参与者发送prepare消息，每个事务参与者在本地执行事务，并写入Undo/Redo日志，此时事务并未提交
提交阶段：如果事务管理器收到参与者失败或超时消息，则给参与者发送回滚消息，反正发送提交事务消息，并释放资源

基于2PC方案，定义了分布式事务解决方案模型DTP，及定义了TM与RM之间的接口协议XA
DPT模型中包含角色：
AP:应用程序
RM:资源管理器，可理解为参与者
TM:事务管理器

1. TM为AP提供接口，AP通过TM提交或回滚事务
2. TM交易中间件通过XA协议的接口通知RM的数据库事务开始，结束，提交及回滚

2PC性能较差，在RM执行事务过程中资源是不释放的

2PC方案优化框架：Seata

基本概念：
Seata是阿里巴巴开源的分布式事务中间件,以高效并且对业务0侵入的方式,解决微服务场景下面临的分布式事务问题,支持AT（2PC）和TCC模式,对比DTP模型,Seata新增一个TC事务协调器作为独立运行的中间件,协调事务的通知

案例：
与2PC方案的区别在于多了TC以及在第一阶段事务就已经进行提交，所以资源在第一阶段就释放

总结要点和注意事项

1. RM使用DataSourceProxy连接数据库，从而使用ConnectionProxy将undo_log和业务数据库放在一个本地事务进行提交
2. 第一阶段undo_log中存放了数据修改前后的值，为之后可能回滚做准备，第一阶段就提交了事务，释放了资源
3. TM开启全局事务，将XID放入事务上下文中，通过远程调用将XID传入上下游分支，每个分支将自己的分支ID和全局ID关联
4. 在第一阶段已经提交过事务，所以第二阶段提交事务只需要对undo_log文件进行处理，可异步执行
5. 进行全局回滚，TM会通过XID和分支ID找到对应的undo_log日志进行反向sql操作，回滚到未修改的状态
6. 全局事务开启要用@GlobalTransactional标识
7. 每个本地事务要有自己的@Transactional事务标识
8. 每个数据库都要创建undo_log表，保证一致性

TCC方案

基本概念：
TCC方案指try，confirm，cancel。try阶段执行成功，confirm阶段必定执行成功（即使人工介入或重试也要让该阶段成功），try阶段失败则失败方参与cancel阶段，TCC又可以被称为两阶段补偿事务，第一阶段try只是预留资源，第二阶段去对资源进行处理，判断资源能否使用，对应第二阶段的confirm/cancel，用来清除第一阶段的影响，所以叫补偿型事务，但是该方案对业务有很大的侵占性，实现比较复杂

TCC方案框架Hmily

介绍：
Hmily是一个轻量级的高性能的TCC框架，使用AOP拦截方法对事务进行渗透，侵占性低
@Hmily只要标记了这个注解的方法就是Try方法，并且可用在其中指定confirm和cancel方法的名称，且confirm和cancel方法需要写在同一个类下

转账案例:

问题及解决思路：

1. 空回滚:没有调用Try时，调用了Cancel方法(如在执行Try业务的过程中超时，默认判断失败，执行cancel方法)，只需要在执行try的过程中添加记录，将全局事务Id作为主键，在cancel阶段判断是否有记录，有就执行方法，反之则不执行
2. 幂等:重复提交或执行，解决思路如上
3. 悬挂:cancel阶段比try阶段先执行(如在try阶段RPC调用网络延时，默认失败，则去调用cancel阶段方法，网络恢复后try阶段才开始执行)，在执行cancel阶段时记录，在try阶段时先判断cancel阶段是否已经执行过了，如果执行过就不在执行try方法

可靠消息一致性

基本概念：
消息发起方完成本地事务发送一条消息，消息接收方一定接收到消息且一定执行事务成功，完成消息发起和接收事务的最终一致，要做到参与方接收消息的可靠性和避免消息重复消费

案例:

RocketMQ4.3实现可靠消息一致性

RocketMQ提供事务回查接口和接收接口
RocketMQLocalTransactionListener接口
其中包含两个方法 一个executeLoacalTransactional是成功发送消息回调的接口
checkLocalTransactional是事务状态回查，可以重写该方法判断本地事务执行状态
@RocketMQTransactionListener 可以监听消息发送是否成功
RocketMQListener<>接口
onMessage方法可以接收消息内容
@RocketMQMessageListener 可以监听消息接收是否成功

最大努力通知

基本概念：
最大努力通知指发起方把消息发送给接收方，接收方不一定要接收的到，但发起方必须提供给接收方一个查询的接口，可以查询到该业务的处理结果。最大努力通知主要也是借助MQ来进行事务控制，与可靠消息最终一致一样。区别在于，最终一致性方案需要保证消息发起方消息的可靠性，而最大努力通知方案需要接收方去主动查询发起方，保证消息可靠性。
特点：

1. 有消息通知机制
2. 有消息校对机制

方案1(内部通知系统)

方案2(对接其他的接收方)

小结

	2PC	TCC	可靠消息一致性	最大努力通知
一致性	强一致性	最终一致	最终一致	最终一致
吞吐量	低	中	高	高
复杂度	易	难	中	易