| 问题分类 | 消息积压 |
|---|---|
| 相关描述 | 在使用MQ过程中由于种种原因导致消息消费不及时造成大量消息积压。 |
| 原 因 | 1. 消费流程卡死 |
| 2.消息消费耗时过长 | |
| 3.消费组客户端启动失败 | |
| 4.消费线程过少，消费能力不够。 | |
| 最佳实践 | 1.消费逻辑的业务处理尽量时间不要太长，如果存在长耗时逻辑尽量异步处理。 |
| 2.不要过多和外系统服务进行交互，避免其它服务问题导致消费能力下降。 | |
| 3.消费线程要对异常进行分类处理，不要发生异常轻易终止或者关闭消费节点的注册。 | |
| 4.消息积压后，通过shovel可以应急处理，防止消息丢失。。 |
| 问题分类 | 消息丢失 |
|---|---|
| 相关描述 | 在使用MQ过程中由于种种原因导致消息消费不及时造成大量消息积压。 |
| 原 因 | 1. mafka partition leader选举策略问题造成消息丢失。 |
| 2.数据可靠性级别未设置为ack=-1。 | |
| 3.在机器重启过程时，异步发送消息还没处理完客户端已经被销毁。 | |
| 4.消息过大造成发送失败 | |
| 5.消息发送失败没有及时关注发送结果。 | |
| 最佳实践 | 1.业务消费未执行成功不要返回消费成功。 |
| 2.程序退出先关闭Consumer和Producer。 | |
| 3.如果对消息丢失0容忍可设置客户端 ack=-1。 | |
| 4.不要发送超过1M以上消息 |
| 问题分类 | 重复消费 |
|---|---|
| 相关描述 | 在使用MQ过程中我们经常会遇到消息被重复消费问题，如果不能准确处理会导致线上问题。 |
| 原 因 | 1. 绝大部分消息中间件均不能保证消息只被消费一次。 |
| 2.生产者重复生产消息。 | |
| 最佳实践 | 1.消息消费需要严格幂等控制，实现幂等的方式有很多，有依赖分布式锁将并行改成串行的 |
| 2.也有依赖数据库的事务的、也有依赖与数据库记录的状态之间流转的状态机的； |
| 问题分类 | 消息发送失败 |
|---|---|
| 相关描述 | 在使用MQ过程中会遇到使用不规范或者系统故障导致消息发送失败。 |
| 原 因 | 1. 客户端是使用不规范，重复创建实例，造成大量系统资源消耗。 |
| 2.系统异常未能及时监控流量，没有限流、切流预案。 | |
| 3.未处理发送结果 | |
| 最佳实践 | 1.按照规范创建客户端，可采用Spring bean配置创建，保证一个消费组或生产者只有一个 |
| 2.实例对象。 | |
| 3.关注发送结果。 | |
| 4.构建有效的流量监控应急预案。 |