分布式事务之seata使用，一文带你全盘掌握！

       大家好，今天我来分享一下分布式事务中的pynng源码seata使用技巧。在面试中，分布式事务的解决方案是一个不可回避的话题。seata是阿里巴巴中间件团队开源的项目，它的目标是让分布式事务的使用变得简单高效，解决开发者在分布式事务方面遇到的所有问题。seata采用无侵入2PC方案，将分布式事务看作由多个分支事务组成的全局事务。全局事务负责协调分支事务，确保事务的一致性，即要么一起成功提交，要么一起失败回滚。分支事务通常就是数据库中的本地事务。seata的核心组件包括TC（Transaction Coordinator）、TM（Transaction Manager）和RM（Resource Manager）。

       接下来，我将通过一个案例来具体讲解如何使用seata。我们需要实现一个需求，即通过订单微服务进行下单操作，并通知库存微服务进行库存扣减。为了实现这一需求，我们需要准备订单和商品实体类，并添加项目必备的pom依赖。然后，分别搭建商品微服务和订单微服务，确保它们可以共享公共模块中的实体类和工具类。在订单微服务中，我们需要编写下单操作的服务接口、service、feign客户端、dao。同样，我们需要在商品微服务中编写controller、service和dao。

       接下来，我们启动测试。如果手动模拟异常，例如下单操作成功，但库存没有扣减，我们就会遇到数据不一致的问题。这时，我们可以使用seata来解决这个问题。首先，下载seata，然后配置相关参数，包括修改registry.conf、指定使用nacos注册中心、配置nacos-config.txt、初始化nacos配置、启动seata服务等。配置完成后，我们可以在nacos控制台中看到初始化的seata配置。启动seata服务后，我们可以在nacos服务列表中看到名为serverAddr的服务，这表示seata服务已成功启动。

       最后，mov源码我们需要在微服务中添加seata相关的依赖，并配置DataSourceProxyConfig代理数据源。通过这种方式，seata可以实现事务分支的管理，确保事务的一致性。在进行测试时，我们可以使用h在年发表的论文，其核心在于当分布式事务中的一个节点失败后，通过状态机对整个事务从前到后进行重试，或从后往前进行补偿，以确保事务的最终一致性。

       saga模式广泛应用于复杂业务流程场景，尤其当某些服务无法提供TCC模式的接口或者实现AT模式的自动补偿机制时。

       阿里巴巴的Seata中间件采用状态机实现saga模式，通过定义状态图和生成JSON状态语言文件来指导服务调用流程，其中状态图的节点可以是服务节点或补偿节点。在出现异常时，状态机引擎负责从成功调用的服务开始，从前向后或从后向前执行补偿逻辑，补偿逻辑由服务自身实现。

       以电商网站购买商品为例，当用户下单时，系统首先在订单服务中保存订单，随后调用账户服务扣减金额，并调用库存服务扣减库存。若过程中某一步失败，则从后向前依次执行补偿操作，此过程由状态机驱动。

       配置状态机包括创建SQL表以存储流程状态，定义状态机的JSON文件以描述流程图中的节点，包含6个ServiceTask，分别对应下单、扣减账户和库存以及补偿机制。定义CompensationTrigger在异常情况下触发补偿事件。对于每一个节点，定义其类型、触发方法、回滚事件对应的ServiceTask、流程节点、输入/输出参数和异常处理。

       订单服务是集成服务，负责调用账户服务和库存服务实现业务逻辑。在OrderServiceImpl中启动状态机，保存订单时使用OrderSaveImpl对应JSON文件中的orderSave，并在出现异常时回滚至deleteOrder。调用账户服务和库存服务时，使用feign实现，补偿逻辑分别对应CompensateDecrease。

       库存服务和账户服务类似，提供HTTP接口，包括扣减库存和补偿扣减库存的方法。账户服务的实现逻辑与库存服务相仿，不在代码中详细展示。

       进行实验时，各服务拥有独立数据库，cythonize源码无需贴SQL代码。实验开始前，确保订单表为空，账户和库存表已有数据。在成功下单后，账户表和库存表更新。若修改库存服务的decrease方法，导致下单过程中抛出异常，系统将依次执行补偿操作，确保最终事务一致性，表数据保持不变。

       Seata中的saga模式适用于复杂流程或长事务场景，但引入状态机增加了复杂性，需要开发者定义流程和补偿机制，确保回滚失败时能够有效控制整个事务。

对话鲁直：蚂蚁金服中间件的开源头羊 | 穿山甲专访

       受访者：鲁直，蚂蚁金服SOFA开源负责人。

       采访者：老王，开源布道人，拥有年互联网从业经验的技术老兵。

       从SOFA4到SOFA5的转变，标志着SOFA架构的进化，从传统架构转向更加面向未来，特别是考虑云时代的需求。SOFA4更多是对内部技术框架的整理和优化，为对外开源铺平道路。而SOFA5则更专注于云能力的实现，如Serverless等技术。

       在SOFA5中，Service Mesh成为了一个重要方向。鲁直强调，Service Mesh是迈向未来的关键一步，它将基础设施层的管理从业务逻辑中剥离，让业务更加专注于代码，而无需过多关注基础设施。这不仅提高了开发效率，也提升了资源利用效率，为业务提供了更加灵活和高效的基础设施支持。

       阿里巴巴在分布式事务领域拥有深厚的技术积累。基于此，阿里巴巴中间件团队推出了Seata，而蚂蚁金服则开源了自己的分布式事务框架，并与Seata合并共建分布式事务解决方案。这种合作旨在提供更广泛、更兼容的分布式事务解决方案，满足不同业务场景的需求。

       作为开源核心模式的实践者，蚂蚁金服在开源工作中遵循一套完善的原则和流程。首先，代码是开源的基础，同时提供示例、贡献者指南等文档支持，以促进社区参与。鲁直强调，开源项目的活跃度需要通过理性数据评估，以确保项目持续发展和改进。

深度解析阿里巴巴对账系统：分布式事务一致性挑战！

       大家好，我是小米！今天，我们将深入探讨分布式事务一致性这一核心问题，以及如何通过避免使用分布式事务和采用轻量级方案来确保数据一致性。在分布式系统中，分布式事务一致性挑战不容忽视，但通过合理规划与实施，可以有效解决这一难题。

       避免使用分布式事务和采用轻量级方案，是保证数据一致性的关键策略。首先，我们需要明确为何避免分布式事务。复杂度高、额外性能开销以及系统稳定性风险是分布式事务的主要挑战。因此，考虑单进程内的事务操作，可以利用数据库事务；对于跨进程通信，则可采用消息队列进行异步通信，以实现解耦与提高系统的整体稳定性。

       为了深入理解分布式系统事务一致性实现，我们将探讨主流方案、理论上可行但不推荐的方案，以及本地数据库事务原理。理论上的方案如两阶段提交（2PC）和三阶段提交（3PC）虽然在理论上可保证一致性，但在实际应用中存在诸多问题，如单点故障、性能瓶颈和事务阻塞。相比之下，补偿事务（TCC）和长事务（SAGA）机制虽然复杂度较高，但适合特定业务场景。

       接下来，我们将介绍分布式事务原理，包括全局事务协调器、全局锁和本地数据库事务在保证一致性中的作用。全局事务协调器负责协调参与者节点的事务执行顺序，全局锁则防止多节点同时修改同一数据，而本地数据库事务通过undo log、redo log、数据库锁和多版本并发控制（MVCC）来确保数据的一致性。

       在实际应用中，我们推荐采用自研补偿/MQ方案+人工介入的方式。这旨在减少性能损失，提高系统的可控性和可维护性。通过轻量级方案和消息队列配合，我们不仅保证了数据一致性，还提升了系统性能和可维护性，为用户提供了更好的服务体验。

       同时，对于Seata AT模式和RocketMQ事务消息，我们给出了不推荐的建议。Seata AT模式在分布式事务处理中可能导致性能降低，而RocketMQ事务消息在某些业务场景下可能不适用，特别是同步性强的处理链路。因此，我们需要根据实际业务需求选择合适的方案。

       最后，确保消息被下游MQ消费方成功消费至关重要，这关系到数据的一致性和系统的稳定性。实现幂等性是关键，通过设计幂等性处理逻辑，如添加唯一标识或版本号，以及在数据库操作中使用唯一索引或乐观锁，可以有效避免重复消费和数据错误。

       分布式事务一致性挑战是分布式系统架构中的重要议题，需要深入理解和合理规划。通过上述讨论，我们希望为读者提供了一种全面且实用的方法论，以解决这一挑战。在实际应用中，结合业务需求与技术特点，选择合适的方案，可以有效保障分布式系统的高效运行和数据一致性。欢迎读者在下方留言，与我们一起探讨更多技术问题。

Seata：分布式事务岂能少了它

AT模式：非侵入式，自动管理事务，简化开发，但需依赖Seata Server协调器和数据库适配。

TCC模式：侵入式，业务方控制事务流程，适用于独立部署的SOA服务，对锁定粒度有更高灵活性。

Saga模式：补偿型，长事务解决方案，由业务开发实现正向服务和补偿服务。

XA模式：两阶段提交，适用于强一致性的分布式事务场景，通过协调器协调参与者。

详解阿里开源分布式事务框架Seata

       Seata发展历史

       始于年，阿里集团内部为解决分布式事务问题，研发了TXC，支持AT和MT模式，广泛应用于内部业务，主要解决HSF服务框架下的数据库一致性问题。年，以云服务形式推出GTS，服务于众多大型私有云和公有云用户。年1月，阿里巴巴中间件团队推出了Fescar，面向开源社区，目标是简化分布式事务的使用，逐步解决开发者遇到的难题。蚂蚁金服加入共建，后项目更名为Seata。

       Seata总体架构

       Seata架构简洁，由三个核心角色：TM、RM和TC组成。TM和RM以SDK形式集成至业务系统，TC作为服务端独立部署。主要流程包括：TM发起分布式事务，TC协调资源管理，RM执行事务。

       Seata事务模式

       Seata支持四种模式：AT、TCC、Saga、XA。AT模式对业务无侵入，简化事务处理，用户只需添加注解@GlobalTransactional。TCC模式则需要用户实现try、confirm和cancel方法，实现正向和反向操作。AT模式和TCC模式的区别在于接入成本、作用范围和事务控制方式。

       举例说明

       “扣钱”场景中，接入TCC模式前，单条SQL即可完成操作。接入后，需要拆分为两阶段，try方法预留资源，confirm方法执行扣款，cancel方法释放预留资源。此模式对业务逻辑复杂度增加。

       Saga模式

       Saga模式基于Hector和Kenneth的论文，是一种补偿协议，适用于长事务流程，通过正向服务和逆向回滚服务实现事务一致性，但具有较高业务侵入性。

       XA模式

       在XA模式中，通过支持XA协议的事务资源管理分布式事务，保障数据一致性，但要求事务资源支持协议规范。

       Seata的优势在于简化分布式事务处理，支持多种模式，但不同模式适用场景不同，AT模式因其无侵入性受到欢迎。本文出自《正本清源分布式事务之Seata（全彩）》一书，欲了解更多细节，推荐阅读。

初识Seata

       Seata是一种分布式事务解决方案，由蚂蚁金服和阿里巴巴在年1月开源。它旨在提供高性能和易于使用的分布式事务服务，为用户提供一站式的解决方案。

       Seata官网提供详细的文档和播客，涵盖了使用说明和源码分析等内容。架构上，Seata由三个关键角色组成，其总体架构如图所示。Seata提供四种分布式事务解决方案，每一个都离不开TC，即事务协调者。

       部署TC服务时，可参考博主之前的文章，链接如下。微服务集成Seata时，以order-service为例进行演示。首先，需要在order-service中引入依赖。接着，在application.yml中配置TC服务信息，通过注册中心nacos结合服务名称获取TC地址。微服务如何找到TC的地址，我们知道注册到Nacos中的微服务确定一个实例需要四个信息，这些信息在配置文件中都能找到。

       配置完成后，其他服务按照类似步骤进行。接下来，我们学习Seata中的四种事务模式。首先介绍的是XA模式，它是X/Open组织定义的分布式事务处理标准。Seata对原始的XA模式做了封装和改造，基本架构如图所示。在AT模式中，我们弥补了XA模式中资源锁定周期过长的缺陷。AT模式下，当前分支事务执行流程分为两个阶段，一阶段RM的工作包括注册分支事务到TC、执行分支业务SQL但不提交以及报告执行状态到TC。二阶段TC和RM的工作分别包括TC通知事务结束、TC检查分支事务状态和RM在提交或回滚时的工作。

       在AT模式下，我们通过一个真实的业务来梳理其原理。接着，我们简述了AT模式与XA模式最大的区别，并讨论了脏写问题及其解决思路。AT模式的优点在于不锁数据库，缺点是需要额外的表记录全局锁和数据快照。实现AT模式时，需要导入数据库表，记录全局锁和数据快照，并在application.yml文件中修改事务模式。

       在TCC模式中，每一个阶段都是独立事务，通过人工编码来实现数据恢复。我们通过一个例子来分析TCC模式的流程，包括初始余额、冻结操作、提交操作和回滚操作。Seata中的TCC模型依然沿用事务架构。TCC模式的每个阶段分别对应正向操作和逆向回滚操作，优点是支持复杂业务场景，缺点是需要实现额外的逻辑。实现TCC模式时，需要定义状态表并改造服务，声明TCC接口和编写实现类。

       Saga模式是Seata即将开源的长事务解决方案，基于Hector & Kenneth在年的论文Sagas。在Saga模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务。Saga也分为两个阶段，优点是可以处理复杂的业务场景，缺点是实现复杂。我们通过对比四种实现方式来了解其特点。

       Seata的TC服务作为分布式事务的核心，必须保证集群的高可用性。搭建TC服务集群很简单，只需启动多个TC服务并注册到nacos。为了确保安全性，一般会实现异地多机房容灾，例如在上海和杭州分别部署TC集群。微服务基于事务组与TC集群的映射关系查找当前使用的TC集群，当集群出现故障时，通过修改映射关系实现集群切换。

       实现高可用的具体步骤和链接请参考相关文档。希望这些内容能帮助您更好地理解Seata和分布式事务。如果您有任何疑问，欢迎访问博主的个人开源博客地址: chengke.net。