本文共 1263 字，大约阅读时间需要 4 分钟。

前言

  将自己技术沉淀的时候忽然想到分布式锁和分布式事务，这两个都是博主打算自己深度定制并且开源的两个组件。这个文章我就说一下分布式事务中我的思路，或许能帮到大家，或许等找到工作有时间的时候我深度定制后做成开源分布式组件大家也能用上。

分布式事务

  基本上每个分布式项目都会遇到分布式事物这个问题，在技术上没有解决不了的问题，只是解决方案的优雅级别而已。目前广泛应用的分布式事务有两种，一种是“尽最大努力通知型”，一种是“集中管理型”，还有一种不常见的就是“好心累我们不搞事务了”。

  其实分布式事务难点难在事务是与Session绑定的（事务是啥我就不讲了），分布式项目中自己的连接池中的每个session都是隔离的不用说非自己连接池的了。

尽最大努力通知型

  见名知意，就是尽最大努力的通知分布式中每个事务是不是该去提交，场景：有个业务需要3个服务支撑，并且这三个服务均有数据写入操作，3个服务有自己的DB连接池，并且3个服务均开启事务，并且3个服务的事务互相隔离，业务在执行完后判断3个服务的返回状态决定是否提交事务，然后通知3个服务他们的服务是回滚还是提交。如图：

集中管理型

  又是见名知意昂，就是将所有的数据库操作交给一个服务去做，这样来保证分布式事务，场景：有个业务需要3个服务支撑，并且这三个服务均有数据写入操作，他们将数据库读写操作高速事务管理节点，业务执行完毕之后根据3个服务返回的状态决定是否提交该事务。如图：

定制方案的选择

   博主个人感觉，尽最大努力通知型或许比较轻量级，但是一般事务提交后无法回滚，所以如果有其中一个服务事务提交失败了，那么其他事务的数据可能会产生脏数据。“集中化管理”在扩展性、维护性上也有着显而易见的优势，虽然说如果一个事务操作的数据库不同集中化管理或许也是最大努力通知自己服务连接中的事务，相对故障点也小，唯一的缺点就是稍微重了那么一点点，所以博主选择的是“集中化管理”进行深度定制。

预测SpringBoot的定制方案（可以参考）

  因为我经常开源框架嘛，这次的定制方案也是以中间件或者组件的形式。SpringCloud这一部分也就是SpringBoot一样，都是data组件。我计划是深度定制data组件包括mongo的，mysql的，在提交数据库部分改为rpc，rpc支持扩展如rest、mq等，最大保证与原生data组件使用方式、注解一致，仅为配置文件不同，需要再配置文件中指定通知的服务器servicename或者ip地址。管理节点服务端支持自定义的事务扩展，并且内置支持mongo事务、mysql事务，根据业务中使用的数据库智能调度事务。

目前市场上的主流分布式事务框架

Atomikos，seata，fescar，txlcn，我比较倾向于txlcn，不产生事务只是事务的管理者，拥有一定的可扩展空间，比如自我扩展mongodb4的事务。

技术进阶讨论

  个人一直没有把自己当成一条咸鱼，我对技术有自己的追求。欢迎加入QQ群： 524574427 一起讨论技术，群人数不求多但求精。

转载地址：https://blog.csdn.net/zhanghaishan/article/details/104963383 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！