如何保证消息不丢失
丢失的时间节点：存在网络的地方

一：消息丢失问题

image.png

可能丢的环节：

1，2，4 网络的丢失问题
3：写入系统缓存，异步刷盘有个时间差也会

生产者：

事务消息
可以使用事务消息类型保证在生产者发送消息时的丢失问题
image.png

消息存储转发中间环节

  1. 同步刷盘，
    把刷盘方式flushDiskType配置成同步刷盘，保证消息不丢
  2. Dledger同步
    两段提交的方式保证
    一：uncommited
    二：commited
    类似zk， 半数broker ack才认为是ack
    image.png

消费端

可以使用本地事务，确定消费逻辑执行完才ack

nameServer挂了消息不丢失

如果全部nameServer都挂了，
那就只能只用本地缓存的路由副本
但是还是会不能正常工作
考虑消费降级，把消息存下来，redis ,文件，或内存

零丢失方案：

  • 生产者使用事务消息机制。
  • Broker配置同步刷盘+Dledger主从架构
  • 消费者不要使用异步消费。
  • 整个MQ挂了之后准备降级方案

实际考虑性能，吞吐量，安全，
采用定时对账，补偿机制，异步消息等

二：消息顺序问题

  1. 全局有序
  2. 局部有序

对于局部有序，可以把一个局部有序的消息集合发到同一个MessageQueue
或者只配置一个MesssageQueue,默认是4个，这样会影响吞吐量

三：消息积压问题

消费者故障可能导致的问题；
控制台查询消息积压情况：
差值：
可以通过mqadmin后台检查各个Topic的消息延迟
也可以在config目录下落地的json文件image.png
如何处理
每个consumer可以分配多个MessageQueue, 极限就是一个consumer配置一个MessaeQUeueu
也可以把积压的消息转存到一个新的Topic

从集群模式切换至Dledger模式也存在积压消息的问题

四：消息轨迹

消息的关键属性：

Producer端 Consumer端 Broker端
生产实例信息 消费实例信息 消息的Topic
发送消息时间 投递时间,投递轮次 消息存储位置
消息是否发送成功 消息是否消费成功 消息的Key值
发送耗时 消费耗时 消息的Tag值

打开消息轨迹功能的配置

broker.conf文件中 默认是关闭的 traceTopicEnable=true

轨迹数据存在一个系统的中，RMQ_SYS_TRACE_TOPICimage.png

也可以客户端自定义消息轨迹
核心类：
DefaultMQProducer
DefaultMQPushConsumer
构造的参数打开消息轨迹的存储

  • enableMsgTrace：是否打开消息轨迹。默认是false。
  • customizedTraceTopic：配置将消息轨迹数据存储到用户指定的Topic 。