总结几个RocketMQ的最佳实践问题

如何保证消息不丢失？

1. 跨网络过程及异步刷盘等都有可能造成消息丢失
2. 可利用消息事务机制保证消息0丢失，过程也较复杂
3. 配置同步刷盘+Dleger主从架构保证消息0丢失
4. 消费者不要使用异步线程机制对消息进行消费
5. NameServer挂了不影响消息路由功能，但所有NameServer都挂掉时，生产者与消费者也无法工作
6. 综上所述，一般大型互联网企业还会准备降级方案保证消息0丢失
7. 比如mq不可用时，则找其他地方先将消息缓存（如Redis、文件或者数据库等）起来，启一个线程定时扫描失败的消息，尝试发送
8. 这样，等mq恢复后，将会重新推送这些消息

如何保证消息消费顺序？

1. 全局有序，即为严格按照消息先进先出顺序进行消费
2. 局部有序，只保证一部分关键消息的消息顺序
3. 大部分场景下，我们只保证局部有序即可
4. 局部有序，只需在发送者发送一组消息时，通过MessageSelector对象决定下搜西发入哪一个Queue中即可
5. 而全局有序，其实也就是将消息压缩成局部有序的问题
6. 让Topic中只有一个MessageQueue，即可保证全局有序（默认为4个）
7. 全局有序对消息吞吐量影响较大，基本不建议使用

如何解决积压消息？

1. 利用web控制台或命令来确定消息极大情况
2. 首先考虑增加消费者实例
3. 但对于Queue数量不多的情况下，要增加太多Consumer也没有啥用
4. 此时，可考虑创建一个新Topic，配置足够多Queue，紧急上线一组新消费者，只负责旧Topic消息消费
5. 消费旧的消息到新Topic中，这个速度会很快
6. 如此一来即可快速消费积压消息
7. 这种方式还可用于主从架构换Dledger高可用集群架构场景，不想历史消息丢失，也可考虑如上方式

如何跟踪消息轨迹？

1. 默认提供了消息轨迹功能
2. 通过traceTopicEnable=true参数开启
3. 可跟踪：
   • 生产实例信息发送时间，是否发送成功，耗时
   • 消费实例、投递时间及轮次、是否消费成功、消费耗时、
   • 以及Borkder相关的Topic、存储位置、key、Tag等信息
4. 支持客户端自定义轨迹数据存储的Topic
5. 可通过客户端提供的API，再构造函数中配置消息轨迹存储到用户指定的Topic中