消息驱动模式的两个疑问

Question

1. 创建订单的时候失败，票一直锁着。这时没有订单，定时任务也不起作用。 

2. 处理订单完成的时候，order服务挂了，这时是订单状态还是NEW,则定时任务起作用，将订单标记为超时，是否需要回滚之前的所有任务，比如用户额度恢复，取消先前移交的票等操作。
   

Answer 1

大漠风 2018-08-24 13:24:03

不好意思，回复晚了。
1. 定时任务没有起作用，是有什么错误吗？是定时任务没运行？任务里有没有触发相应的事件，然后该事件的处理？
2. 在超时任务里回滚未完成的任务时，应该回滚所有数据，实现数据的一致性。

• 提问者 zhusx #1

  可能我没表达清楚，
  第一个我想问的是，创建订单的时候报错，则订单表就不会有这条记录，导致定时器轮训不到这条记录，所以票一直锁着。
  第二个我想问的是，在订单完成的时候报错了，前面其实都是正常的，只是差改下订单状态而已，回滚的话，代价太大了。不过想了下，也没有什么好的办法。

• 大漠风 回复 提问者 zhusx #2

  首先说明一下，使用消息机制处理一个流程的分布式事务，就是要设计一个状态机，能够处理所有的正常、异常的流程。在课程的实例里面，由于时间关系，没有考虑所有的异常情况。
  第一个问题，创建订单的时候失败，也就是锁票完成，在订单服务里，把订单信息写到数据库的时候出错。因为已经做过业务条件验证、锁票，这种错误应该是order服务停了、或网络错误、DB错误。如果是写数据库失败，也就是order服务读消息后重试多次后一直失败，很多MQ都可以设置把这个消息发到某个队列，或者默认会被发到一个死信队列（DLQ）。对于这种情况，我们可以专门写一个处理方法针对这个死信进行订单异常的处理，也就是票的解锁。
  如果是服务退出，这个消息完全没有被消费，那么在服务启动以后，就会开始消费这个消息，这时候，我们可以通过在消息上加一个时间戳来标记消息创建时间，再通过一个超时时间来处理超时。由于在这个消息里面已经有了锁的票，就可以用来解锁。
  最后需要说明的是，我们使用分布式系统、微服务系统，目的是为了通过一个方便开发和维护的系统，实现复杂、高并发的业务需求。不要轻易为了一个异常情况，就让系统别的过于复杂。
  总之，订单还没有创建，就没法通过定时器来检查超时的订单，需要从其他方面来解决。

• 提问者 zhusx 回复 大漠风 #3

  了解，谢谢！