日千万级下单流程设计

注意点：

1. Redis宕机或者MQ宕机
   需要设计降级方案，当出现中间件宕机时，降级到订单中心下单，同时做好限流避免订单中心被打垮。

2. Redis从宕机中恢复后，数据丢失
   运维上如何去保证redis不崩溃或者数据不丢失不在讨论范围，我先按下不表。下面说下开发这里该做哪些措施：
   整个链路会以下两个阶段发送数据丢失
   1. 发起支付时，数据丢失。这是对于用户来说订单不存在，无法发起支付，在业务上无论是用户还是企业都未受到损失，可以无需理会
   2. 支付完成回调时，数据丢失。这个很严重的问题，因为用户已经付钱了。这是我需要考虑的。
   解决方案如下：
   1. redis双写。将下单请求双写，回调发现数据不存在时，可降级去另外一个redis集群读取。
   2. 退款。如果两个redis集群数据都丢失，支付流程无法继续，应该给用户发起退款，并记录退款信息方便用户查看和客服审核。
   3. 这里有种特殊的场景也得考虑，就是因为网络抖动，导致两次回调先后到达，第一次回调redis数据未丢，完成支付，订单同步到订单中。第二次回调redis数据已丢，发起退款。这里还涉及退款-订单拦截的流程。这里先按下不表

3. MQ消息丢失
   如何保证MQ消息不丢失，可参考我之前的文章
   使用RabbitMq做中间件时，生产者如何保证消息不丢失？
   最后，日志记录非常重要，就算有些异常没有在我考虑范围内出现，我依旧可以通过日志去人工恢复数据或者发起退款。