#高併發下單主要包括以下幾個方面：
分庫分表
多應用例項全域性唯一訂單號
資料庫連線
買家查詢訂單
賣家查詢訂單
擴容問題
業務拆分
一、分庫分表
隨著訂單量的增長，資料庫的發展主要經歷以下幾個步驟：
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個月前的資料遷移到歷史資料庫中，從而解決容量增長的問題。
##七、業務拆分
下訂單過程，業務極其複雜，不只是訂單號的生成插入等，還要減庫存、支付等一系列的操作。所以應該通過訊息佇列將業務進行拆分，本步驟只做訂單生成的操作，通過訊息佇列實現資料的最終一致性。
訂單系統設計 訂單號設計
三 因子分表法 唯一性 必要 每個訂單號全域性唯一代表乙個訂單 安全性 必要 訂單號不能透露訂單量 運營規模等業務資訊 資料安全性 高效能 訂單號的建立成本越低越好 擴充套件性 能夠較好的支撐後續業務發展變大帶來的分庫分表 訂單長度擴充套件等場景 不安全 訂單號能夠反映出系統的訂單量，存在業務資料外...
訂單系統訂單表設計方案
一年前，在上一家公司接手了乙個含有訂單系統的專案，業務並不複雜，但是當時令我比較困惑的是訂單表的設計。困惑的點主要是隨著訂單量增加，單錶的儲存能力將達到瓶頸，必然要採用分表的方案，那麼按照什麼維度拆分合適呢？分表之後帶來的最大的挑戰是訂單查詢。如果以使用者為中心，採用userid取模，可以很方便的處...
訂單系統設計 分頁查詢
1.2 查詢條件設計 二 技術方案 2.2 mysql es架構 三 db規範 產品設計不合理是導致深度分頁查詢的乙個重要原因，比如下圖所示的深度隨機跳頁設計方案，如果沒有特殊原因，正常情況下應避免使用。一方面，隨機跳頁實際意義有多大有待考究 另一方面，隨機性會加大後端的難度，如果隨機跳頁的頁碼很大...