首页 / 更多教程 / 淘宝下单高并发解决方案
淘宝下单高并发解决方案
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了淘宝下单高并发解决方案,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1664字,纯文字阅读大概需要3分钟。
内容图文
这里我把淘宝下单高并发解决方案的个人理解分享一下。我不是淘宝技术人员,本文只是写自己的理解,所以肯定是会有一些出入的。
在session中牧劳为我们介绍了淘宝下单部分的技术方案变迁,我不介绍变迁,而只对现有系统做介绍。
要优化下单,提高下单的TPS (Transaction per second),我们首先要做的是对下单的逻辑剥离,只保留核心部分,而把附加功能剔除出去。比如说下单要考虑库存量,考虑发短信,要给卖家发旺旺消息通 知,要对订单做统计,要做销售额统计等等,这些功能是必要的,但是也是附加的功能,要最大程度提高下单这一步的TPS,就要先不考虑这些东西。
下单必然会涉及到买家查看订单,和卖家查看收到的订单,修改订单价格等,这是下单的核心。 在下单这个操作中有买家和卖家两个密切关联而有不同的视角。牧劳称为两个不同的维度。据牧劳的介绍下单这一步只有5张表,这5张表涵盖了这两个维度的操作。
下单是在一个数据库事务中进行的,要提高数据库的事务并发数,最有效的办法是拆分,拆分有两种,一是对库进行拆分,另一种是在同 一个库中对表进行拆分。要做拆分首先就要考虑拆分依据的字段,淘宝是根据订单号做拆分的,而下单中有两个维度,买家和卖家,对订单做拆分之后,必须还是可 以通过买家,卖家方便的查询着两个维度的数据。该怎么办呢?这里留个疑问,我先介绍淘宝拆分的规模,淘宝将订单表拆分到16个mysql库中,而在每个库 中又将订单表横向拆分为64份,相当于将一个表拆分为1024份。拆分之后事务会分散到1024套表中,这必然会很大程序上增加并发的事务处理能力(这儿 我说是必然,但是淘宝在使用这种方案之前是要经过压力测试,实际测试出这种方案的TPS之后,才会逐步采用这种方案的)。上面留了一个疑问,经过拆分之后 如何保证买家卖家快速的查询其下的订单呢?最好的办法是保证买家,卖家下的订单在一张表中,如何保证呢?淘宝的做法是将买家的id取模后放到订单号中。假 定一个订单号是142424594267664;这个订单号对应的订单该放在哪台服务器上的哪个表中,是根据订单的后四位7667,对1024取模之后决 定的;同时7667是买家id的后四位。这样买家在查询其订单时就可以通过其id获得其订单所在库以及表,就可以方便有效的查询买家订单了。这里会带来另 外一个问题,卖家查询订单时怎么办?前面我们已经提到卖家和买家被分成两个不同的维度来做表设计,卖家查询时不是直接查订单表,而是通过卖家维度的表来做 查询。卖家维度的表的插入,更新是通过在订单插入时发一个消息来通知插入的。同样对于发短信、发旺旺也是通过消息来处理的,这些附加功能不参与到下单的事 务中去。
即使这样做了库,表的拆分,依然会有问题。淘宝在双11时的一天的交易量就达到了5000多万,这样几个月过去后,这些拆分后的 表中的数据量也会达到很大的一个量,处理速度就会下降。淘宝的做法是把三个月之前的老数据迁移到其他库中,这样就避免了数据量增大导致的系统响应时间降低 的问题。但是会带来另外一个问题,用户在查询订单时需要同时查两个库,一个是历史数据表,另一个是近期数据表;这个问题无可避免,就是通过查询两次解决。
也许有的朋友会想到拆分之后对全数据做统计会有问题。如果在拆分后的表上做统计,是肯定会有问题的。怎么做呢?其实很简单,把数据迁移到别的库中去做统计。
表做拆分可以大大的提高TPS,但是也会带来一些问题,需要通过可靠的消息通知机制通知其他模块做非核心处理的事情,需要通过高效的搜索系统保证搜索数据的及时更新。
以上是我个人对淘宝下单高并发设计的理解。这是肤浅的,实际做的时候肯定还需要考虑更多的问题,比如数据库的调优,磁盘IO方式,服务器稳定性;方案的可测试性,可量化等等。
出处:http://www.iteye.com/topic/1123010
原文:http://www.cnblogs.com/wuxl360/p/5455106.html
内容总结
以上是互联网集市为您收集整理的淘宝下单高并发解决方案全部内容,希望文章能够帮你解决淘宝下单高并发解决方案所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。