[rocketmq] 如何保证消息可靠性

消息可能丢失的阶段

1、生产者发送消息到Broker时；

2、Broker内部存储消息到磁盘以及主从复制同步时；

3、Broker把消息推送给消费者或者消费者主动拉取消息时；

生产者发送消息：

1.重试策略，发送消息失败后会进行一定的重试策略
重试机制：固定重试次数，同步刷盘会切换 broker 重试，异步刷盘会在同一 broker 重试，服务端向 broker 超时不会重试。

2.同步发送，阻塞后续流程，即业务端获取到 mq 返回的 ack 后再继续进行。

3.异步发送，不阻塞后续流程，发消息时传入回调接口，另起线程获取返回信息。

4.Oneway发送： Oneway 方式只负责发送请求，不等待应答，Producer只负责把请求发出去，而不处理响应结果。

broker 保存消息：

1.数据从pagecache刷新到磁盘有两种方式，同步刷盘和异步刷盘。
同步刷盘：生产者发送消息同步进行落盘后返回 ack(若耗时过长可能会重复)。
异步刷盘：生产者发送消息后保存到 pagecache 后即返回 ack，再异步进行落盘，若未落盘宕机会丢失部分消息。

2.主从
多Master多Slave模式的同步复制实现，master 会等 slave 也写入成功后才返回 ack，存在 master 宕机后 slave 不升级的问题。
多 master多Slave 异步复制：master 写入成功后即返回 ack，主备可切换

消费消息阶段

消费者拿到消息有两种模式：pull/push
pull：消费者主动拉取消息
push：将消息推送给消费者
rocketmq 默认提供At least once机制：

● At least once: 至少一次。消息在传递时，至少会被送达一次。也就是说，不允许丢消息，但是允许有少量重复消息出现。

1.消息重试机制

2.消息失败次数达到最大重试次数后会进入死信队列。可对死信队列进行监控告警，可人为介入。

3.通常消费消息的ack机制一般分为两种思路：
● 先提交后消费；
● 先消费，消费成功后再提交；
思路一可以解决重复消费的问题但是会丢失消息，因此Rocketmq默认实现的是思路二，由各自consumer业务方保证幂等来解决重复消费问题。