#高併發下單主要包括以下幾個方面：
分庫分表
多應用實例全局唯一訂單號
數據庫連接
買家查詢訂單
賣家查詢訂單
擴容問題
業務拆分
一、分庫分表
隨着訂單量的增長，數據庫的發展主要經歷以下幾個步驟：
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個月前的數據遷移到歷史數據庫中，從而解決容量增長的問題。
##七、業務拆分
下訂單過程，業務極其複雜，不只是訂單號的生成插入等，還要減庫存、支付等一系列的操作。所以應該通過消息隊列將業務進行拆分，本步驟只做訂單生成的操作，通過消息隊列實現數據的最終一致性。