关于消息驱动模式中支付过程这一节的问题

Question

老师您好，在这一节中，有个疑问，就是如果在支付过程中，支付成功后，如果发送解锁票的消息失败，则要将失败的消息写入一个队列中，在代码演示中，然后建立相关的表payInfo来判断是否是重发，这里使用了最大努力一次提交这种方式，但是如果使用JTA这种事务管理方式，是不是就不需要建立表来判断了？因为可以让MQ和DB的数据都回滚。还有如果在这里解锁票的消息发送失败，那监听这个解锁票的队列再如何获取消息呢？此时用户账户的钱已经扣款成功，需要人工介入么？

Answer 1

大漠风 2018-10-23 23:32:37

在一个多个步骤的分布式事务当中，也就是先下单，再支付，再减库存、发货等，在这种情况下，对于一个请求，我们需要判断它是不是正常请求、异常请求、重复请求。所以像支付的时候，通过payInfo表来判断是否支付过。在重复请求中会存在处理过的记录，就是因为最大努力一次提交，如果使用JTA，只要失败了，就不会写进去任何数据，就不会存在处理过的记录了。

然后，在数据的回滚过程中，我们需要保证所有的已处理数据都被回滚，包括锁票、扣费等数据。但是这个回滚是否要用程序自动执行，也要看具体的业务流程和设计。只要这个回滚的过程不会导致系统设计和代码过于复杂，就使用程序回滚。上面也说了，我们需要判断它是不是正常请求、异常请求、重复请求等等，业务流程多一步、条件分支多一个，往往就会成倍的增加代码复杂度，所以，我们需要权衡。当然对于出错时的回滚，也要做好相应的出错信息的记录。

• 提问者 达闻西funnyx #1

  谢谢老师的回答，还有两个问题需要老师解答一下
  1.在演示系统中，如果某一个模块中业务流程都执行完成，但是在发送消息的时候失败（比如扣费操作中，扣费完成，但是消息发送失败），下一个流程操作处理无法监听到该消息，这种情况该如何处理呢？
  2.在演示系统中，用户发起请求，在第一步操作中，先锁票，那如果现在锁票成功，但是消息发送失败，在后面的下单操作中，无法监听到该消息，那么订单也就无法生成，但是票还是被这个用户锁定着，对于这种情况，系统是否需要一个定时任务去执行没有下单的用户但是在锁票中的这种情况呢？

• 大漠风 回复 提问者 达闻西funnyx #2

  确实，在这种多个步骤的事务当中，我们得想办法判断你说的这种错误。特别是像已经锁票，但是为创建订单，这时候，我就需要一种办法能够判断超时。所以，一般的做法还是先创建订单，然后再做一个一个的步骤，根据订单的时间来判断超时。在我们的演示程序里，也是简化了一下这个步骤，先做锁票。还有你说的第一种情况，扣费失败也是，可以根据订单的时间来通过定时任务判断超时。在我们演示的程序里，也是通过定时任务来检测超时的订单的。

• 提问者 达闻西funnyx #3

  非常感谢！