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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了电商系统中的下单功能的mysql架构设计，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2415字，纯文字阅读大概需要4分钟。

内容图文

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

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

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

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

这里有几个注意点：

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

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

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

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

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

内容总结

以上是互联网集市为您收集整理的电商系统中的下单功能的mysql架构设计全部内容，希望文章能够帮你解决电商系统中的下单功能的mysql架构设计所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端