消息队列-RockMQ-消息的可靠性

从哪些阶段来保证？

1 生产阶段
同步发送：预设一定的重试次数，重试CODE（ producer.addRetryResponseCode(ResponseCode.FLUSH_SLAVE_TIMEOUT);）
异步发送：使用待回调函数的异步发送，这个时候再回调函数中进行重试或者记录或者告警。
单向发送：(不推荐使用)：没有一定的保证机制来保证消息一定会投递到Broker;
2 储存阶段
Broker 突然 Crash：可以由刷盘策略来保证（同步刷盘不会丢消息，异步刷盘会丢失一点点消息）
操作系统突然 Crash：可以由刷盘策略来保证（同步刷盘不会丢消息，异步刷盘会丢失一点点消息）
Broker 突然断电：其实还是可以由刷盘策略来保证（同步刷盘不会丢消息，异步刷盘会丢失一点点消息）
Broker 的磁盘受损：这台机器连保存到磁盘都成为一个问题的话，那有没有可能设计成为拥有备份节点都分布式或者主备或者HA
Broker 无法开机或者启动：就更得需要有备份节点
Broker 正常关闭：其实这个不用态关心，因为是正常操作，所以不用担心消息的丢失
3 消费阶段
先消费数据，再提交成功状态。这里有一个细节点，需要消费者有一定的幂等性处理，因为消费者有可能会消费多条数据（举一个典型的例子：就是并发消费的时，如果 offset 小的那条消息消费失败了，那即使 offset 大的那些消费成功了，那最后提交 offset 位移的时候，还是会将那个 offset 最小的成功值提交到 Broker 侧。）
假设消费者进行了各种 Retry 到尝试，那还有最后一招，直接消费死信队列里面的数据。
消息回溯：
可以采用原来的消费者继续设置回溯的一些 API 来进行重新消费。
也可以采用新的消费者组来进行重新消费。
重新消费的 API：偏移量以某个偏移量开始消费（consumeFromWhere）、时间戳以某个时间戳来消费消息（consumeTimestamp）

参考资料 ： 参考资料