大写的服，看完这篇你还不懂RocketMQ算我输

目录

1. RocketMQ介绍
2. RocketMQ概念
3. 为什么要用RocketMQ？
   1. 异步解耦
   2. 削峰填谷
   3. 分布式事务最终一致性
   4. 数据分发
4. RocketMQ架构
5. RocketMQ消息类型
   1. 普通消息
   2. 顺序消息
   3. 定时消息
   4. 事务消息
6. 最佳实践
   1. 消息重试
   2. 消息过滤
   3. 消费模式
   4. 消费幂等
7. 本地事务消息封装
8. 参考代码

RocketMQ 介绍

Apache RocketMQ 是一款 低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。

RocketMQ 概念

• Topic：消息主题，用于将一类的消息进行归类，比如订单主题，就是所有订单相关的消息都可以由这个主题去承载，生产者向这个主题发送消息。
• 生产者：负责生产消息并发送消息到 Topic 的角色。
• 消费者：负责从 Topic 接收并消费消息 的角色。
• 消息：生产者向 Topic 发送的内容，会被消费者消费。
• 消息属性：生产者发送的时候可以为消息自定义一些业务相关的属性，比如 Message Key 和 Tag 等。
• Group：一类生产者或消费者，这类生产者或消费者通常生产或消费同一类消息，且消息发布或订阅的逻辑一致。

为什么要使用 RocketMQ？

异步解耦

随着微服务架构的流行，服务之间的关系梳理非常重要。异步解耦可以降低服务之间的耦合程度，同时也能提高服务的吞吐量。

使用异步解耦的业务场景非常多，因为每个行业的业务都会不太一样，以一些比较通用的业务来说明相信大家都能理解。

比如电商行业的下单业务场景，以最简单的下单流程来说，下单流程如下：

1. 锁库存
2. 创建订单
3. 用户支付
4. 扣减库存
5. 给用户发送购买短信通知
6. 给用户增加积分
7. 通知商家发货

我们以下单成功后，用户进行支付，支付完成会有个逻辑叫支付回调，在回调里面需要去做一些业务逻辑。首先来看下同步处理需要花费的时间，如下图：

上面的下单流程从 3 到 5 都是可以采用异步流程进行处理，对于用户来说，支付完成后他就不需要关注后面的流程了。后台慢慢处理就行了，这样就能简化三个步骤，提高回调的处理时间。

削峰填谷

削峰填谷指的是在大流量的冲击下，利用 RocketMQ 可以抗住瞬时的大流量，保护系统的稳定性，提升用户体验。

在电商行业，最常见的流量冲击就是秒杀活动了，利用 RocketMQ 来实现一个完整的秒杀业务还是与很多需要做的工作，不在本文的范围内，后面有机会可以单独跟大家聊聊。想告诉大家的是像诸如此类的场景可以利用 RocketMQ 来扛住高并发，前提是业务场景支持异步处理。