go分布式事务 mysql_分布式事务解决方案

什么是分布式事务

在大的操作集合中，所有的小操作都属于不同的服务器，不同的应用，分布式事务需要保证这些小操作要么一起成功，要么一起失败。本质上，分布式事务为了保证数据的一致性

分布式事务产生的原因

数据库分库分表(当一个操作需要访问01库又要访问02库的时候就会有这个问题)

SOA服务化(所有业务拆分到不同的模块中，数据存储在不同的服务器中，所以需要用到分布式事务)

ACID事务特性

原子性

一致性

隔离性

持久性

分布式事务的解决方案

基于XA协议的二阶段提交

消息事务+最终一致性

TCC编程模式

二阶段提交

XA是分布式事务协议，

总的来说 XA协议比较简单，容易实现，但是缺点是

同步阻塞 所有事务参与都在等待其他参与者响应的时候都处于同步阻塞的状态

单点问题

数据不一致

太过保守 任何节点失败 都会导致整个事务失败

性能不理想，mysql的XA实现，没有记录prepare阶段日志，许多nosql也没有支持XA

消息事务+最终一致性

A系统 发送prepare信息到 mq 然后得到mq 的返回后进行本地事务 然后在发送执行成功的消息进入mq，接着B系统获得到A系统完成本地事务的通知后

执行自己的事务 A系统通过消息回调来知晓 事务是否成功

如果A完成事务 B没完成 则再mq中会不断发起请求，知道B完成事务为止

缺点： 该解决方案只是最终一致性，如果B一直不成功，那其实AB 就不是一致性，所以需要业务方去抉择，判断

TCC编程模式

TCC 提供一个编程框架，Try Confirm Cancel 三个操作

每个业务方都需要实现这3种操作 try用于事务资源的预留，cancel用户资源不足时候的cancel方法，必须保证幂等。

协调器调用每个业务方的confirm接口 发现所有参与者的confirm方法都ok了 则分布式事务结束

如果失败次数过多，都需要进行事务补偿

缺点 业务需要实现这3个操作 对业务侵入较大

总结

分布式事务，本质上针对多个数据库的事务进行统一控制，按照控制力度分为 不控制，部分控制，完全控制

不控制 表现为不引入分布式事务

部分控制 消息事务+最终一致性，TCC编程

完全控制 两阶段提交

性能优缺点： 控制力度越大 性能，qps 都会下降，但是一致性会提高

复制代码

有疑问加站长微信联系(非本文作者)