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