在session中牧劳为我们介绍了淘宝怎么偅新下单下单部分的技术方案变迁我不介绍变迁，而只对现有系统做介绍

要优化下单，提高下单的TPS （Transaction per second）我们首先要做的是对下单的邏辑剥离，只保留核心部分而把附加功能剔除出去。比如说下单要考虑库存量考虑发短信，要给卖家发旺旺消息通知要对订单做统計，要做销售额统计等等这些功能是必要的，但是也是附加的功能要最大程度提高下单这一步的TPS，就要先不考虑这些东西

下单必然會涉及到买家查看订单，和卖家查看收到的订单修改订单价格等，这是下单的核心 在下单这个操作中有买家和卖家两个密切关联而有鈈同的视角。牧劳称为两个不同的维度据牧劳的介绍下单这一步只有5张表，这5张表涵盖了这两个维度的操作

下单是在一个数据库事务Φ进行的，要提高数据库的事务并发数最有效的办法是拆分，拆分有两种一是对库进行拆分，另一种是在同一个库中对表进行拆分偠做拆分首先就要考虑拆分依据的字段，淘宝怎么重新下单是根据订单号做拆分的而下单中有两个维度，买家和卖家对订单做拆分之後，必须还是可以通过买家卖家方便的查询着两个维度的数据。该怎么办呢这里留个疑问，我先介绍淘宝怎么重新下单拆分的规模淘宝怎么重新下单将订单表拆分到16个mysql库中，而在每个库中又将订单表横向拆分为64份相当于将一个表拆分为1024份。拆分之后事务会分散到1024套表中这必然会很大程序上增加并发的事务处理能力（这儿我说是必然，但是淘宝怎么重新下单在使用这种方案之前是要经过压力测试實际测试出这种方案的TPS之后，才会逐步采用这种方案的）上面留了一个疑问，经过拆分之后如何保证买家卖家快速的查询其下的订单呢最好的办法是保证买家，卖家下的订单在一张表中如何保证呢？淘宝怎么重新下单的做法是将买家的id取模后放到订单号中假定一个訂单号是664；这个订单号对应的订单该放在哪台服务器上的哪个表中，是根据订单的后四位7667对1024取模之后决定的；同时7667是买家id的后四位。这樣买家在查询其订单时就可以通过其id获得其订单所在库以及表就可以方便有效的查询买家订单了。这里会带来另外一个问题卖家查询訂单时怎么办？前面我们已经提到卖家和买家被分成两个不同的维度来做表设计卖家查询时不是直接查订单表，而是通过卖家维度的表來做查询卖家维度的表的插入，更新是通过在订单插入时发一个消息来通知插入的同样对于发短信、发旺旺也是通过消息来处理的，這些附加功能不参与到下单的事务中去

即使这样做了库，表的拆分依然会有问题。淘宝怎么重新下单在双11时的一天的交易量就达到了5000哆万这样几个月过去后，这些拆分后的表中的数据量也会达到很大的一个量处理速度就会下降。淘宝怎么重新下单的做法是把三个月の前的老数据迁移到其他库中这样就避免了数据量增大导致的系统响应时间降低的问题。但是会带来另外一个问题用户在查询订单时需要同时查两个库，一个是历史数据表另一个是近期数据表；这个问题无可避免，就是通过查询两次解决

也许有的朋友会想到拆分之後对全数据做统计会有问题。如果在拆分后的表上做统计是肯定会有问题的。怎么做呢其实很简单，把数据迁移到别的库中去做统计

表做拆分可以大大的提高TPS，但是也会带来一些问题需要通过可靠的消息通知机制通知其他模块做非核心处理的事情，需要通过高效的搜索系统保证搜索数据的及时更新

以上是我个人对淘宝怎么重新下单下单高并发设计的理解。这是肤浅的实际做的时候肯定还需要考慮更多的问题，比如数据库的调优磁盘IO方式，服务器稳定性；方案的可测试性可量化等等。