谈谈web系统中的可重入,幂等性,分布式事务的那些事 – 下

分布式事务

我们都熟悉mysql事务,它保证要么全做,要么全不做。但是对于一个大型系统来说,mysql一般会分库分表,多物理机部署,同时业务逻辑更加复杂漫长,同时需要调用很多服务(SOA)。

因此可以想象,在一个处理逻辑中,任何一个中间环节出现异常中断(请求超时,进程自杀等等不可控因素)都是很麻烦的。麻烦在于我们要知道上次中断在哪里以便重试的时候可以跳过之前的环节,这对编写函数流程的方式方法论就有一定的要求了。

我们知道,任何一个可靠的系统都应该符合”可重入”,”幂等性”,因此我们也相信我们依赖的其他服务也是遵循这些守则的,因此我们重试或者并发的访问其他服务都会得到正确且一致的应答。有了这个前提,我们才能讨论如何解决”分布式事务”问题。另外,这里提到的”分布式事务”是”柔性事务”,只能保证最终一致性,因为任何中间环节中断是无法避免的,并且通常不考虑中途回滚,需要事务完整做完再进入其他回滚流程。

继续以”付款环节”为例,当我们收到付款后,希望给用户生成消费码,然后给用户发送一条短信告知消费码,最终返回”接受付款”。为了简化,我们不考虑”拒绝付款”的场景,整个流程简化如下:

  1. 微信支付系统调用我们的接口,告知我们收到了order订单付款。
  2. 从mysql读取这个order,并且假设order的status总是”待付款”。
  3. 请求券码服务,为这个order分配1个消费码。
  4. 更新mysql将消费码存到order中。
  5. 请求短信服务,为这个order的用户发送这个消费码。
  6. 更新这个订单为”已付款”。
  7. 返回微信支付”接受付款”。

整个流程比较明确,我们完全可以顺序的把代码编出来,在各种环境都非常稳定的情况下,可以正常运行。但是程序复杂的永远是异常,下面我们分别考虑每个步骤失败会带来什么问题。

步骤3)券码服务超时,但其服务内部实际上已经生成了一个券码,按照博客之前的介绍,我们只能退出程序,稍后重试。问题是重试的时候,我们再次请求券码服务,会不会又多生成了1个券码呢?其实很好解决,券码服务的接口设计满足幂等性即可,例如:createCoupon(orderId),我们每次调用传入订单号,券码服务在mysql中维护orderId唯一索引,从而保证一个order只能生成一次券码。问题得到解决。

步骤4)更新mysql超时,分两种情况,虽然超时但已经写入到mysql和没有写入。在重试的时候,我们可能会想到,可以首先判断order中是否已经填写了消费码,如果有就不需要执行步骤3)和步骤4)了,否则依旧从步骤3开始执行。

步骤5)短信服务超时,其实和3)的场景一样,短信服务可以保证幂等性,从而不会因为异常导致重试的时候给用户多发1次短信。

步骤6)更新mysql超时,也分实际写入和没有写入mysql。在重试的时候,如果order的status是”已付款”,那么直接就应该跳转步骤7),否则仍旧应该从步骤5执行。

可见,我们依赖的服务都实现的不错,可以让我们放心使用,但我们实现自己的逻辑的时候,随处都可能失败,每一种失败都需要写对应的逻辑去重试和修复,乍一想还是很麻烦的,那么怎么简化这个问题呢?

回归问题本质,降低问题复杂度从2个方向入手。首先这一段逻辑是写在一个函数流程里的,先做1后做2…最后做7,我们仍旧想保持这么简单的代码。其次,我们期望的效果是即便做到6失败了,在重试的时候可以直接从6开始重做,而不是从1做到7。

根据上述思路,我们除了保持订单的status不变,新增一个sub_status字段用于记录”分布式事务”的中间状态,如果sub_status=5代表步骤5执行成功,且步骤6尚未执行或者上一次执行失败。这样,每完成一个步骤,我们将sub_status记录到mysql中,以便下次重试可以直接从中断的sub_status位置继续执行逻辑处理。

而整个代码将被简化成如下伪代码:

 

说在最后,上述都是一些基本的理念,仅具有指导意义。实际问题还是需要实际分析,记住这些思路,是为了在解决具体问题时能帮助梳理思绪,简化问题。

如果文章帮助您解决了工作难题,您可以帮我点击屏幕上的任意广告,或者赞助少量费用来支持我的持续创作,谢谢~