淘宝下单部分高并发设计 的个人理解(转)

    要优化下单就要提高TPS （Transaction per second）每秒下单数，我们首先要做的是对下单的逻辑剥离，只保留核心部分，而把附加功能剔除出去。

    比如说下单要考虑库存量，考虑发短信，要给卖家发旺旺消息通知，要对订单做统计，要做销售额统计等等，这些功能是必要的，但是也是附加的功能，要最大程度提高下单这一步的TPS，就要先不考虑这些东西。

    下单的核心是买家查看订单，和卖家查看收到的订单，修改订单价格等。在下单这个操作中有买家和卖家两个密切关联而有不同的视角。可以称为两个不同的维度。

 

    整个下单流程是在数据库事务中心进行的，要提高数据库的事务并发数，最有效的办法是拆分，拆分有两种，一是对库进行拆分，另一种是在同一个库中对表进行拆分。

    要做拆分必须要考虑拆分字段的依据，淘宝是根据订单号进行拆分的。淘宝现在的规模是将订单表拆分到16个mySql数据库中，在每个数据库中又将订单表横向拆分为64份，相当于将一个表拆分为1024份。拆分后事务会分散到1024套表中，这必定会增加并发的事务处理能力。（当然这种方法必定经过抗压测试）

    这里面会产生一个问题，拆分之后如何能保证买家和卖家快速的查询自己的订单。最好的办法是保证买家和卖家的订单在同一张表中。如何保证那？

     假定一个订单号是142424594267664；这个订单号对应的订单该放在哪台服务器上的哪个表中，是根据订单的后四位7667，对1024取模之后 决定的；同时7667是买家id的后四位。这样买家在查询其订单时就可以通过其id获得其订单所在库以及表，就可以方便有效的查询买家订单了

 

    同时会产生另外一个问题 卖家查询订单时怎么办？ 前面我们提到买家和卖家是分为两个不同的维度来设计的，卖家查询是不是直接查询订单表，而是通过卖家维度的表来查询的。卖家维度的表的插入和更新是通过在订单插入时发一个消息来通知插入的。同样对于发短信发旺旺也是通过消息来处理的，这些都不附加到下单的事务中去。

 

    即便是这样做了库和表的拆分依然会有问题，淘宝双十一一天的订单量达到了5000千万，这样在几个月后数据库中的数据依然会达到一个很大的量，处理速度也会随之下降。淘宝的做法是三个月前的老数据迁移到其它库中。这样会带来另外一个问题，用户在查询订单的时候需要查询两个库，一个历史数据，一个最近的数据，这样也是无可避免的，淘宝就是通过两次查询来实现这个过程的。

 

    拆分之后对全数据的统计肯定会有问题，实际上也很简单就是把数据迁移到其它数据库中来完成全数据的统计。

    库和表的拆分会大大提高TPS,这是需要可靠的消息通知机制来通知其它模块来完成非核心处理的事情，需要通过高效的搜素系统来保证搜素的数据的及时更新。

 

    这些都是我对淘宝下单高并发设计的理解。实际实施的时候肯定会有很多要考虑的问题，比如数据库的调优，磁盘的IO方式，服务器的稳定性，方案的可测实性可量化。