当前位置:Gxlcms > mysql > 电商系统中的下单功能的mysql架构设计

电商系统中的下单功能的mysql架构设计

时间:2021-07-01 10:21:17 帮助过:39人阅读

简单的订单业务的基本模型设计用户、商品(库存)、订单、付款,这里只考虑商品和订单,流程是下订单 -> 减库存,这两步必须同时完成,不能下了订单不减库存(超卖),或者减了库存没有生成订单(少卖)。超卖商家库存不足,消费者下了单买不到东西,体验不好;少卖商家库存积压或者需要反复修改商品信息,反复麻烦,体验也不好。

在系统初期,承接流量小,很多创业团队都是单库的模型(是的,大家都在一起。。。)。这种模型带来了极大的方便,不用跨库,更没有跨节点,能够方便的利用数据库提供的事务来实现下单和减库存的原子操作,还能进行各种联表和子查询(运营MM需求再变态,我会SQL能奈我何)。但也正是这些优点,会成为流量上来后对系统进行扩展的绊脚石。联表、子查询、事务都是将多张表绑定在了一起,拆库、拆表就麻烦了。

后期系统流量逐渐升高,单库的读写性能不够,这时候会考虑将数据库进行拆库、分表。比如商品和订单分为两个集群,集群内又根据各自业务维度进行分库和分表,商品可以根据卖家维度来切分,订单一般根据买家维度切分,并且根据卖家维度做冗余。这个时候出现的问题,还是经典问题——数据一致性,数据拆分后商品和订单不在一个库里,怎么保证一致性;买家维度的订单数据怎么和卖家维度的订单数据保证一致性。有两个解决思路:

(1)分布式事务,经典的有基于2PC的实现。优点是封装得足够好后使用起来和单库虽然有区别(主要是复杂查询语句),但总体来说对业务的改动不会很大。缺点是性能太差,本来引入分布式数据库主要是为了成倍的提高性能,但因为分布式事务的引入将这个性能的提升大打折扣,很多时候这个性能是难以接受的。

(2)消息中间件,本文主角,消息中间件的一大职能就是负责各个系统间的交流,非常适合这里的商品和订单系统的同步问题。引入消息中间件后的下单流程是:用户A下订单后给消息中间件发送消息,商品系统订阅订单消息,并扣除相应的库存。

这里有几个注意点:

a、消息的传递是需要时间的,下单前查看有库存,但在并发条件下,实际减库存时可能库存不够,所以必须在库存扣减成功后才能显示订单成功,即下单后标记已下单,但用户对该状态不可见,等待商品系统减库存成功后,再通知订单系统更新状态(仍然是消息中间件的运用哦);

b、对消息的可靠性要求很高,发送消息时返回成功就要保证该消息会被投递,发送失败需要下单业务自己做回滚;

c、消息的可靠性高表示一定会有消息重复,这里需要商品系统自己做幂等,可以通过消息id来做去重,否则会少卖;

d、下单成功失败前端用户都希望尽早得到通知,所以在下单成功后需要设定一个定时消息,在一段时间后如果订单库存还没有扣除成功,这个时候应该通知用户下单失败,并且定期回补这部分多扣的库存。

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

人气教程排行