订单业务的基本模型设计用户、商品(库存)、订单、付款

简单订单业务的基本模型是为用户、商品（股票）、订单和支付设计的。这里只考虑商品和订单。该过程是下订单 -> 减少库存。这两个步骤必须同时完成。减少库存（超卖），或减少库存但不生成订单（减少销售）。超卖商家库存不足，消费者下单买不到东西，体验不好；低价商家库存积压或需要反复修改商品信息，麻烦且体验不好。

系统前期，要承担的流量小，很多创业团队都是单库模式（是的，大家一起...）。这种模式带来了极大的便利。它不需要跨数据库或跨节点。它可以方便地利用数据库提供的事务来实现下单、减库存的原子操作，还可以进行各种连接表和子查询（操作）。 MM又要变态了，我用SQL就能搞定）。但正是这些优势，将成为流量上来后系统扩展的绊脚石。联接表、子查询、事务都是将多张表绑定在一起，拆库拆表很麻烦。

后期系统流量逐渐增加，单个数据库的读写性能不够。这时候，数据库会被认为是被拆分，分成表。例如，产品和订单分为两个集群，集群根据各自的业务维度分为数据库和表。产品可以按照卖家维度划分，订单一般按照买家维度划分，按照卖家维度做冗余。这时候出现的问题还是一个经典的问题——数据一致性。数据拆分后，商品和订单不在同一个库，如何保证一致性；如何保证买家维度的订单数据和卖家维度的订单数据的一致性。有两种解决方案：

(1)分布式事务，经典的实现是基于2PC的。优点是封装得足够好（主要是复杂的查询语句）后区别于单个库，但一般来说不是适合业务 变化不会很大 缺点就是性能太差通常是不可接受的。..

(2)消息中间件，本文的主角，消息中间件的一大功能就是负责各个系统之间的通信，非常适合这里的商品和订单系统的同步。之后消息中间件的介绍下单流程为：用户A下单后向消息中间件发送消息，商品系统订阅该订单消息并扣除相应的库存。

这里有一些注意事项：

一个。传递消息需要时间。下订单前检查库存。但是，在并发条件下，实际减少库存时，库存可能不够。因此，只有在扣货成功电商系统 高并发库存系统设计，即下单后，才能显示订单。标记下订单后，但用户看不到状态，等待商品系统成功减库存，然后通知订单系统更新状态（还是使用消息中间件）；

b.消息的可靠性非常高。当消息成功回传时，需要确保消息能够送达。如果发送失败，订单业务需要回滚；

c。消息的高可靠性意味着会有重复的消息。在这里，商品系统需要自己做幂等性。可以用message id做去重，不然卖的少；

d。如果订单成功与否，前端用户希望尽快得到通知。因此，下单成功后需要设置定时消息。如果订单库存在一段时间后仍未成功扣减电商系统 高并发库存系统设计，则应通知用户订单失败。并定期补足这部分多余的库存。

引入消息中间件可以解决分布式数据库中的数据同步问题，避免分布式事务。并且额外的好处是减少库存时的并发锁争用减少了，并且性能得到了利用。