要優化下單就要提高TPS （Transaction per second）每秒下單數，我們首先要做的是對下單的邏輯剝離，只保留核心部分，而把附加功能剔除出去。
比如說下單要考慮庫存量，考慮發短信，要給賣家發旺旺消息通知，要對訂單做統計，要做銷售額統計等等，這些功能是必要的，但是也是附加的功能，要最大程度提高下單這一步的TPS，就要先不考慮這些東西。
下單的核心是買家查看訂單，和賣家查看收到的訂單，修改訂單價格等。在下單這個操作中有買家和賣家兩個密切關聯而有不同的視角。可以稱為兩個不同的維度。
整個下單流程是在數據庫事務中心進行的，要提高數據庫的事務並發數，最有效的辦法是拆分，拆分有兩種，一是對庫進行拆分，另一種是在同一個庫中對表進行拆分。
要做拆分必須要考慮拆分字段的依據，淘寶是根據訂單號進行拆分的。淘寶現在的規模是將訂單表拆分到16個mySql數據庫中，在每個數據庫中又將訂單表橫向拆分為64份，相當於將一個表拆分為1024份。拆分后事務會分散到1024套表中，這必定會增加並發的事務處理能力。（當然這種方法必定經過抗壓測試）
這里面會產生一個問題，拆分之后如何能保證買家和賣家快速的查詢自己的訂單。最好的辦法是保證買家和賣家的訂單在同一張表中。如何保證那？
假定一個訂單號是142424594267664；這個訂單號對應的訂單該放在哪台服務器上的哪個表中，是根據訂單的后四位7667，對1024取模之后 決定的；同時7667是買家id的后四位。這樣買家在查詢其訂單時就可以通過其id獲得其訂單所在庫以及表，就可以方便有效的查詢買家訂單了
同時會產生另外一個問題 賣家查詢訂單時怎么辦？ 前面我們提到買家和賣家是分為兩個不同的維度來設計的，賣家查詢是不是直接查詢訂單表，而是通過賣家維度的表來查詢的。賣家維度的表的插入和更新是通過在訂單插入時發一個消息來通知插入的。同樣對於發短信發旺旺也是通過消息來處理的，這些都不附加到下單的事務中去。
即便是這樣做了庫和表的拆分依然會有問題，淘寶雙十一一天的訂單量達到了5000千萬，這樣在幾個月后數據庫中的數據依然會達到一個很大的量，處理速度也會隨之下降。淘寶的做法是三個月前的老數據遷移到其它庫中。這樣會帶來另外一個問題，用戶在查詢訂單的時候需要查詢兩個庫，一個歷史數據，一個最近的數據，這樣也是無可避免的，淘寶就是通過兩次查詢來實現這個過程的。
拆分之后對全數據的統計肯定會有問題，實際上也很簡單就是把數據遷移到其它數據庫中來完成全數據的統計。
庫和表的拆分會大大提高TPS,這是需要可靠的消息通知機制來通知其它模塊來完成非核心處理的事情，需要通過高效的搜素系統來保證搜素的數據的及時更新。
這些都是我對淘寶下單高並發設計的理解。實際實施的時候肯定會有很多要考慮的問題，比如數據庫的調優，磁盤的IO方式，服務器的穩定性，方案的可測實性可量化。