淘寶下單高并發(fā)解決方案
周末參加了@淘寶技術(shù)嘉年華 主辦的技術(shù)沙龍， 感覺收獲頗豐，非常感謝淘寶人的分享。這里我把淘寶下單高并發(fā)解決方案的個人理解分享一下。我不是淘寶技術(shù)人員，本文只是寫自己的理解，所以肯定是會有一些出入的。
在session中牧勞為我們介紹了淘寶下單部分的技術(shù)方案變遷，我不介紹變遷，而只對現(xiàn)有系統(tǒng)做介紹。
要優(yōu)化下單，提高下單的TPS （Transaction per second），我們首先要做的是對下單的邏輯剝離，只保留核心部分，而把附加功能剔除出去。比如說下單要考慮庫存量，考慮發(fā)短信，要給賣家發(fā)旺旺消息通知，要對訂單做統(tǒng)計，要做銷售額統(tǒng)計等等，這些功能是必要的，但是也是附加的功能，要最大程度提高下單這一步的TPS，就要先不考慮這些東西。
下單必然會涉及到買家查看訂單，和賣家查看收到的訂單，修改訂單價格等，這是下單的核心。 在下單這個操作中有買家和賣家兩個密切關(guān)聯(lián)而有不同的視角。牧勞稱為兩個不同的維度。據(jù)牧勞的介紹下單這一步只有5張表，這5張表涵蓋了這兩個維度的操作。
下單是在一個數(shù)據(jù)庫事務(wù)中進行的，要提高數(shù)據(jù)庫的事務(wù)并發(fā)數(shù)，最有效的辦法是拆分，拆分有兩種，一是對庫進行拆分，另一種是在同一個庫中對表進行拆分。要做拆分首先就要考慮拆分依據(jù)的字段，淘寶是根據(jù)訂單號做拆分的，而下單中有兩個維度，買家和賣家，對訂單做拆分之后，必須還是可以通過買家，賣家方便的查詢著兩個維度的數(shù)據(jù)。該怎么辦呢？這里留個疑問，我先介紹淘寶拆分的規(guī)模，淘寶將訂單表拆分到16個mysql庫中，而在每個庫中又將訂單表橫向拆分為64份，相當于將一個表拆分為1024份。拆分之后事務(wù)會分散到1024套表中，這必然會很大程序上增加并發(fā)的事務(wù)處理能力（這兒我說是必然，但是淘寶在使用這種方案之前是要經(jīng)過壓力測試，實際測試出這種方案的TPS之后，才會逐步采用這種方案的）。上面留了一個疑問，經(jīng)過拆分之后如何保證買家賣家快速的查詢其下的訂單呢？最好的辦法是保證買家，賣家下的訂單在一張表中，如何保證呢？淘寶的做法是將買家的id取模后放到訂單號中。假定一個訂單號是142424594267664；這個訂單號對應(yīng)的訂單該放在哪臺服務(wù)器上的哪個表中，是根據(jù)訂單的后四位7667，對1024取模之后決定的；同時7667是買家id的后四位。這樣買家在查詢其訂單時就可以通過其id獲得其訂單所在庫以及表，就可以方便有效的查詢買家訂單了。這里會帶來另外一個問題，賣家查詢訂單時怎么辦？前面我們已經(jīng)提到賣家和買家被分成兩個不同的維度來做表設(shè)計，賣家查詢時不是直接查訂單表，而是通過賣家維度的表來做查詢。賣家維度的表的插入，更新是通過在訂單插入時發(fā)一個消息來通知插入的。同樣對于發(fā)短信、發(fā)旺旺也是通過消息來處理的，這些附加功能不參與到下單的事務(wù)中去。
即使這樣做了庫，表的拆分，依然會有問題。淘寶在雙11時的一天的交易量就達到了5000多萬，這樣幾個月過去后，這些拆分后的表中的數(shù)據(jù)量也會達到很大的一個量，處理速度就會下降。淘寶的做法是把三個月之前的老數(shù)據(jù)遷移到其他庫中，這樣就避免了數(shù)據(jù)量增大導(dǎo)致的系統(tǒng)響應(yīng)時間降低的問題。但是會帶來另外一個問題，用戶在查詢訂單時需要同時查兩個庫，一個是歷史數(shù)據(jù)表，另一個是近期數(shù)據(jù)表；這個問題無可避免，就是通過查詢兩次解決。
也許有的朋友會想到拆分之后對全數(shù)據(jù)做統(tǒng)計會有問題。如果在拆分后的表上做統(tǒng)計，是肯定會有問題的。怎么做呢？其實很簡單，把數(shù)據(jù)遷移到別的庫中去做統(tǒng)計。
表做拆分可以大大的提高TPS，但是也會帶來一些問題，需要通過可靠的消息通知機制通知其他模塊做非核心處理的事情，需要通過高效的搜索系統(tǒng)保證搜索數(shù)據(jù)的及時更新。
以上是我個人對淘寶下單高并發(fā)設(shè)計的理解。這是膚淺的，實際做的時候肯定還需要考慮更多的問題，比如數(shù)據(jù)庫的調(diào)優(yōu)，磁盤IO方式，服務(wù)器穩(wěn)定性；方案的可測試性，可量化等等。
上周六的技術(shù)還分享介紹了很多其他方面的精彩內(nèi)容。感謝主辦方，主持人！ 期待@淘寶技術(shù)嘉年華 更多精彩的技術(shù)沙龍。
訂單號介紹勘誤：
文中對于訂單號的表述有點問題，對于16臺服務(wù)器，每臺服務(wù)器64張表只需要2位買家或賣家id的后兩位數(shù)字就可以準確定位到具體的庫和表。訂單號中同時存在買家id的最后兩位和賣家id的最后兩位。分別在訂單號的倒數(shù)第3，4位數(shù)和最后兩位數(shù)。
假定買家id為123456789，那么在訂單號中的最后兩位就是89，通過89對16取模就可以定位到具體的庫上，通過對64取模就可以定位到具體的表上。
原文鏈接：http://www.cnblogs.com/yukaizhao/archive/2012/04/23/taobao_order_design.html
【編輯推薦】
