盘点RocketMQ

消费失败

消费失败会返回RECONSUME_LATER状态，标识消息未成功消费，过会再重新消费。这时会把消息放到另一个topic（schedule_topic_xxx延迟队列中）中，让它等着再次被消费。

失败重试

消息失败会重试，默认会16次。如果16次还是失败的话会认为彻底失败，不会在进行重试。这是失败的消息会放入到死信队列中（DLQ_原队列）。如果想要继续重试，也可以开启后台线程不断扫描死信队列后继续重试
重试队列（retry开头的队列）会保存因各种异常导致消费端未能成功消费消息的mq，重试队列是针对消费组的。后台会有个定时任务按照对应的时间进行延迟保存在retry_consumerGroup的重试队列中。

延迟消息

消息延迟有18个级别，从1开始到18，每个级别对应的延迟时间间隔
1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

1、 如果设置的延迟级别大于0，则代表为延迟消息，放入延迟队列（schedule_topic_xxx），队列的ID为延迟级别-1
2、mq的服务端会针对每一个延迟级别设置一个定时器，每隔一秒会拉取对应级别的延迟队列。
3、定时任务会根据上次的偏移量offset不断的从队列中拉取消息，根据消息的偏移量和大小会从commitLog中解析对应的消息，再次获取消息。
5、从消息tagsCode中解析出消息应当被投递的时间，与当前时间做比较，判断是否应该进行投递。
6、若到达了投递时间，则构建一个新的消息，根据消息的属性重新创建消息，消除消息延迟，恢复消息主题topic和队列ID quenueId，重新发送到原主题的队列中，重新进行消息投递，供消费者进行消费

tag过滤

使用tag过滤消息，在broker和consumer中都会过滤消息
在broker过滤：从commitLog中读取过滤后的消息返回给消费者，在消费端的过滤只是为了消除因哈希冲突误读的多余数据，相当于二次保障过滤。
consumer过滤：收到消息会调用DefaultMQPushConsumerImplthis.pullAPIWrapper的processPullResult方法进行tag过滤,用户监听消息就只会收到关注的tag

消费积压

出现消息积压我一般遇到下面几种情况
1、硬件问题；
2、代码写的有问题；
代码逻辑过于复杂，链条过长，里面又大事务
里面可能会有慢查询，发生死锁
批量的数据单条处理也可能变慢，单条数据处理可能需要几十到几百毫秒，这样看是没有问题，如果这时需要消费一百条数据，需要的时间就是*100 ，这么算下来就是几秒到几十秒，花费的时间就过长了，导致后面消息一直未能消费，就会积压
还有可能就是系统抛出异常导致消费重试，一条消息最多可以重试16次，这样就导致消息量级发大导致消费失败
3、消息本身量就大；销售订单的消息一天几百万上千万，而我们可能不需要全量的消息，在生产消息时对消息使用tag进行分类，我们消费时用tag过滤只有我们需要的消息，这样也可以减少消息积压的发生。