老板，明年我用Seata搞定分布式事务管理的规范化建设 | 中篇

灰太狼 2023-09-23 19:38 83阅读 0赞

#### 辞旧迎新，22年要结束了，明年做什么想好了嘛？要不要用 Seata 搞定公司分布式事务管理的规范化建设？ ####

> 欢迎关注微信公众号「架构染色」交流和学习

### 一、背景 ###

在上一篇[《明年用Seata搞定分布式事务管理的规范化建设 | 上篇》][Seata_ _] 中介绍了微服务架构演进，必然带来数据不一致的问题，在一些特性场景下数据的一致性要求会很高，而大多数情况下对一致性的要求又不高，这些差异也导致了对分布式事务解决方案呈现两种相对的顾念，一种认为可以置之不理，一种则认为必须解决，在没有标准方案的情况下，很容易出现各显神通，做出的东西即不通用也不健壮。

这两种情况从标准架构规范的大局来看都非合理状态，实际上从公司技术架构管理的角度看，需要的是**一套规范的、通用的、可靠的分布式事务解决方案**，能够帮助开发者在分布式的环境下，既能**保证业务数据的一致性**，又不需要**投入太多的资源**用于业务数据一致性的开发维护，还能**加快迭代速度保障项目交付**。

Seata 所兼备的 TC 高可用、 TCC 模式和 AT 模式特别符合**一套规范的、通用的、可靠的分布式事务解决方案**的诉求，能将分布式事务问题从业务中尽量剥离出来（AT模式剥离的比较彻底），作为一个独立的技术切面由专人管理运维（独立的服务端和模块化的客户端），提供简单、易用、高效、稳定的分布式事务解决方案，体现出以下价值：

1.  架构复杂度降低：分布式事务这个切面的技术问题，全部由 Seata 所提供的服务能力来解决。
2.  设计和开发成本减轻，加快交付和迭代速度：业务逻辑的设计和开发中，若采用 AT 模式，则无需考虑是否涉及分布式事务，是否需要做额外的准备，专注 SQL 编写实现业务逻辑即可，对业务 0 侵入 。
3.  运营成本降低，保证业务数据准确度，以及出错时的自动回滚和及时通知

本篇我们探讨一下项目的推进思路，以及AT模式的原理

### 二、如何推进 ###

之前好朋友在聚餐时提到说自己在尝试来落地分布式事务，但自己也遇到一些问难，之后我们经常沟通，也探索出了一些可行方案，整理出来给大家做个参考。

当下的大环境并不好，公司调整为业务导向的方针，因此基础技术领域的部门需重新审视自己的角色、调整自己职责，不能以技术至上的心态一味追求高精尖，而他作为一向偏爱技术的个体也需调整思路，全力转向为开发者服务。在老板业务导向的方针下，新技术的引入、推进就不能再纯粹以技术视角考量，要结合业务，评估是否有痛点，是否有需求，需求是否强烈。

PMO 与多个业务部门组织需求和使用场景的沟通后，他们得到了比较一致的反馈，较多同事有听到过 Seata 在其他公司的实践分享，但此技术的可用性、稳定性方面在本公司尚无案例借鉴，无法给与充足的信任，即使有需求也不敢贸然明确提出使用 Seata 就能解决问题；基础设施需要先行，给出兼容性、性能、稳定性等方面的一些可靠结论。新能力需要业务方提需求，业务方要基础设施先提供能力保障，这个“死锁现象”按照工程化的思路重新梳理，跟 PMO 商定徐图缓进的应对之策：

1.  加强对 Seata 技术层的掌控力，针对公司的技术栈和数据库中间件进行全面的功能性验证，明确其可靠能力的合集；在此过程中梳理原理、解决问题并将验证结论等进行整理
2.  通过每周宣导的方式，进行同步、培训和引导，互动的过程中，搜集需求和意向用户以及其需求场景
3.  理清 Seata 的**安全保障机制**，以**最小测试单元**的原则来保障试点应用的接入和验证。

TCC 模式对代码的侵入性较高，需要做大量的改造，这对当下 Seata 的推进并不友好，而 AT 模式能适配的应用场景很多，只需要少量代码的微调即可，并且通过 AT 模式即也能证验证大部分 Seata 的能力。基于以上考虑，他们将尝试的方向先聚焦到 AT 模式上，有了 AT 模式的积累沉淀后，TCC 模式的应用将会水到渠成。

### 三、介绍 AT 模式业务无侵入的的原理 ###

1）一阶段：

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其读出保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其读出保存成“after image”，最后生成事务锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

![format_png][]

2）二阶段提交：

二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段的事务锁释放，完成对应”before | after image“数据的清理即可。

![format_png 1][]

3）二阶段回滚：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

![format_png 2][]

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。

### 四、总结与预告 ###

本篇介绍了好朋友公司在业务导向的主旨下，推进 Seata 时所遇到的一些困难，以及应对策略，给读者朋友做个参考借鉴。之后介绍了 AT 模式业务无侵入的的原理，从而让读者朋友能直观的感受到此模式能适配的应用场景很多，只需要少量代码的微调即可，读者朋友可将尝试的方向先聚焦到 AT 模式上，有了 AT 模式的积累沉淀后，TCC 模式的落地将会水到渠成。

等好朋友结合自家公司的技术栈，做完兼容性测试，以及将遇到的问题解决后，再将有价值的信息同步给大家，帮助大家少踩坑。每家的技术栈情况会有微小差异，兼容性测试真的很重要，没问题就很开心，有问题就不能带病上线。

### 五、最后说一句 ###

我是石页兄，如果这篇文章对您有帮助，或者有所启发的话，欢迎关注笔者的微信公众号【 架构染色 】进行交流和学习。您的支持是我坚持写作最大的动力。

[Seata_ _]: https://juejin.cn/post/7174076314020904997
[format_png]: https://img-blog.csdnimg.cn/img_convert/94cc09e6c2a67533d2d660c4d15b76b4.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/32fe50a9271e8fb144b2636b47af0e3c.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/84bedabe5928fb3fb9dbd511d513b001.webp?x-oss-process=image/format,png