高併發下單主要包括以下幾個方面：

• 分庫分表
• 多應用例項全域性唯一訂單號
• 資料庫連線
• 買家查詢訂單
• 賣家查詢訂單
• 擴容問題
• 業務拆分

一、分庫分表

隨著訂單量的增長，資料庫的發展主要經歷以下幾個步驟：
- 1主-1從架構
- 雙主-多從架構，讀寫分離
- 表分割槽，提高併發
- 分表，提高併發
- Master更換SSD
- 分庫，分表，提高併發

分庫分表實現過程

訂單分成16個庫，每個庫64個表進行儲存，總共1024個表，mysql單表效能超過千萬級別會導致效能嚴重下降，假設按千萬計算，最高可以儲存百億級訂單。隨著儲存問題的解決，但複雜度會隨著增加：

首先是多庫怎麼保證生成的訂單號全域性唯一；
其次查詢複雜度的增加；
買家查詢訂單時，應該去哪個庫哪個表裡查詢，賣家應該去哪查；
再大的儲存量，隨著資料量的增長，終究是會遇到瓶頸，該怎麼擴容。

二、全域性唯一訂單號

這裡採用Twitter snowflake方案，全劇唯一ID生成由：時間戳+機器ID+自增序列（+userid後兩位）；
訂單的生成過程直接在應用例項中生成，直接在記憶體中計算，且計算過程分散到每臺應用例項中，解決效能問題，userid後兩位在後面解釋。

三、資料庫連線問題

分庫分表後，要連線資料庫變的複雜起來，分為兩種方案：

一、jdbc直連

此種方式需要在應用程式碼中，自己計算訂單應該進入哪個庫，可取訂單的後兩位，先對庫16進行取模，再對錶64取模，從而確定。優點是直連資料庫效能更好，缺點是程式碼複雜度增加。

二、通過中間價連線

中間價可以使用阿里的mycat連線，具體使用檢視mycat文件。優點：程式碼實現簡單，跟分庫前差不多

四、買家查詢訂單

訂單成交後，買家需要查詢訂單的時候，只有userid，並不知道訂單存在哪個庫哪張表中，從每個庫每個表中遍歷一遍不現實。所以還要對訂單號進行改進，之前是：時間戳+機器ID+自增序列。現在此訂單號的後面加上userid的後兩位，時間戳+機器ID+自增序列+userid後兩位。訂單入庫取模的後兩位即userid後兩位，即同一個買家的所有訂單都會存入同一個表中，通過此設計買家即可找到訂單號應該在哪個表中。

五、賣家查詢訂單

賣家查詢訂單不能像買家一樣，賣家的訂單分散在訂單表的各個表中。賣家訂單需要在業務拆分過程中，將訂單按賣家維度存入到別的庫和表中。此維度不僅賣家可以查詢到對應所有訂單，並且方便統計、分析。

六、擴容問題

由於此方案已經不是單純的通過訂單號查詢訂單，還需要通過userid查詢訂單，其次是訂單具有時間特性，使用者查詢的大部分都是最近的訂單，3月前的訂單很少會檢視，所以不適合進行擴容，特別適合遷移歷史資料，將3個月前的資料遷移到歷史資料庫中，從而解決容量增長的問題。

七、業務拆分

下訂單過程，業務極其複雜，不只是訂單號的生成插入等，還要減庫存、支付等一系列的操作。所以應該通過訊息佇列將業務進行拆分，本步驟只做訂單生成的操作，通過訊息佇列實現資料的最終一致性。