RocketMq

架构

Name Server: 是一个几乎无状态节点，可集群部署，在消息队列 RocketMQ 中提供命名服务，更新和发现 Broker 服务。
Broker：分为 Master Broker 和 Slave Broker，一个 Master Broker 可以对应多个 Slave Broker，但是一个 Slave Broker 只能对应一个 Master Broker。Broker 启动后需要完成一次将自己注册至 Name Server 的操作；随后每隔 30s 定期向 Name Server 上报 Topic 路由信息。
Producer：与 Name Server 集群中的其中一个节点（随机）建立长链接（Keep-alive），定期从 Name Server 读取 Topic 路由信息，并向提供 Topic 服务的 Master Broker 建立长链接，且定时向 Master Broker 发送心跳。
Consumer： 与 Name Server 集群中的其中一个节点（随机）建立长连接，定期从 Name Server 拉取 Topic 路由信息，并向提供 Topic 服务的 Master Broker、Slave Broker 建立长连接，且定时向 Master Broker、Slave Broker 发送心跳。Consumer 既可以从 Master Broker 订阅消息，也可以从 Slave Broker 订阅消息，订阅规则由 Broker 配置决定。

发布订阅模型

实例
机器
进程
对象

Broker回调 确认事物状态

一个 Consumer 对应一个 Group ID，一个 Group ID 可以订阅多个 Topic

Topic业务消息分类
Tag 二级分类 允许Tag过滤

消息类型是否一致：如普通消息，事务消息，定时消息，顺序消息，不同的消息类型使用不同的 Topic，无法通过 Tag 进行区分。

业务是否相关联：没有直接关联的消息，如淘宝交易消息，京东物流消息使用不同的 Topic 进行区分；而同样是天猫交易消息，电器类订单、女装类订单、化妆品类订单的消息可以用 Tag 进行区分。

消息优先级是否一致：如同样是物流消息，盒马必须小时内送达，天猫超市 24 小时内送达，淘宝物流则相对会会慢一些，不同优先级的消息用不同的 Topic 进行区分。

消息量级是否相当：有些业务消息虽然量小但是实时性要求高，如果跟某些万亿量级的消息使用同一个 Topic，则有可能会因为过长的等待时间而『饿死』，此时需要将不同量级的消息进行拆分，使用不同的 Topic。

幂等性 唯一key处理

发送时重复

接受时重复 MEssgeId相同

负载均衡问题

建议根据业务唯一标识处理

订阅关系一致

尽量保持同一GroupId订阅下的TOPIC TAG一致

事物消息大小64k

消息实例

发送消息的3种方式
可靠同步发送、可靠异步发送、单向（Oneway）发送。

顺序 可靠同步

同步发送是指消息发送方发出数据后，会在收到接收方发回响应之后才发下一个数据包的通讯方式。

例如重要通知邮件、报名短信通知、营销短信系统等。

异步发送是指发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式

需要用户实现异步发送回调接口（SendCallback）

异步发送一般用于链路耗时较长，对 RT 响应时间较为敏感的业务场景，例如用户视频上传后通知启动转码服务，转码完成后通知推送转码结果等。

单向（Oneway）发送特点为发送方只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不等待应答。 此方式发送消息的过程耗时非常短，一般在微秒级别。

发送方式 发送 TPS 发送结果反馈 可靠性
同步发送 快 有 不丢失
异步发送 快 有 不丢失
单向发送 最快 无 可能丢失

发消息前 需要调用start启用

同步发送不抛异常就是成功

销毁对象

sendAsync

new SendCallback()

CallBack之前可取得messageId

producer.sendOneway

在同一个生产者或消费者实例里采用多线程发送或接收消息，从而提高消息发送或接收 TPS。 请避免为每个线程创建一个客户端实例。

广播模式下 无法堆积 报警

定时消息和延时消息适用于以下一些场景：

消息生产和消费有时间窗口要求：比如在电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条 延时消息。这条消息将会在 30 分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。 如支付未完成，则关闭订单。如已完成支付则忽略。
通过消息触发一些定时任务，比如在某一固定时间点向用户发送提醒消息。

msg.setStartDeliverTime

long timeStamp = new SimpleDateFormat(“yyyy-MM-dd HH:mm:ss”).parse(“2016-03-07 16:21:00”).getTime();
msg.setStartDeliverTime(timeStamp);

// 延时消息，单位毫秒（ms），在指定延迟时间（当前时间之后）进行投递，例如消息在 3 秒后投递
long delayTime = System.currentTimeMillis() + 3000;
// 设置消息需要被投递的时间
msg.setStartDeliverTime(delayTime);

顺序消息（FIFO 消息）是消息队列 RocketMQ 提供的一种严格按照顺序进行发布和消费的消息类型。 顺序消息指消息发布和消息消费都按顺序进行。

顺序发布：对于指定的一个 Topic，客户端将按照一定的先后顺序发送消息。

顺序消费：对于指定的一个 Topic，按照一定的先后顺序接收消息，即先发送的消息一定会先被客户端接收到。

性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景。

示例

在证券处理中，以人民币兑换美元为 Topic，在价格相同的情况下，先出价者优先处理，则可以通过全局顺序的方式按照 FIFO 的方式进行发布和消费。

性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。

示例

例一：用户注册需要发送发验证码，以用户 ID 作为 sharding key， 那么同一个用户发送的消息都会按照先后顺序来发布和消费。

例二：电商的订单创建，以订单 ID 作为 sharding key，那么同一个订单相关的创建订单消息、订单支付消息、订单退款消息、订单物流消息都会按照先后顺序来发布和消费。

顺序消息暂不支持广播模式。
建议同一个 Group ID 只对应一种类型的 Topic，即不同时用于顺序消息和无序消息的收发。
顺序消息不支持异步发送方式，否则将无法严格保证顺序。
对于全局顺序消息，建议创建实例个数 >=2。 同时运行多个实例的作用是为了防止工作实例意外退出时，业务中断。 当工作实例退出时，其他实例可以立即接手工作，不会导致业务中断，实际同时工作的只会有一个实例。

顺序消息 不支持事物

顺序消息支持同步

事物消息 版消息 消息回查

购物车 系统 交易系统

事务消息的 Group ID 不能与其他类型消息的 Group ID 共用。与其他类型的消息不同，事务消息有回查机制，回查时消息队列 RocketMQ 服务端会根据 Group ID 去查询客户端。

通过 ONSFactory.createTransactionProducer 创建事务消息的 Producer 时必须指定 LocalTransactionChecker 的实现类，处理异常情况下事务消息的回查。

事务消息发送完成本地事务后，可在 execute 方法中返回以下三种状态：

TransactionStatus.CommitTransaction 提交事务，允许订阅方消费该消息。
TransactionStatus.RollbackTransaction 回滚事务，消息将被丢弃不允许消费。
TransactionStatus.Unknow 暂时无法判断状态，期待固定时间以后消息队列 RocketMQ 服务端向发送方进行消息回查。
可通过以下方式给每条消息设定第一次消息回查的最快时间：

Message message = new Message();
// 在消息属性中添加第一次消息回查的最快时间，单位秒。例如，以下设置实际第一次回查时间为 120 秒 ~ 125 秒之间
message.putUserProperties(PropertyKeyConst.CheckImmunityTimeInSeconds,“120”);
// 以上方式只确定事务消息的第一次回查的最快时间，实际回查时间向后浮动0~5秒；如第一次回查后事务仍未提交，后续

顺序消费 处理阻塞的情况

无序消息 广播模式不会重试

最多重试 16此 2小时

集群消费方式下，消息消费失败后期望消息重试，需要在消息监听器接口的实现中明确进行配置（三种方式任选一种）：

返回 Action.ReconsumeLater （推荐）
返回 Null
抛出异常

配置覆盖

huo’z’qu

通过message可以获取重试次数

以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，比如订单创建消息（order）、支付消息（pay）、物流消息（logistics）。 这些消息会发送到 Topic 为 Trade_Topic 的队列中，被各个不同的系统所接收，比如支付系统、物流系统、交易成功率分析系统、实时计算系统等。

上游实时计算模块发布商品价格变更的信息，异步通知到下游商品管理模块进行价格变更。此时，需要保证每一条信息的消费幂等，即重复的价格变更信息只会生效一次，这样便不会发生价格多次重复修改的情况，确保实现了消息消费的幂等。

广播模式 不支持顺序 事物
消费进度在客户端维护，出现重复的概率稍大于集群模式。

失败不会重投

广播模式下，客户端每一次重启都会从最新消息消费。客户端在被停止期间发送至服务端的消息将会被自动跳过

广播模式下服务端不维护消费进度，所以消息队列 RocketMQ 控制台不支持消息堆积查询、消息堆积报警和订阅关系查询功能。

使用集群模式模拟广播：

如果业务需要使用广播模式，也可以创建多个 Group ID，用于订阅同一个 Topic。