今天簡單聊聊訂單系統每秒處理10萬訂單數據的架構，首先說明，是峯值10w，不是持續性的啊，其次我不曾有寫過或者設計過這麼大請求的系統，所以下面寫的都是的一點簡單看法吧，先看下物理架構圖。![]()
記得前些天公司評審我這邊寫的一個後端框架，當時確實有點驚訝，都是10年以上經驗的高開和技術總監，評審的內容不是底層原理、擴展性等，居然是對象之間怎麼調用。下面簡單說明下上面的物理架構吧，10w訂單數據，姑且估算7w檢索信息，3w訂單寫入信息。設計層面這裏我保守一點，做了個nginx/lvs的負載集羣和高可用集羣，負載集羣通過dns-server實現，高可用集羣通過keepalived組件實現，這樣單臺nginx的流量峯值就是5w，我這裏是保守哈，因爲我沒做過訂單系統，不瞭解業務，有那麼一句話，脫離業務談qps實屬裝逼耍流氓，同時在代理層面做了布隆過濾器，通過lua腳本實現，這裏主要是在入口層做一次過濾減壓，靜態資源做了cdn網絡加速。再往後就是k8s集羣，這裏主要是藉助k8s強大的服務生命週期管理和簡單服務治理能力，k8s集羣對外通過nginx-ingress網關接入，網關後面跑的就是一個個真實的應用服務，服務於服務之間通信通過rpc過程調用，當然這裏面會有很多細節，不討論。後面還有一個普羅米修斯，這裏我把它畫出來主要是體現結合HPA做pod的動態擴縮容，直白點就是當現有pod壓力過大，超過一定閾值，由k8s集羣自動根據負載擴縮容pod，好了，從入口到web服務，10w每秒的處理能力應該是能滿足了，即便是有更高的負載100w請求壓過來，代理和網關都可以做粗細管道和限流，當然前提還有帶寬，一般的企業沒有這麼大請求量。
接下來是最麻煩的一環數據持久化問題，這也是系統最大的瓶頸。10w每秒的數據庫操作，應該說在任何一個獨立的關係數據庫都無法完成，所以這裏個人採用的是分庫分表+讀寫分離。
水平分庫分表，分庫採用hash取模+1的算法並且以2的倍數進行擴容，如1-2-4-8-16以此類推，分表採用個位數%10的方式（每個庫的分表爲10個，編號0-9），這種分庫分表方式在後續進行動態擴容時只需要進行表級數據遷移，不需要行級數據遷移。如現在訂單庫有1個db1，需要擴容到2個db1、db2，以id10001爲例，原來這個id在db1（table1），現在擴容到兩個庫，10001id被落庫到了db2（table1），所以我只需要遷移table1的所有數據到db2即可。
id生成，建議兩個方案吧，snowflake分佈式id，或者redis原子生成，兩個方案都可以，redis支持一次區間取，snowflake一毫秒可以生成4096個id，所以不管哪種方案，都是滿足的。
讀寫分離，數據一致性問題，對於實時性要求並不是那麼嚴苛的話，這部分讀請求流量全部打入到讀庫，對於實時性要求極高的需求，這小部分流量還是需要打到mysql寫庫。
數據同步，兩種方案吧，1.mysql備份庫，通過mysql同步機制實現，這裏有個細節，如果沒有做庫表分片，千萬上億級數據還是壓力蠻大的。2.elasticsearch，es天生分佈式並且自帶hash分片算法，高吞吐，隨意動態擴縮容。實現方案canal+rabmq，canal是阿里開源中間件，原理跟mysql主從同步差不多，監聽binlog日誌文件，但是canal開發人員可以寫業務邏輯代碼，實現es庫和mysql的同步操作。當然這裏最好是用mq中間件解耦，canal只需要往mq寫，其他業務只需訂閱mq消息即可。
大概的設計就寫這麼多吧，整體主要是圍繞10w每秒的數據處理，當然業務處理還有很多細節，也很複雜，我簡單看了下一個訂單的創建需要交互N個服務，商品服務、運營、會員、倉儲、物流等等。技術細節同樣也非常複雜，如垂直分表、數據一致性、全局分佈式鎖、緩存、接口冪等、分佈式事務等等，暫時就寫這麼多吧，真實的架構是需要做數據計算的，而不是簡單的我要10wqps或者tps給我一個架構，架構沒有銀彈，需要不斷試錯重構。