简单了解RocketMQ

作用

异步：和同步相对，无需等待某些行为，可以直接继续往下执行

削峰限流：降低瞬时流量，避免系统宕机

解耦：解除业务上下游的耦合

和其它消息队列的对比

架构

消费模式

push模式：队列强制推送，实时性强，但是可能对消费端压力大

pull模式：消费者主动拉取，RocketMQ默认实现

生产者轮询发，消费者轮询取，并且消费者可以选择单线程（一个线程对应一个队列）或者多线程

消息类型

同步消息：生产者需要等待消息队列确认，适用于需要消息可靠性的

异步消息：生产者无需等待消息队列确认，只需要有个回调来确认消息是否收到，适用于需要响应快的

单向消息：生产者无需消息队列确认，消息可能丢失，适用于写日志（消费者接收msg写ES）

延时消息：消息到时间了才会被投递到消息队列，适用于延时取消订单

批量消息：很多消息被同时发送到同一个队列

顺序消息：消息被放到同一个队列里面（生产顺序），消息被单线程消费（消费顺序），单线程消费失败会无限次重试，多线程最多16次，超过16次放到死信队列

消息问题

消息区分

消息可通过 tag 或者 topic 进行区分，考虑业务类型以及业务体量，不同业务类型建议分成不同的topic，业务体量差异大建议分成不同的topic

消息重复

原因

1. 生产者重复投递
2. 消费者因为扩容重复消费，由于消费者端扩容采用负载均衡的机制，没有被确认的消息会被投递给新分配到的消费者

解决方案

消息自带的 msgid 或者 自定义key 来在消费者去重，做幂等性处理

消息重试

单线程消费失败会无限次重试，多线程最多16次，超过16次放到死信队列

%DSL% +topic名称 就是死信队列topic的名字，在死信队列我们一般不进行业务处理，选则把错误写入文件、邮箱短信通知人工处理

消息堆积

生产者和消费者的速率不均衡

解决方案

生产者：减少消息的发送，限流策略限制过多请求（请求频繁，请稍后重试）

消费者：增加消费者组内的消费者数量（但是不能超过队列数量），增大线程数（I/O 密集型 2N、CPU 密集型 N + 1）

消息丢失

消息持久化失败

同步刷盘：磁盘损坏

异步刷盘：buffer 内的脏消息断电后丢失