http://www.cnblogs.com/yukaizhao/archive/2012/04/23/taobao_order_design.html
周末参加了@淘宝技术嘉年华 主办的技术沙龙, 感觉收获颇丰,非常感谢淘宝人的分享。这里我把淘宝下单高并发解决方案的个人理解分享一下。我不是淘宝技术人员,本文只是写自己的理解,所以肯定是会有一些出入的。
在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方式,服务器稳定性;方案的可测试性,可量化等等。
上周六的技术还分享介绍了很多其他方面的精彩内容。感谢主办方,主持人! 期待@淘宝技术嘉年华 更多精彩的技术沙龙。
订单号介绍勘误:
文中对于订单号的表述有点问题,对于16台服务器,每台服务器64张表只需要2位买家或卖家id的后两位数字就可以准确定位到具体的库和表。订单号中同时存在买家id的最后两位和卖家id的最后两位。分别在订单号的倒数第3,4位数和最后两位数。
假定买家id为123456789,那么在订单号中的最后两位就是89,通过89对16取模就可以定位到具体的库上,通过对64取模就可以定位到具体的表上。
周末参加了@淘宝技术嘉年华 主办的技术沙龙, 感觉收获颇丰,非常感谢淘宝人的分享。这里我把淘宝下单高并发解决方案的个人理解分享一下。我不是淘宝技术人员,本文只是写自己的理解,所以肯定是会有一些出入的。
在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方式,服务器稳定性;方案的可测试性,可量化等等。
上周六的技术还分享介绍了很多其他方面的精彩内容。感谢主办方,主持人! 期待@淘宝技术嘉年华 更多精彩的技术沙龙。
订单号介绍勘误:
文中对于订单号的表述有点问题,对于16台服务器,每台服务器64张表只需要2位买家或卖家id的后两位数字就可以准确定位到具体的库和表。订单号中同时存在买家id的最后两位和卖家id的最后两位。分别在订单号的倒数第3,4位数和最后两位数。
假定买家id为123456789,那么在订单号中的最后两位就是89,通过89对16取模就可以定位到具体的库上,通过对64取模就可以定位到具体的表上。