延迟消息，进行二次确认，回调检查的相关问题

Question

如下图，讨论的场景基于方案二

第一个问题，Step 4 完成后，是不是也需要在发送一个延迟确认消息(参考Step 2)，来保障消息可靠到达。还是单独依赖 ConfirmListener 和 ReturnListener 来重试，超过重试次数，怎样处理，是向 MSG DB 插入失败消息记录还是其他。

第二个问题，Step 2 发送的延迟确认消息假如在经历最大重试次数后，任然没有发送成功，是不是应该向 MSG DB 中插入一条失败的消息记录，还是做其他处理。

Answer 1

ImoocZhang 2018-08-31 17:42:45

2次投递就是利用延长插件去做的，可以中间'设置一个短暂的时间间隔，当然如果有必要也要做confirm，只不过不存储和更新消息记录表了，少了一次持久化，提升性能，做一个优化。

• 提问者 qq_哈之仆_0 #1

  谢谢老哥，其实问题总结下来就下面3点
  1. 二次投递失败的处理
  2. 消费成功向 CallBackService 发送的消息是否也需要做二次投递进行保障
  3. 这种方案下，失败的消息肯定也是需要入库的，不然怎样做人工手动补偿

• 阿神 回复 提问者 qq_哈之仆_0 #2

  问题1： 2次投递还失败就人工补偿了，第二次投递本身就是个补偿处理
  问题2： CallBackService是RPC调用 自己有内部的重试或者补偿机制 （比如dubbo、thrift 内部都可以retry）
  问题3： 人工补偿是要进行跟踪日志的traceID 肯定会有分布式链路跟踪或者CAT报警 OCTO监控

• ImoocZhang 回复 提问者 qq_哈之仆_0 #3

  3问题发生的概率非常小， 如果有，那就是订单级别的链路问题 会反应到整体核心trace上 这样我们通过链路跟踪即可解决 查找traceID 解决即可

点开查看后面3条评论

Answer 2

提问者 qq_哈之仆_0 2018-08-31 19:10:27

第一个问题: 消息发送的操作进行封装，每次调用Api，底层做延迟消息二次发送处理。

第二个问题: 延迟消息超过重试次数大概率是业务链路出现了问题，进行链路追踪，手动补偿。日记记录，数据库不记录失败的消息

• 阿神 #1

  已解决