采用二阶段消费方式,需要将消息在StoreQueue和PrepareQueue之间移动,如何实现重试次数控制呢,其关键在StoreQueue和PrepareQueue的分数设计。
PrepareQueue的分数需要与时间相关,正常情况下,消费者不管消费失败还是消费成功,都会从PrepareQueue删除消息,当消费者系统发生异常或者宕机的时候,消息就无法从PrepareQueue中删除,我们也不知道消费者是否消费成功,为保障消息至少被消费一次,我们需要做到超时回滚,因此分数需要与消费时间相关。
当PrepareQueue中的消息发生超时的时候,将消息从PrepareQueue移动到StoreQueue。因此PrepareQueue的分数设计为:秒级时间戳*1000+重试次数。不同类型的消息首次存储到StoreQueue中的分数表示的含义不尽相同,区间重复合并消息和任意定时消息存储时的分数表示消费时间戳,优先级消息存储时的分数表示优先级。
如果消息消费失败,消息从PrepareQueue回滚到StoreQueue,所有类型的消息存储时的分数都表示剩余重试次数,剩余重试次数从16次不断降低最后为0,消息进入死信队列。以上内容摘自《阿里开发者手册-Redis专题》电子书,点击https://developer.aliyun.com/ebook/download/7770 可下载完整版
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。