标签：消费 服务 处理 至少 failure 失败 消息 确保
对消息服务需要了解的朋友，可以移步：
本章讨论主题
- 如何确保消息至少消费一次，确保消费者最大程度消费成功
消费者消费消息有2中方式：
1. push方式
消息服务接收到消息之后，主动将消息推送给消费者消费
2. pull方式
消费者定时从消息服务中拉取消息进行消费
下面我们将讨论2中方式中如何确保消息至少被消费一次。
push模式
消费的过程：
- 消息服务查询待消费的消息列表
- 轮询待消息列表
- 调用消费者
- 消费者收到消费请求，执行业务处理，将处理结果返回给消息服务
- 消息服务接收到消费成功的信息，将消息状态置为消费成功状态
- 继续消费下一条消息
探讨一下上面需要考虑的问题：
若消息一直消费失败如何处理？
先说一下影响：
消息被阻塞
消息如果一直消费失败，消息服务会不断调用消费者进行消费，会阻塞其他消息的消费，直接影响到业务的正常进行.
消费失败的原因：
代码问题
这种情况不管尝试多少次，消息都会消费失败，需要人工介入修复bug，这个可以依靠监控系统发现bug，同时开发进行修复。
系统运行异常
如调用超时、网络问题等一些不可控的因素。产生这种错误，继续重试，最终会处理成功。
此处咱们只用讨论消息服务中重试机制如何设计？
系统异常情况下，可能过一段时间，系统恢复了，此时去重试，消费也就成功了。
所以我们对于消费失败的消息采用延迟处理的方式，可以这么实现：
消息中增加几个字段用于重试：next_dispose_time【下次处理时间】、max_failure【最大允许失败次数】、failure【当前失败次数】，消息入库时：next_dispose_time=需消费的时间，max_failure = 运行最大失败次数, failure=0;
当消费失败时，处理过程：
计算下次处理时间（next_dispose_time），可以在当前时间上面做指数递增，比如根据失败次数依次在当前时间上递增2的failure次方秒，如：
第1次失败：当前时间 + 2秒
第2次失败：当前时间 + 4秒
第3次失败：当前时间 + 8秒
第4次失败：当前时间 + 16秒
.......
第n次失败：当前时间 + 2的n次方秒
failure++
消息服务查询待消费的消息也需要做调整：
select * from 消息表 where next_dispose_time<=当前时间 and failure<max_failure and status = 待处理;
此时能够最大程度保证消息最少消费成功一次。
pull方式
这种会复杂一些，为何会复杂一些，咱们先看一下常规的流程：
- 消费者从消息服务中拉取消息
- 本地进行处理
- 从消息服务中删除此消息
- 继续拉取下一条进行处理
如果本地一直处理失败，那么后面拉取到的都是同一条消息，这条消息直接阻塞后续消息的消费，这种情况如何解？
咱们先分析一下出现这种问题的后果及原因：
- 后果：消息被阻塞，业务无法正常运行
- 原因：代码问题或其他异常
- 确保代码没问题，可以解决上面问题，及时性不够高，线上要考虑系统的容错能力。
遇到这种问题还是挺严重了，业务方都是无法接受的，一条消息消费失败，会影响到其他所有消息的消费，这个我们还是得想办法解决，可以这样：
- 消费者拉取消息
- 落地到本地
- 从消息服务中删除此消息
- 异步去消费本地落地的消息
消息先落地，然后异步处理，本地需要有个补偿的job，去处理本地消费失败的消息，这个可以参考push方式消费的过程。
标签：消费,服务,处理,至少,failure,失败,消息,确保 来源： https://www.cnblogs.com/itsoku123/p/10860509.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。