diff --git a/MQ/RocketMQ.md b/MQ/RocketMQ.md index 369389d..63c639c 100644 --- a/MQ/RocketMQ.md +++ b/MQ/RocketMQ.md @@ -7,12 +7,64 @@ -# 普通消息 +# 普通消息的使用场景 -普通消息一般应用于微服务解耦、事件驱动、数据集成等场景，微服务每个服务都是独立的，通过MQ实现异步通信是常用的一种方式。 +## 微服务解耦 +## 异步执行事件 + +## 数据集成 + +## 普通消息的声明周期 + + + +- 初始化：生产者构建并完成初始化，待发送到服务端 +- 待消费：发送到服务端，对消费者可见，等待消费 +- 消费中：被消费者处理，服务端会等待消费完成，如果没有收到消费者的响应，会进行重试。 +- 消费提交：消费者完成消费处理，向服务端提交消费结果，服务端标记当前消息已经被处理，消费成功、失败 +- 删除消息：在消息到期或存储空间不足时，将消息从物理文件中删除 + +发送消息时，可以设置一个key，方便查询消息轨迹。这个key最好是唯一的，比如订单编号、用户ID、Trace等。 + +# 延时/定时消息 + +**生产者设置好消息的定时时间，服务端按时投递给消费者**。一个典型的场景：用户在业务系统中发起支付，创建一笔支付单后，5分钟未付款关闭支付单。 + +## 注意事项 + +- 定时的时间是一个毫秒级 Unix 时间戳 +- 必须设置在24小时范围内，超过范围不生效 +- 若设置在当前时间之前，服务端将立即投递 + +## 声明周期 + + + +相比普通消息，在初始化和待消费之间，加了一个定时中的状态。服务端将延时消息单独存储，到时间以后再挪到普通消息的存储位置，暴露给消费者进行消费。 + +⚠️如果大量的延时消息在同一时刻触发，会造成系统压力过大、消息延迟，影响定时精度，尽量打散定时时间。 + +# 顺序消息 + +典型的应用场景：有序的事件处理、数据实时增量同步，比如用canal同步mysql的binlog至ES或其他存储介质。 + + + + +顺序消息的关系是通过 Message Group 识别的，生产者发送顺序消息时，需要为每条顺序消息设置 Message Group。相同 Message Group 的消息遵循 FIFO 原则。所以有以下两个限制需要关注： + +- 必须一个生产者一个 Message Group 才能保障顺序性，不同的生产者设置同一个 Message Group 是无法保证顺序性的 +- 串行发送，使用多线程并行发送的话，也无法保障顺序性 + +## 存储逻辑 + +相同的消息组按照先后顺序存储到同一个队列，不同消息组的消息可以混在同一个队列，但是不一定连续。 + + +