皮皮网

1.【RocketMQ系列】基于RocketMQ的源码分布式事务
2.分布式事务—LCN原理及使用方式
3.SQL到底可以分几种语言
4.可靠消息最终一致性分布式事务
5.如何理解tcc分布式事务?
6.分布式事务之TCC机制，一文给你讲透！源码

【RocketMQ系列】基于RocketMQ的源码分布式事务

       在RocketMQ系列的第三篇文章中，我们将深入探讨基于RocketMQ的源码分布式事务解决方案。在分布式系统中，源码服务间的源码涨停回调5天预警指标源码协作常面临事务一致性问题，尤其在涉及多个服务（如订单与支付）的源码场景下，确保从创建订单到支付再到状态更新的源码完整流程是原子性的至关重要。

       分布式事务的源码挑战在于，如订单服务与支付服务的源码交互中，如果支付成功但订单状态更新失败，源码一旦消息消费，源码无法回滚。源码为解决这个问题，源码出现了分布式事务解决方案，源码如两阶段提交（2PC）和补偿事务（TCC）。2PC通过协调者管理事务的提交或回滚，分为准备阶段和提交阶段，但可能存在同步阻塞和实现复杂性问题。TCC则引入补偿机制，通过预留资源避免阻塞，但编程负担较大。

       RocketMQ提供了分布式事务支持，利用其「事务消息」和半消息（预处理消息）机制来实现最终一致性。半消息在Broker收到后暂存，通过定时任务检查事务状态，如本地事务执行成功但确认消息失败，会进行消息回查，确保数据一致性。如果超时未得到回复，将默认回滚消息。生产者使用TransactionMQProducer发送事务消息，并设置TransactionListener监听事务状态，执行本地事务后根据结果回应队列检查请求。

       在代码示例中，生产者创建TransactionMQProducer并发送TagB的消息，然后消费者通过TAG过滤消费验证。完整代码可在GitHub的JavaJourney项目中查看。这标志着本次基于RocketMQ的分布式事务讲解告一段落，欢迎关注公众号「行百里er」获取更多内容。代码仓库也在GitHub，期待您的参与与交流。

分布式事务—LCN原理及使用方式

       探索分布式事务的守护者：LCN原理及实战指南

       在微服务和分布式系统的世界里，数据一致性是至关重要的。传统的解决方案如2PC和消息事务+最终一致性，各有优劣。让我们深入解析LCN框架，一种旨在提供分布式事务一致性协调的阿里飞冰源码创新模式。

       LCN事务模式：低代码的力量与同步挑战

       LCN模式以低代码嵌入为核心，允许本地事务进行控制，确保数据一致性。然而，这种模式要求连接释放时同步处理，这可能会增加连接占用的时间，对性能产生影响。

       TCC事务模式：灵活但代价高

       TCC（Try-Cancel-Confirm）模式提供了高度的灵活性，适用于各种复杂场景。但代价是业务开发的复杂度提升，每个操作都需要精心设计Try、Cancel和Confirm的流程。

       TXC事务模式：SQL世界的专精

       相比之下，TXC模式更为简化，仅支持SQL模块，但它的资源消耗和时间开销不可忽视，尤其是在数据库连接资源的管理上。

       LCN的幕后英雄：TxClient与TxManager

       LCN由TxClient和TxManager两大组件组成，发起或参与事务的决策由TxClient驱动。关键步骤包括创建事务组、加入事务组，并通过通知驱动整个事务流程。

       实战环境搭建：微服务与集成

       为了实现实战部署，你需要配置微服务、集成TxManager、Eureka服务发现和Redis缓存。访问事务调节器管理平台，通过地址.manager.admin-key）进行管理。

       注解驱动：轻松上手分布式事务

       通过引入POM依赖并添加@LcnTransaction注解，你可以轻松配置事务管理器的位置。同时，容灾处理和配置文件调整也是必不可少的环节。

       启动新旅程：开启分布式事务管理

       在启动类中加入@EnableDistributedTransaction，这将激活LCN注解，为你的应用开启分布式事务管理的新篇章。

       LCN不仅提供了一种在分布式环境中保持数据一致性的实用工具，还简化了开发者的操作。通过理解其原理和实践，你可以更好地利用这一框架提升系统的可靠性和性能。

SQL到底可以分几种语言

       DDL (Data Definition Language) 资料定义语言

       DML (Data Manipulation Language)资料处理语言

       DQL (Data Query Language)资料查询语言

       DCL (Data Control Language)资料控制语言

       DAC (Data Administration Commands)资料管理语言

       TCC (Transactional control commands)交易控制指令

       1. DDL：允许资料库使用者建立与重建资料库物件，如建立或更新删除表格。

        DDL指令 ：

       (1) CREATE TABLE (建立表格，属於概念层指令)

       (2) ALTER TABLE (修改表格，例如：增掩表格属性)

       (3) DROP TABLE (删除表格)

       (4) CREATE INDEX (建立索引表)

       (5) ALTER INDEX

       (6) DROP INDEX

       (7) CREATE VIEW (产生景观，属於外部纲目指令)

       (8) ALTER VIEW

       (9) DROP VIEW

       2. DML：用来插入、更新及删除关联式资料库的资料，DML有三个主要指令：insert、 delete、update。

       3. DQL：允许资料库使用者查询资料库中相关的资料。DQL只有一个select指令，这里的select指令与关联式代数的「选择」指令意义并不同。

       4. DCL：DCL控制使用者对资料库内容的存取权限。主要指令有：REVOKE删除权限、ALTER PASSWORD、GRANT授与权限、SYNONYM。

       5. DAC：允许使用者对使用中的资料库产生稽核与分析，共有两种主要指令：START AUDIT、STOP AUDIT。

       6. TCC：用来管理资料的交易。

        以下为主要指令：

       (1) COMMIT：确认资料库的交易。交易一旦确认就永久有效。

       (2) ROLLBACK：回复资料库的交易。使交易回到未被确认状态。

       (3) SAVEPOINT：设立群组内交易的指标。

       (4) SET TRANSACTION：为每一次交易命名。

       COMMIT、ROLLBACK、SAVEPOINT只能与DML的insert、delete、update指令一起使用。

可靠消息最终一致性分布式事务

       分布式事务一致性

       在分布式系统中，确保事务的一致性是一项关键需求。分布式事务的一致性要求，在多个节点上执行的事务要么全部成功，要么全部失败，不能出现部分成功部分失败的情况。然而，在分布式环境中，极品画线指标源码网络延迟、节点故障等问题使得实现事务一致性变得复杂。

       为解决这一难题，业界引入了“可靠消息最终一致性分布式事务”方案。该方案通过利用可靠消息服务，确保事务在执行过程中的一致性。

       具体操作如下：首先，当分布式事务开始执行时，系统会向可靠消息服务发送一个预备消息，该消息包含事务的所有细节，如参与者、操作等。接着，各个节点执行事务。若所有节点执行成功，则向消息服务发送确认消息；若存在节点执行失败，则发送取消消息。

       当消息服务收到确认消息，会删除预备消息，并向所有节点广播事务成功的消息。各节点接收到成功消息后提交事务。相反，收到取消消息后，消息服务会删除预备消息，并向所有节点广播事务失败的消息，各节点回滚事务。

       通过这种方式，即使在异常情况下，系统也能通过可靠消息服务恢复事务一致性。然而，这一方案依赖于可靠消息服务，其可用性和可靠性是实现方案的关键。

       实现可靠消息最终一致性分布式事务的常见技术包括：

       1. 基于MQ（消息队列）的可靠消息服务：如RabbitMQ、Kafka、RocketMQ，用于存储预备消息和传递事务状态。

       2. TCC（Try-Confirm-Cancel）模型：通过三个操作（Try、Confirm、Cancel）实现事务的一致性。

       3. Saga模式：将一个长事务分解为多个本地事务，每个本地事务都有对应的补偿事务，确保一致性。

       4. 基于XA协议的分布式事务：定义全局事务管理器和本地资源管理器的接口，但在互联网应用中较少使用。

       5. Seata：阿里巴巴开源的分布式事务解决方案，支持TCC、Saga和XA协议。移动平台源码搭建

       6. GTS（Global Transaction Service）：华为云提供的分布式事务一致性服务，支持全局事务、分布式锁和补偿事务，解决微服务数据一致性问题。

       这些方案各有优势，需根据实际业务需求和系统环境选择最合适的。

       以Kafka实现基于MQ的可靠消息最终一致性分布式事务为例：

       1. 预备阶段：业务启动前，向Kafka发送预备消息，包含事务详细信息。

       2. 执行阶段：各个事务参与者执行事务，成功后向Kafka发送确认消息；失败后发送取消消息。

       3. 提交阶段：Kafka接收到确认消息后，删除预备消息，向参与者广播事务成功消息；接收到取消消息后，删除预备消息，并广播事务失败消息。

       4. 恢复阶段：异常发生时，通过Kafka中的预备消息恢复事务，重新执行事务。

       注意Kafka消息顺序不保证，需额外机制确保消息顺序。为了消息可靠性，需配置持久化机制，如设置副本数、开启消息持久化。

       事务参与者在业务逻辑完成后，应发送确认或取消消息，提交或回滚操作在一个本地事务中完成，防止数据不一致。

       下面是一个Kafka Java API实现的简单示例：

       在尝试发送消息时，如果出现异常，终止事务，关闭生产者，确保消息不会被意外消费。

       使用Kafka实现分布式事务时，需考虑消息顺序、持久化和并发控制等。

       以下是一个使用Java API的Kafka分布式事务简单实现示例：

       首先初始化Kafka生产者并开启事务，尝试发送消息，如果所有消息发送成功，提交事务；如果发送过程中出现异常，则回滚事务。

       以下代码示例展示了如何使用Java API进行消息发送和消费。

       生产者和消费者通过分区和消费者组实现消息顺序、持久化和并发控制。

       RocketMQ实现最终一致性分布式事务主要通过以下步骤：

       1. 发送预备消息：事务发起者向RocketMQ发送预备消息，消息状态为“未决定”，搭建红手指源码消费者无法消费。

       2. 执行本地事务：消息发送成功后，执行数据库事务。事务执行结果决定消息状态。

       3. 提交或回滚预备消息：本地事务成功则提交，消息状态改为“可消费”；失败则回滚，删除消息。

       4. 消费者消费消息：只能消费状态为“可消费”的消息。

       RocketMQ的事务回查机制在未收到提交或回滚请求时，定期询问生产者，以确保事务的一致性。

       以下是一个使用Java和RocketMQ实现分布式事务的示例：

       首先创建事务监听器，然后创建生产者发送事务消息。

       在执行过程中，通过监听器控制本地事务的尝试、确认或取消。

       TCC模型将事务分解为三个阶段：

       Try阶段检查业务条件并预留资源；成功后进入Confirm阶段执行业务操作；失败则执行Cancel阶段撤销操作。

       TCC模型实现最终一致性，但需手动实现操作，增加了开发复杂性，并可能面临长时间事务未解决的问题。

       以下是一个模拟电商系统中用户下单和付款场景的TCC模型实现：

       订单服务依赖库存和账户服务，每个服务需实现Try、Confirm和Cancel操作。

       实际应用中，需处理并发、分布式事务优化和长时间运行事务等问题。

       以下是Saga模式实现分布式事务的基本步骤：

       定义每个本地事务及其补偿事务；按顺序执行本地事务；失败时执行补偿事务撤销。

       以下是一个电商下单场景的简化Java实现示例，展示Saga模式的基本思路。

       扩展：在分布式环境中，服务间通信通常通过RPC或消息队列实现，提高系统的扩展性和容错性。

       RPC和消息队列支持异步处理、负载均衡和容错处理，适用于分布式环境，优于直接调用Java方法。

如何理解tcc分布式事务?

       理解TCC分布式事务的关键在于确保全局事务的一致性，尤其在分布式环境下。TCC事务框架在实现过程中，必须基于资源管理器（RM）本地事务来实现全局事务，以确保当部分事务操作失败时，能够有效回滚或提交所有相关操作。基于RM本地事务的TCC事务框架可以将服务视为一个原子操作，一个本地事务的完成意味着所有与之关联的Try、Confirm、Cancel业务操作都生效，反之则都不生效。因此，TCC事务框架需要接管Spring容器的TransactionManager，以掌握每个本地事务的状态及其与业务方法之间的对应关系，从而有效构建TCC全局事务。

       在TCC事务框架中，接管Spring容器的TransactionManager是实现关键。通过此方式，TCC事务框架能够了解RM本地事务的状态，包括事务的创建、提交和回滚。这非常重要，因为TCC机制通过执行Cancel业务来达到回滚效果，只有生效的Try操作才需要执行对应的Cancel操作。如果Try操作所在的RM本地事务被rollback，后续全局事务回滚时就无需执行其Cancel操作。同样，Confirm/Cancel操作必须保证生效，它们也涉及RM数据存取操作，其参与的RM本地事务同样需要被commit。TCC事务框架需要确信所有Confirm/Cancel操作的RM本地事务都被成功commit，才能标记该TCC全局事务为完成。如果误判了事务状态，可能导致全局事务不一致。

       接管TransactionManager还能让TCC事务框架明确了解Spring的事务性指令，管理Spring容器中各服务的RM本地事务，避免出现业务系统中存在两套独立的事务处理逻辑，导致协调TCC全局事务困难。

       此外，TCC事务框架应具备故障恢复机制，以应对分布式系统中可能出现的服务器宕机、网络故障、断电等故障。记录事务日志是实现故障恢复的基础，通过日志数据，TCC事务框架能够将中断的事务恢复至正确状态，并在此基础上继续执行先前未完成的提交或回滚操作，确保全局事务的一致性。

       在TCC事务框架的设计中，保证Confirm/Cancel服务的幂等性也是非常关键的。幂等性要求针对同一个服务的多次请求和单次请求具有相同的副作用。由于Confirm/Cancel业务可能会被多次调用（例如，在全局事务提交或回滚时），TCC事务框架应该提供幂等性保障，而不是依赖业务系统自行解决。这可以避免因多次调用而引发的服务请求累积问题。

       在处理TCC服务的具体操作时，需要关注Cancel业务与Try业务的关系，尤其是在网络中断、超时等情况下，确保Try操作与Cancel操作的正确执行顺序。这涉及到TCC服务在尝试、确认、取消操作中的协调与同步。

       最后，TCC服务的设计不需要对外暴露三个服务接口，只需提供Try接口。Confirm与Cancel业务逻辑是TCC事务框架内部管理的，不需要其他业务服务直接调用。同时，TCC服务之间不应互相调用Confirm与Cancel方法，以避免引起全局事务关系混乱。

       综上所述，实现一个通用的TCC分布式事务管理框架需要考虑多个方面，包括基于RM本地事务实现全局事务、接管Spring容器的TransactionManager、故障恢复机制、幂等性保障、正确处理Cancel与Try操作之间的关系以及合理设计服务接口。通过这样的设计，可以有效管理分布式事务，确保全局数据一致性。

分布式事务之TCC机制，一文给你讲透！

       基于消息的分布式事务处理机制（文末有惊喜）

       基于消息的分布式事务处理机制可以总结为两个阶段：

       - 第一阶段：在事务发起方的本地事务中产生消息。例如，在transaction写入操作的同一个数据库事务中记录消息（消息入队），消息中包含了transaction的相关信息。

       - 第二阶段：消息的消费方提供幂等操作来处理这些消息。这分为两种情况：一种是业务自身提供幂等操作，业务在处理时通过一些业务标识字段来判断某一条消息是否已经被处理过；另一种情况，业务自身不支持幂等操作，则可以引入一个去重表来实现幂等性。例如，引入updates_applied表来判断消息是否被处理过。

       该机制具有以下特征：

       - 消息的处理是异步的。这意味着消息的生产方没有办法同步获取到消息的处理结果。这个特性限制了该机制只能适用于那些不要求各个业务方同步得到结果的情况。比如对于下单操作来说，用户积分的改动可能属于这类场景。

       - 整个流程无回滚或者补偿机制。消息消费方的处理失败并不会导致消息生产方已提交操作的回滚。对于消费方来说，在碰到提交失败的情况，只能反复重试直到提交成功。

       基于消息的机制总体来说比较简单。消息队列还能对消息起到削峰填谷的作用，所以不用担心分布式事务各个参与系统的性能是否匹配的问题。同时，该机制也不涉及回滚和补偿操作，总体来说实现成本较低。

       基于补偿的分布式事务处理机制

       有一些业务场景，要求各参与方能同步获取到执行结果。这类业务场景就不能用基于消息的机制了。

       比如，用户下单时，我们需要对用户钱包余额和库存做扣减。扣减成功与否，将直接影响当前下单结果。对于这类业务场景，整个分布式事务成功与否，取决于所有参与方的执行结果。

       对于这类业务场景，我们需要引入补偿机制。基于补偿机制的下单操作步骤如下：

       1. 创建订单，订单状态为处理中。

       2. 调用用户钱包服务，扣减用户钱包余额。

       3. 调用库存服务，扣减库存。

       4. 如果步骤2和步骤3都成功，则将订单状态改为成功。

       如果第3步执行失败，则需要调用第2步用户钱包服务的补偿操作，将余额的扣减补偿回去。

       相较于基于消息的机制来说，补偿机制需要给每个操作增加相应的补偿操作，从实现上来说更加复杂。

       TCC模式

       基于补偿的机制能很好地处理分布式事务各业务参与方同步获取执行结果的问题。但这个机制有一个问题，那就是会让用户看到即将被补偿的数据中间状态。

       比如上面提到的下单流程，如果第2步用户钱包扣减成功了，但第3步库存扣减失败了，整个事务本来会被回滚。但用户却在用户钱包服务的补偿操作被成功调用之前，看到了被错误扣减后的余额。

       这里我们引入TCC模式来解决这个问题：

       - Try阶段：完成业务检查，预留业务资源。

       - Confirm阶段：直接使用Try阶段预留的业务资源。

       - Cancel阶段：取消Try阶段预留的业务资源。

       我们继续用上面的下单操作来进一步解释TCC。

       用户钱包表wallet字段如下：

       为了达到业务资源预留的目的，我们为用户钱包服务引入一张余额冻结表balance_frozen_record，字段如下：

       用户钱包服务提供的几个关键API接口如下：

       - 余额查询接口（参数：wallet_id）。直接返回wallet表中的balance字段。

       - 余额冻结接口（参数：amount和wallet_id）。对应于Try阶段。如果amount小于该钱包的可用余额，则冻结成功，往balance_frozen_record插入一条state=true的记录；如果amount大于可用余额，则冻结失败。可用余额等于wallet表中的balance字段减去select sum(frozen_amount) from balance_frozen_record where wallet_id = $wallet_id and state = true。

       - 取消冻结接口（参数：record_id）。对应于Cancel阶段。等幂操作。只需要将balance_frozen_record中对应的记录状态设置为false即。

       - 确认提交接口（参数：record_id）。对应于Confirm阶段。等幂操作。将record_id对应金额变动反映到wallet表balance中，同时将该记录状态设置为false。亦即：

       TCC模式具有以下特点：

       - 未提交的中间状态将不再对用户可见。用户看到的余额不会反映这些中间状态。需要所有业务实现预留接口。

       - 大部分业务都能被改造成预留的方式，但某些业务不能预留，比如第三方公司提供的业务，那就没办法使用这种模式。

       上面使用冻结表的方式，还带来了另外一个好处。也就是将对wallet表中balance的并发修改操作，变成了数据库插入操作。在某种程度上提高了系统的吞吐量。

SpringCloud入门实战-分布式事务框架Seata简介

       在深入探讨分布式事务框架Seata之前，我们先回顾事务概念。事务是数据库中一组操作的集合，确保操作要么全部成功要么全部失败，以保持数据一致性。本地事务是单数据库场景下的事务，通常通过数据库系统提供的ACID特性来管理。然而，分布式事务涉及多个系统或数据库，需要确保全局数据一致性，这一需求远超本地事务范畴。

       分布式事务问题主要出现在微服务架构中，服务间依赖增加，导致数据一致性难以保证。当业务逻辑涉及跨多个数据库操作时，单个数据库的ACID特性无法直接应用于整个系统。网络延迟、节点故障等不确定因素使得分布式事务实现更为复杂。

       针对传统事务解决方案在分布式场景下的不足，出现了分布式事务的几种经典模式：AT、TCC、Saga和XA。每种模式都有其理论基础、适用场景和代表产品。例如，TCC模式（Try-Confirm-Cancel）允许服务在尝试执行事务前先确认资源可用性，确保事务的原子性和一致性。

       Seata（Simple Extensible Autonomous Transaction Architecture）是一个开源分布式事务解决方案，旨在提供高性能、易用的分布式事务服务。Seata支持AT、TCC、SAGA和XA模式，提供一站式的分布式事务管理。其通过分布式事务日志和分布式锁保障事务的一致性和可靠性，实现全局数据的统一管理。

       Seata的架构包括TC（Server端）、TM（Transaction Manager）和RM（Resource Manager）三个角色。TC负责维护全局事务状态，TM作为事务发起者和终结者，RM则管理本地事务并上报状态给TC。在分布式事务执行过程中，全局事务ID（XID）在调用链路中传递，确保服务间协同操作。

       Seata支持的配置中心用于管理服务端配置，与注册中心协同工作，保证服务的动态配置管理。Seata的存储模式包括数据库、文件系统和Redis等，通过store.mode配置来选择。

       接下来，我们将介绍如何在微服务架构中整合Seata。使用Seata通常需要与Nacos等配置中心集成，同时确保SpringBoot框架的兼容性。这一集成过程涉及到服务注册、配置加载和事务管理的自动化，简化了分布式事务的实施与管理，为微服务提供了更稳定的业务流程支持。