关于投递事务的疑惑，感觉难点在这里！请老师帮忙

Question

老师，您好！课程很好，但有几个细节新人提问：
1、关于transMessageService.messageSendReady(messageId),是在Ordercreate后创建，个人理解是否应该把创建订单、发送消息落库放在一个事务里面，毕竟重新投递都要以这个落地数据为依据，如果落库失败，将不会有任何重试机制。
2、异步ack的时候，判断条件为 if ( ack && null != correlationData) 然后执行messageSendSuccess(messageId),如果此时落库失败，那么messageid还会存在于数据库中，定时轮询就会判定为投递交换机失败，会从新投递，这里是否会造成重复投递？
3、定时轮询是将所有的数据进行重新投递，如果某一时刻，正好有个新消息进来，并在ack删除之前进行了一次定时轮询，是否会造成此条新消息重复投递，如何避免?
也可能我理解有问题，请老师帮忙解答。

Answer 1

Moody 2021-07-26 10:15:29

1确实加上事务更好

2确实有这个问题，所以后面再迭代的时候要考虑重复消息的识别问题

3实际可以给消息加个中间状态，比如“消息发送中”

• 提问者 慕沐4878363 #1

  moody老师好，
  1、业务数据落地、消息落地绑定在一个事务是一种思路，这样代码的侵入性会增强，我看rockeymq有业务数据落地和发送mq消息的事务绑定，其中有个after-commit，并不一定要消息落地，不知道rabbitmq是否有这种实现。
  2、消息的重复投递，个人以为在消费端进行消费识别，是否可以解决此类问题。
  3、加更多的中间状态，会加大数据库落地锁的消耗，mq解耦是一个方面，比如秒杀类场景，更多的还需要考虑性能问题，如何有更好的方案。
  新人请多关照。

• Moody 回复 提问者 慕沐4878363 #2

  不好意思，你在别人的问题里提问的，一直没有看到
  1 据我所知rabbitmq并没有这种原生的实现
  2 消费端识别是个好方法，但可能会付出一些代价，比如记录已经处理的消息ID，要权衡
  3 秒杀类场景还是不太推荐用rabbit，还是用redis比较合适