骏马逸动，心随你动的博客

我还记得第一次使用rocketmq的时候，需要去控制台预先创建topic，我当时就想为什么要这么设计，于是我决定撸一波源码，带大家从根源上吃透rocketmq topic的创建机制。topic在rocketmq的设计思想里，是作为同一个业务逻辑消息的组织形式，它仅仅是一个逻辑上的概念，而在一个topic下又包含若干个逻辑队列，即消息队列，消息内容实际是存放在队列中，而队列又存储在broker中，下面我用一张图来说明topic的存储模型：其实rocketmq中存在两种不同的topic创建方式，.

目录一、可靠消息最终一致性事务概述二、解决方案【本地消息表方案】三、解决方案【RocketMQ事务消息方案】四、RocketMQ实现可靠消息最终一致性事务五、总结一、可靠消息最终一致性事务概述可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成，如下图：事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息..

RocketMQ 核心组件图RocketMQ是开源的消息中间件，它主要由NameServer，Producer，Broker，Consumer四部分构成。NameServer：NameServer主要负责Topic和路由信息的管理，功能类似Dubbo的zookeeper。Producer：消息生产者，负责产生消息，一般由业务系统负责产生消息。Broker：消息中转角色，负责存储消息，转发消息。Consumer：消息消费者，负责消息消费，一般是后台系统负责异步消费。Rokce.

我们知道 RocketMQ 是一款高性能、高可靠的分布式消息中间件，高性能和高可靠是很难兼得的。因为要保证高可靠，那么数据就必须持久化到磁盘上，将数据持久化到磁盘，那么可能就不能保证高性能了。RocketMQ 在兼容这两方面做的不错，先从磁盘说起，现代的磁盘都是高性能的，写速度并不一定比网络的数据传输速度慢。比如 SSD 固态硬盘在 M.2 NVMe协议下，顺序写的速度可以达到 1500 MB/s，就算是普通磁盘，如果性能比较高的话，顺序写的速度可以达到 450MB/s~600MB/s。在顺序写的情

为什么写这篇文章?博主有两位朋友分别是小A和小B:小A，工作于传统软件行业(某社保局的软件外包公司)，每天工作内容就是和产品聊聊需求，改改业务逻辑。再不然就是和运营聊聊天，写几个SQL，生成下报表。又或者接到客服的通知，某某功能故障了，改改数据，然后下班部署上线。每天过的都是这种生活，技术零成长。 小B，工作于某国企，虽然能接触到一些中间件技术。然而，他只会订阅/发布消息。通俗点说，就是调调API。对为什么使用这些中间件啊？如何保证高可用啊？没有充分的认识。庆幸的是两位朋友都很有上进心，于是博主

延迟消息是实际开发中一个非常有用的功能，本文第一部分从整体上介绍秒级精度延迟消息的实现思路，在第二部分结合RocketMQ的延迟消息实现，进行细致的讲解，点出关键部分的源码。第三步介绍延迟消息与消息重试的关系。1 延迟消息介绍基本概念：延迟消息是指生产者发送消息发送消息后，不能立刻被消费者消费，需要等待指定的时间后才可以被消费。场景案例：用户下了一个订单之后，需要在指定时间内(例如30分钟)进行支付，在到期之前可以发送一个消息提醒用户进行支付。一些消息中间件的Broker端内置了延迟消息支持

目录前言一、事务消息二、订单服务1、事务日志表2、TransactionMQProducer3、OrderTransactionListener4、业务实现类5、调用6、总结三、积分服务1、积分记录表2、消费者启动3、消费者监听器4、增加积分5、幂等性消费6、消费异常四、《RocketMQ技术内幕》中的代码示例1、下单异常2、本地事务执行异常3、源码分析总结前言之前我们说到，分布式事务是一个复杂的技术问题。没有.

问题：在阿里云服务提供的消息队列服务（RocketMQ）中，给出了一份关于订阅关系一致的最佳实践，在文档中指出同一个 GroupID 中的所有消费者实例最好订阅同样的 Topic+Tag。这让我有一些疑问，为什么一个 GroupID 只能产生一种订阅，这样岂不是同一个应用需要订阅不同的 Topic 那么每一次都需要去申请一个 GroupID，这使得 GroupID 和 Topic 产生了一定的耦合关系，看起来是不太合理的，那么为什么 RocketMQ 要这么做呢？参考：https://blog.csd