接口异步调用导致的一个低概率问题引发的思考。

Posted 2021-02-15 在天成象

最近5个月接触到的异步调用占工作以来接触到的一半以上，这些异步调用都是消费消息的方式。

应用A在处理完业务后，需要调用应用B的接口做信息同步（记录数据或者更新数据），有两种方式：

一般情况是采用同步方式，等待应用B的接口处理完后，拿到返回值，继续后续处理。这样的好处是可以根据应用B的接口返回值来做接下来的数据处理：如果B失败了，可以数据回滚；或者使用应用B的接口返回数据继续业务处理。

还有一种比较少的方式是异步：有发消息的，也有往系统插入一条定时任务数据的。这种方式的好处时不用等待调用方处理，节省响应时间。缺点是，不知道调用方处理结果，如果调用方不通过发邮件，或者反调原系统接口，这次调用方处理结果都可能不被感知。

我这次遇到的问题其实不是异步调用失败，专门测试功能是会发现异步调用失败的。我这次遇到的问题是消息在消息队列排队太久了：运营角色在订单端处理订单后，将消息发出来，进入了消息队列，结果15秒后运营角色处理第二个订单时，这个消息还在消息队列，没有被活动端处理，而第二个订单就因为这个原因失败。 消息不是同步，所以生产者和消费者之间数据会有时间差。一般测试环境因为请求不频繁消息中心几乎没压力，所以异步看起来像同步，而这次是运气好，发现了这个问题。也因此发现了系统其实还存在可以完善的地方，数据时间差可能导致的问题没有做邮件通知，异步任务失败（上线后基本不会存在）后没有邮件通知。

我遇到的这个问题，如果用异步，是解决不了问题的，只能通过代码改进，来减少问题发生的概率；改用同步才能解决这个问题，然而同步存在响应时间长的问题。我们唯一能做的就是，在异常情况发生时，第一时间邮件通知大家，不要等到几天后才被用户发现。