架构16 社交软件红包技术09

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等

 

b. 对账补送解决不少发的问题：

发货失败是不可避免的，诸如网络波动/游戏方发货接口故障之类的问题都可能导致调用发货接口失败。在同步领取环境下，用户可以通过重试在一定程度上解决这个问题。但是对于异步发货，用户点击领取后发货请求由{4.1 AMS 外网发货新 OP}放入 MQ 中就算成功了，即使后台调用游戏的实际发货接口失败了没有实际到账，用户对此也无感知不能进行重试但是会投诉，后台发货系统必须通过自身的容错保证即使游戏方的发货接口不稳定偶尔会失败，用户所领的礼包能最终到。这里我们使用了对账补送方案。

对账：用户领取礼包调用的接口{4.1 AMS 外网发货新 OP}成功写应发流水，{4.3 AMS 内网发货 OP}调用游戏方发货接口的写实发流水，由于部分消息会堆积在消息队列中，这部分称为队列堆积流水。故实际要进行补发操作的流水由以下公式可得：
失败补发流水= 应发流水 - 实发流水 - 队列堆积流水。

由于订单号的存在，可以保证同一个发货请求重复发送也不会多发，对队列中堆积的消息提前进行补发操作也不会导致多发。故当队列中堆积的流水较少的时候，采用应发流水与实发流水的差集作为失败补发流水是合理，只是每个对账周期会对队列中堆积的消息进行两次发货操作，对性能略有损耗。

后台每个小时运行一次增量对账功能，检测 MQ 消息堆积量量低于某个阈值，则进行对账操作，截取上次对账到此时的应发流水/实发流水，两者相减得到补发流水。

补送：对对账操作得到的补发流水调用游戏方发货接口进行发货补送操作。