周末參加了@淘寶技術嘉年華 主辦的技術沙龍， 感覺收獲頗豐，非常感謝淘寶人的分享。這里我把淘寶下單高并發解決方案的個人理解分享一下。我不是淘寶技術人員，本文只是寫自己的理解，所以肯定是會有一些出入的。

　　在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取模就可以定位到具體的表上。

轉載于:https://www.cnblogs.com/jking10/p/4470690.html

總結

以上是生活随笔為你收集整理的[转]淘宝下单高并发解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。