• 电商系统中的下单功能的架构设计思路
  • Kelly 发表于 2016/7/11 18:59:00 | 分类标签: 订单系统设计 电商系统设计 分布式
  • 声明:以下讨论基于MySQL,InnoDB引擎,不考虑主从

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

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

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

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

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

    这里有几个注意点:

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

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

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

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


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

    这里会持续更新中间件架构相关的文章,欢迎关注和吐槽。

  • 请您注意

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:Kelly
  • 加入时间:2013/6/13 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 以下内容也很赞哦
分享按钮