订单系统的优化方案

要优化订单系统，提高订单的每秒交易数量（TPS，Transactionper second），我们首先要做的是对下订单的逻辑进行剥离，只保留核心部分，而把附加功能剔除出去。比如说下单要考虑库存量、考虑发短信、要给卖家发消息通知、要对订单做统计、要做销售额统计等，我们需要对这些功能进行分析，哪些功能是必需的，哪些是附加的功能，要最大程度提高下单这一步的TPS，就要先不考虑这些附加的功能。

下单必然会涉及到买家查看订单，和卖家查看收到的订单，修改订单价格等，这是下订单的核心。在下单这个操作中有买家和卖家两个密切关联而有不同的视角，可以称为两个不同的维度。一般来说，订单系统的下单过程这一步涉及到少数几张核心数据表，而这几张数据表涵盖了这两个维度的操作。

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

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

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

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

欢迎关注麦克叔叔每晚10点说，让我们一起交流与学习。