目录

1、消息丢失

1.1 发生的场景

1.2 可能导致的问题

1.3 解决思路

2、重复消费

2.1 发生的场景

2.2 可能导致的问题

2.3 解决思路

3、消息堆积

3.1 发生的场景

3.2 可能导致的问题

3.3 解决思路

---

消息中间件提供了异步通信、缓冲和解耦等特性，由于使系统解耦，也提高了系统的可扩展性。但是也需要考虑由此可能带来的一些问题。

 

1、消息丢失

1.1 发生的场景

topic特性使得不在线的消费者上线后收不到之前的消息了，如果一段时间消费者都不在线，那消息就始终处于未被处理的状态。

服务器异常重启，导致内存中的数据丢失

消息设置了失效时间，过了时间就进入死信队列了

消费者自动回复ack，但是ack之后处理消息的过程中出现故障或异常，导致消息被消费者接收单未处理

 

1.2 可能导致的问题

消息丢失，导致的问题就是数据丢失，具体要看是什么业务场景的数据

 

1.3 解决思路

可追溯消息，默认topic数据是不进行持久化的，可以设置可追溯策略，最近多少条、最近多长时间、最近多少字节。

持久化消息

幂等化业务操作，使得消息丢失后可以重试，但不影响结果

做高可用，保证消息不因节点故障或网络故障丢失

死信队列，对死信队列的数据进行重新推送或重新消费

ack，消息被消费处理完成后再回复broker可以去清除该消息了

消息重投、重试机制

记录日志，将处理异常的或者可能丢失的筛选出来重新处理

2、重复消费

2.1 发生的场景

网络环境差等因素导致重复发送多条相同业务的消息、自动重试等。

2.2 可能导致的问题

导致业务数据错乱。

2.3 解决思路

设计幂等，使得消息重试多少次得到的结果都是一样的。

3、消息堆积

 

3.1 发生的场景

分组或者独占消费者（exclusive和selector），即设定消息只能有特定的消费者接收消费，或者消费者设定了只接收特定属性值的消息。

消费者的消费能力远小于生产者的生产能力（也许是存在短时间消息生产高峰或者消费者节点出现故障）

 

3.2 可能导致的问题

内存占用越来越多，内存可能溢出；

如果设置了消息持久化，磁盘空间占用越来越大；

主要还是影响业务响应时间；

内存溢出或者磁盘占满还可能导致消息丢失。

3.3 解决思路

对应场景和原因提出解决思路。

分组或独占消费者：定期检查发现追踪。

消费者能力不足：增加节点，多线程提升消费效率，优化IO模型与IO传递速度。

broker容量有限：增加容量，JVM参数配置，是否有不自动清除的垃圾数据、死信未处理、做高可用集群。

生产者短时间产生大量消息：检查产生的数据是否正常、程序是否有问题；事前做好压测和测试，预留处理能力。