订单系统设计

我们每天都在使用下单。但是订单是如何生成的呢，又是如何推送到下游的各个系统的？

最重要的保证：

订单系统的低延迟，高可用的，不丢单问题。

万级和千万级架构是不一样的。

思路：
首先，设计一个简单的订单系统。
分析哪几个环节会丢单。
日万级如何优化。
日千万如何升级改造。

简单系统：

只有前台和后台，前台结算页提供用户去结算。当后台收到前台用户点击去结算的操作时，就会处理下单服务。

起初，订单会被处理到后台的数据库中，然后异构数据到缓存中。以此提供用户在我的订单中进行订单查询。
当用户支付完成后，收银台发送消息给下单的服务，进行数据库和缓存中的订单状态的修改。这样一个简单的订单系统就完成了。

真实的订单系统会有更多的业务，使得系统更加复杂。前面只是一个示例。

接下来，我们再看看这个系统中，哪些环节可能会出现丢单的问题。其实现在后台系统研发架构已经很成熟了。但是如果系统挂了，就是挂了。

所以关键点应该聚焦在写数据库，和接收和发送订单消息的环节上。

总结为3步：

1.

关键逻辑不要使用读写分离的查询方式，避免从库同步延迟造成订单查询异常。
比如

创建订单后，要创建支付单，但是在反查订单的时候由于主从延迟，没查到订单信息，这就可能会造成创建支付单的失败。

2

关键逻辑也不要使用缓存来进行订单的查询

这样做,同时是为了避免因为缓存延迟造成订单反查失败。

三

订单补偿不要粗暴的使用消息队列的方式࿰