我们以一个转帐的场景为例来说明这个问题，Bob向Smith转账100块。这个列子在瓜子也有很多实际场景映射，如：车源状态变化，订单状态变化，金融放款，物流运输……
消息不能传递，当消息成功发送到Broker之后，Broker没有收到Producer的二次确认事件，消息被broker标记为暂时不能派发，这种状态下的消息就是Half(Prepare)Message。
MQ组件是系统架构里必不可少的一门利器，设计层面可以降低系统耦合度，高并发场景又可以起到削峰填谷的作用，从单体应用到集群部署方案，再到现在的微服务架构，MQ凭借其优秀的性能和高可靠性，得到了广泛的认可。 随着数据量增多，系统压力变大，开始出现这种现象：数据库已经更新了，但消息没发出来，或者消息先发了，但后来数据库更新失败了，结果研发童鞋各种数据修复，这种生产问题出现的概率不大，但让人很郁闷。这个其实就是数据库事务与MQ消息的一致性问题，简单来讲，数据库的事务跟普通MQ消息发送无法直接绑定与数据库事务绑定在一起，例如上面提及的两种问题场景：
由于在之前的博客中已经搭建了双Master，其实多Master多Slave大同小异，因此这里并不会一步步的演示搭建多Master多Slave，而是从思路上，分析下重点应该注意的配置项。
接 RocketMQ实战（一），RocketMQ实战（二），本篇博客主要讨论的话题是：顺序消费、RMQ在分布式事务中的应用等。
本篇文章聊聊消息队列相关的东西，内容局限于我们为什么要用消息队列，消息队列究竟解决了什么问题，消息队列的选型。
Apache RocketMQ 社区正式发布4.3版本。此次发布不仅包括提升性能，减少内存使用等原有特性增强，还修复了部分社区提出的若干问题，更重要的是该版本开源了社区最为关心的分布式事务消息，而且实现了对外部组件的零依赖。接下来，本文将详细探秘RocketMQ事务消息的设计原理以及实现机制。
"可靠消息最终一致性"是为了解决Producer端的消息发送与本地事务执行的原子性问题，是一种柔性事务，属于异步确保型，软状态，最终一致。
上一篇《我说分布式事务之消息最终一致性事务（一）：原理及实现》中，我们讲解了可靠消息最终一致性的实现原理及如何基于一款开源的消息中间件，实现一个可靠消息服务的思路。
- RocketMQ采用了分布式部署架构，允许生产者、消费者和消息队列实例分布在不同节点上，从而实现水平扩展和高可用性。
这周RocketMQ发布了4.3.0版本，New Feature中最受关注的一点就是支持了事务消息：
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。例如在大型电商系统中，下单接口通常会扣减库存、减去优惠、生成订单 id, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
prepare：将消息（消息上带有事务标识）投递到一个名为RMS_SYS_TRANS_HALF_TOPIC的topic中， 而不是投递到真正的topic中。
本文来自 Apache RocketMQ 的资深用户丁威，他和 MyCat 的核心开发者周继锋合著了《RocketMQ技术内幕：架构设计与实现原理》一书，目的是希望用图解的方式梳理 RocketMQ的核心原理。
RocketMQ提供了事务消息的功能，采用2PC(两段式协议)+补偿机制（事务回查）的分布式事务功能，通过消息队列 RocketMQ 版事务消息能达到分布式事务的最终一致。
a. fork下来，起一个demo，上一个测试环境，遇到问题再去社区提问或找些实践文章；
在2007年的时候，淘宝实施了“五彩石”项目，“五彩石”用于将交易系统从单机变成分布式，也是在这个过程中产生了阿里巴巴第一代消息引擎——Notify。在2010年的时候，阿里巴巴B2B部门基于ActiveMQ的5.1版本也开发了自己的一款消息引擎，称为Napoli，这款消息引擎在B2B里面广泛地被使用，不仅仅是在交易领域，在很多的后台异步解耦等方面也得到了广泛的应用。在2011年的时候，业界出现了现在被很多大数据领域所推崇的Kafka消息引擎，阿里在研究了Kafka的整体机制和架构设计之后，基于Kafka的设计使用Java进行了完全重写并推出了MetaQ 1.0版本，主要是用于解决顺序消息和海量堆积的问题。而在2012年，阿里对于MetaQ进行了架构重组升级，开发出了MetaQ 2.0，这时就发现MetaQ原本基于Kafka的架构在阿里巴巴如此庞大的体系下很难进行水平扩展，所以在2012年的时候就开发了RocketMQ 3.0版本。很多人会问到RocketMQ 3.0和MetaQ 3.0的区别，其实这两者是等价的版本，只不过阿里内部使用的称为MetaQ 3.0，外部开源称之为RocketMQ 3.0。在2015年，又基于RocketMQ开发了阿里云上的Aliware MQ和Notify 3.0。在2016年的时候，阿里巴巴将RocketMQ的内核引擎捐赠给了Apache基金会。
终于到了今天了，终于要讲RocketMQ最牛X的功能了，那就是事务消息。为什么事务消息被吹的比较热呢？近几年微服务大行其道，整个系统被切成了多个服务，每个服务掌管着一个数据库。那么多个数据库之间的数据一致性就成了问题，虽然有像XA这种强一致性事务的支持，但是这种强一致性在互联网的应用中并不适合，人们还是更倾向于使用最终一致性的解决方案，在最终一致性的解决方案中，使用MQ保证各个系统之间的数据一致性又是首选。
在微服务架构中，随着服务的逐步拆分，数据库私有已经成为共识，这也导致所面临的分布式事务问题成为微服务落地过程中一个非常难以逾越的障碍，但是目前尚没有一个完整通用的解决方案。
目前云计算、大数据、互联网领域的大部分系统都采用了SOA、微服务化的架构。一个涉及端到端全链路的业务操作往往会由多个服务和数据库实例共同完成。因此，在一致性要求较高的业务场景中，如何保证多个服务之间RPC调用后的数据一致将成为关键点。
本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看
一说起事务，容易联想到数据库。我们日常使用事务的场景，绝大部分都是在操作数据库的时候。像 MySQL、Oracle这些主流的关系型数据库，也都提供了完整的事务实现。
2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
最近在找工作,面试过程中被多次问到事务消息的实现原理,另外在分布式事务解决方案中,事务消息也是一个不错的解决方案,本篇文章将围绕RocketMQ的事务消息实现展开描述。
事务消息是RocketMQ提供的非常重要的一个特性，在4.x版本之后开源，可以利用事务消息轻松地实现分布式事务。本文对RocketMQ的事务消息进行详细介绍，并给出了代码示例。
“发消息”过程，往往是为通知另外一个系统更新数据，MQ的“事务”，主要解决消息生产者和消息消费者的数据一致性问题。
事务消息是分布式事务的一种解决方案，RocketMQ 有成熟的事务消息模型，今天就来聊一聊 RocketMQ 事务消息实现机制。
关于CAP,BASE理论，以及TCC，seata解决方案，可以参考我上一篇博客.《Java分布式事务-seata,tcc解决方案总结》 本文是接着一篇继续的。
RocketMQ一个优点是有事务特性，可以保证事务的最终一致性。举一个简单的例子，以电商为例，创建订单ID9527被创建后要保存到数据库，通过该订单通过MQ投递给其他系统进行消费。如果要保证订单数据入库与消息投递状态要保证最终一致性，要怎么做？
我们在分布式环境下一个业务可能会涉及到多个模块之间的调用，为了保证操作的原子性，分布式事务是最好的解决方案。
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成，如下图：
RocketMQ事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致。
https://www.open-open.com/lib/view/open1421150566328.html
Kafka 事务与数据库的事务定义基本类似，主要是一个原子性：多个操作要么全部成功，要么全部失败。Kafka 中的事务可以使应用程序将消费消息、生产消息、提交消费位移当作原子操作来处理。 为了实现事务，Producer 应用程序必须做到：
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
上一篇文章我们将整个交易系统进行了微服务化，拆分为了多个相互独立的业务组件，每个业务组件不只是包含自己业务的微服务，还包括了独立管理的数据库。那么，我们来考虑下单的场景，用户下委托单的时候，主要有三步操作：一是冻结金额，二是新增订单，三是投递给到撮合引擎。这三步需要保证事务的一致性。在服务和数据库都不拆分的情况下，是很容易满足的。但拆分之后，这几个步骤的操作也分开到不同业务组件了，服务是分开的，数据库也是分开的。在这种分布式的环境下，又要如何保证事务的一致性，这就是分布式事务问题了。
事务是数据库从一个稳定状态变迁到另一个稳定状态的保证，具备 ACID 这 4 个特性：
最后，让我们看看如何打包和部署应用程序。这两个框架都支持Maven和Gradle等通用包管理技术。但是在部署方面，这些框架差异很大。例如，Spring Boot Maven插件在Maven中提供Spring Boot支持。它还允许打包可执行jar或war包并就地运行应用程序。
消息中间件的本身定义来考虑，应该尽量减少对于外部第三方中间件的依赖。一般来说依赖的外部系统越多，也会使得本身的设计越复杂，采用文件系统作为消息存储的方式。
DLedger 基于 raft 协议，故天然支持主从切换，即主节点(Leader)发生故障，会重新触发选主，在集群内再选举出新的主节点。
分布式事务学习项目：流量充值中心 git地址：https://github.com/barrywangmeng/data-refill-center
RocketMQ 是阿里巴巴开源的分布式消息中间件，它借鉴了 Kafka 实现，支持消息订阅与发布、顺序消息、事务消息、定时消息、消息回溯、死信队列等功能。RocketMQ 架构上主要分为四部分，如下图所示：
在微服务架构盛行的情况下，在分布式的多个服务中保证业务的一致性，即分布式事务就显得尤为重要。本文将讲述分布式事务及其解决方案，有XA协议、TCC和Saga事务模型、本地消息表、事务消息和阿里开源的Seata。
随着业务的快速发展、业务复杂度越来越高，几乎每个公司的系统都会从单体走向分布式，特别是转向微服务架构。随之而来就必然遇到分布式事务这个难题，这篇文章总结了分布式事务最经典的解决方案，分享给大家。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
