一个较为健壮的下单方案

一个较为健壮的下单方案

最近在做的一个新项目中,有一个下单兑换的流程。用户的积分可以用来兑换物品。

这个过程中,需要有几部分的操作:

  • 积分表扣除积分
  • 兑换表写用户兑换内容、状态
  • 下单
  • 更新用户兑换表为兑换完成状态

这个流程中需要保证扣除积分后,能够为成功为用户下单。一个服务的调用会出现三种状态:成功、失败、超时。超时的情况下,是无法确定下单是否真正成功的,这时要避免重试时重复下单。为了保证下单流程的健壮性,除了下单接口本身需要做好幂等之外,上层业务本身也需要记录下单过程中的状态流转,方便进行下单后的逻辑处理,兑换表中需要一个状态字段,可能存在的几种状态为:

  • 1:扣除积分,未下单
  • 2:扣除积分,已经下单
  • 3:扣除积分,完成订单
  • 4:下单失败,积分回退

通过数据库的事务,我们首先需要保证,下单出现非超时错误时,需要回滚下单之前的数据库操作:

「 事务

​        扣除积分

​        写兑换表,状态:1、扣除积分、已经下单

」---> 下单失败,回滚事务

下单成功自不用说,将兑换表中状态更新为3即可。当出现下单超时的时候,以上的事务就先不回滚了,通过消息队列来进行下单重试。消息队列的重试,也有可能再次出现超时的情况。队列的重试是有一定的时间间隔的,例如每隔/10/30/60秒重试一次。如果重试3次失败,应该有相应的告警出来,这时候一般是下游的订单服务不可用了。如果在重试下单时,出现了非超时错误,那么这时候应该给用户回退积分,并且将兑换表的状态更新为下单失败,金币回退。

重试下单失败-->积分回退

到这里其实已经可以较好地保证用户下单的健壮性的。但是还有一点,在成功下单后,需要更新用户的兑换表到状态3。这个时候有可能会抛出更新数据库表失败的异常,导致实际下单成功,但兑换表状态不一致的情况。解决的办法是当更新兑换表失败抛出异常时,捕获该异常,再利用消息队列发出更新数据库状态的消息,进行更新重试。整个流程如下所示:

(完)

posted @ 2019-03-23 16:29 melonstreet 阅读(...) 评论(...) 编辑 收藏