注意点:
-
Redis宕机或者MQ宕机 需要设计降级方案,当出现中间件宕机时,降级到订单中心下单,同时做好限流避免订单中心被打垮。 -
Redis从宕机中恢复后,数据丢失 运维上如何去保证redis不崩溃或者数据不丢失不在讨论范围,我先按下不表。下面说下开发这里该做哪些措施: 整个链路会以下两个阶段发送数据丢失 1. 发起支付时,数据丢失。这是对于用户来说订单不存在,无法发起支付,在业务上无论是用户还是企业都未受到损失,可以无需理会 2. 支付完成回调时,数据丢失。这个很严重的问题,因为用户已经付钱了。这是我需要考虑的。 解决方案如下: 1. redis双写。将下单请求双写,回调发现数据不存在时,可降级去另外一个redis集群读取。 2. 退款。如果两个redis集群数据都丢失,支付流程无法继续,应该给用户发起退款,并记录退款信息方便用户查看和客服审核。 3. 这里有种特殊的场景也得考虑,就是因为网络抖动,导致两次回调先后到达,第一次回调redis数据未丢,完成支付,订单同步到订单中。第二次回调redis数据已丢,发起退款。这里还涉及退款-订单拦截的流程。这里先按下不表 -
MQ消息丢失 如何保证MQ消息不丢失,可参考我之前的文章 使用RabbitMq做中间件时,生产者如何保证消息不丢失? 最后,日志记录非常重要,就算有些异常没有在我考虑范围内出现,我依旧可以通过日志去人工恢复数据或者发起退款。
|