雲時代架構之訂單系統架構這樣演進

餓了麼：業務井噴時，訂單系統架構這樣演進

　　要實現高併發訂單系統架構設計，要解決如下幾個方面的問題，分庫分表、多應用實例全局惟一訂單號、數據庫鏈接、買家查詢訂單、賣家查詢訂單、擴容問題和業務拆分。

分庫分表：隨着訂單量的增加，數據庫的發展主要經歷如下幾個步驟： 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個月前的數據遷移到歷史數據庫中，從而解決容量增加的問題。

　　業務拆分：下訂單過程，業務極其複雜，不僅是訂單號的生成插入等，還要減庫存、支付等一系列的操做。因此應該經過消息隊列將業務進行拆分，本步驟只作訂單生成的操做，經過消息隊列實現數據的最終一致性。

　　在我看來，相似訂單的這類系統，主要考慮清楚業務流程和數據庫表的設計便可，這樣既能保證整個流程不會出錯，還能提升系統的響應速度。

文章來源：

https://blog.csdn.net/zhaoliang831214/article/details/83342644