分布式事务

分布式事务

• 怎么处理分布式事务

  1. 如果能在设计的时候避免就尽量避免

  2. 考察业务出错的原因，如果出错的频率比较低，那可可以考虑不用，可以用人工处理，但是出错的频率比较高的话，可以用分布式事务

  3. 基于MQ可靠消息实现数据一致性

  4. TCC开源框架

  5. LCN开源框架

• cap理论

  1. Consisitency(一致性)：所有用户看到的数据都是一致的

  2. Availability(可用性)：总能找到一个可用的数据副本

  3. Partition(分区容错性)：能够容忍网络中断

• MQ

  1. 生产者发送信息进入队列后是有顺序的，消费的时候分配也是有顺序的，一个一个拿出来，但是无法保证消费是有顺序的

  2. 对于一个消息而言，如果有多个消费者且在同一组，如果不把模式设为广播模式的话，那么一组里面的多个消费者就只有一个消费者能成功消费消息，其余的就不消费了，如果设置了广播模式，那么即使一个组里有多个消费者，也可以都消费到同一个消息；但如果不在一个组里面，那么同一个消息（也就是同一个主题）都可以被消费到

  3. 怎么保证消息的可靠性呢？

     1. 可以使用同步方法，等消息落盘

     2. 可以建立一个本地消息表，把要发的信息放在表里，然后专门弄一个消息恢复系统，定时去查看本地消息表里面有哪些消息（剩下来的消息就是没有被消费到的，或者消费了但没得及删除的），取出来给到mq再发一次，mq收到消息给消费者消费后，在消费者系统中主动去把本地消息表里面对应的这条消息删除掉
        mq消息可靠性.png

但是，如果我的消费者挂了，那消息恢复系统无限取出未消费的消息给到mq吗？我们可以在本地消息表里面设置一个计数器，一个状态字段，每取一次消息，计数器加1，当计数器达到3次，我们就把该消息的状态设为不可消费的状态，以后就不再去拿这条消息给到mq了，这些不可消费的消息，就需要有单独的业务去展示给工作人员看，然后人工去处理

• Seata 两阶段提交协议：（Seata TA模式与Seata TCC模式都是两阶段的）

  1. TM（全局事务管理器）向TC（全局事务协调者）申请开启全局事务，TC生成一个xid给到TM

  2. xid会随调用链传播

  3. RM(资源管理器)把本地事务通过xid注册到全局事务中，成为全局事务的分支事务，由TC来协调该分支

  4. TM通过xid来告诉TC哪个全局事务要执行提交或者回滚的操作了

  5. TC通过xid找到该全局事务对应的每一个分支事务来执行提交或回滚操作了

• Seata AT模式:

  1. 第一阶段（prepare ）：在本地事务中修改数据后保存在数据库（相当于做了本地提交），同时也生成了回滚的日志记录在数据库中（回滚数据保存在undo_log表中，所以AT模式是依赖于mysql的，如果分布式事务用的不是mysql，那么就不适用与AT模式）

  2. 第二阶段（commit ）：如果第一阶段都执行成功了，那么TC就通知所有的分支事务commit，同时自动异步删除回滚日志

  3. 第二阶段（rollback）：如果第一阶段有错，那么通过TC协调所有的分支事务通过之前的回滚日志记录进行数据回滚

• Seata TCC模式：

  1. 第一阶段（try）：完成所有业务检查，预留必须的业务资源（比如转账的操作，现在有100元，每次转30元，那么我最多只能预留3次资源，换句话说最多有3个事务可以并发，因为第四次钱不够了）,这里的预留资源是在接口层面，而不是数据库层面，即不会一直锁着数据库，即使需要操作下数据库，也是操作完就好了，而不是非得等到整个全局事务结束后其他线程才能访问数据库，所以其并发度和效率比AT模式快

  2. 第二阶段（Confirm）：真正执行的业务逻辑，不做任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分布式事务能且只能成功一次。

  3. 第二阶段（ Cancel也是属于第二阶段）：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。

  4. try是我们自己去调用，而confirm和cancle都是seata来调用的，当所有的try都成功后，那么Seata就会调用confirm，否则就调用cancle

• Seata TCC和AT模式的区别：

  1. AT需要全局锁，TCC是无锁的，虽然AT中第一阶段，本地事务（分支事务）已经把自己修改的数据提交了，并且保存了回滚日志undo_log，但是AT本地事务的提交只是方便所有的分支事务操作成功后，不用等着一起commit浪费时间，但是它的资源管理器是把数据库作为资源的，所以数据库还是被锁着的，而TCC模式第一阶段只是预留资源，操作完数据库就释放了，TCC的资源管理器是把接口方法作为资源的，是逻辑资源

  2. AT模式需要回滚日志undo_log，TCC模式不需要

  3. AT模式不需要我们操作commit和cancle，都是数据库层面的，但是TCC模式需要我们自己处理commit和cancel

  4. AT有全局锁，所以性能比TCC慢，而且依赖于mysql数据库

  5. TCC需要考虑空回滚，幂等性和悬挂的问题

  • 参考资料

    1. 分布式事务 Seata TCC 模式深度解析怀素的专栏-CSDN博客seata tcc

    2. 一文简要概述Seata AT与TCC的区别 - (jianshu.com)