如果各位看官的 SQL 數據庫真有 2W+ 高併發，那真是要恭喜你。你已經比很多公司的 MIS 都要前衛得多。2W 和 2K 差別有那麼大嗎，嗯，真是有的。2K 併發的 MIS 系統也經常有無法訪問，timeout 的異常，處理這些異常已經夠很多朋友苦惱的了。2W+ 的併發那需要懂的知識框架就更復雜了。
前幾年在一家擁有 500 多萬直銷顧問的團隊做電商平臺。平時的流量很平穩，基本都在千把，月底拼業績才會衝一衝，來個 1W+ 的併發。大部分的數據庫開發人員在日常中還是沒心沒肺沒壓力的。但電商系統有個慣例，都是淘寶帶出來的，會搞促銷，類似於雙 11. 一到這時間段，必須隨時警惕流量是不是井噴，一旦跨越紅線，系統就跟前期的 12306 一樣，頻頻延遲。隨著 DBA 組的介入，才慢慢搞定這難題。
單實例數據庫應用
這種應用架構最簡單，UI + 應用服務器 + 數據庫服務器，所有的請求，無論讀寫都直接拋給數據庫。往往項目初期，為了迅速的證明自己的點子靠譜，拿到市場，我們會選擇這樣的架構來實現產品。此時往往 10 萬用戶註冊了，但每天訪問的人數剛過 200， 每張數據庫表的總數，最大也不會超過 5000 條。這樣的應用，開發能力強的，1 個人就可以搞定，業務複雜的需要分前端和後端。但無論如何都屬於基礎項目，如果你工作 3，4 了還是停留在這種模式下，那該補補課了。
事物總是在發展之中的，只要系統正常運行，總有一天用戶量會加大，隨之而來的請求會超乎你的想象（前提你是做了 pv, uv 的數據分析），很快這種架構會遇到用戶超過 100 萬，日訪問量超過 20 萬，峰值併發 2 萬，而數據庫的表會趨近於億級的量。此時應用系統如果還是建立在當初的硬件基礎上（比如 16GB，16 核，240GB 硬盤）應該會明顯感覺得到拖卡慢的尷尬，增多的是用戶的抱怨和投訴。就像 12306 前期的購票一樣，往往輪到你的時候，票沒了。
多實例數據庫
遇到流量起來的應用，如果壓力確定是在數據庫上了，那麼分庫是必然的事情了。將一個大庫拆成若干小庫，保持數據庫對象都一致，這樣每個小庫分攤掉一部分流量，應用終將回歸第一種簡單架構上來，將用戶服務好。以現在的硬件服務 4000 個併發，對於不復雜的商用沒有問題。具體能負責多少看系統上線後的 baseline （基線）監測，這裡我們假定 4000 併發。所以分成 5 個相同的庫，來做分庫。這樣同時寫入 4000 併發夠用。
這裡會遇到一個技術細節，就是分庫路由。如何將流量均攤到每個庫裡，是需要研製算法的。比如已知全國用戶分佈均衡，即華東、華北、華西、華南和華中，各有 4000 用戶。我們依據地理位置分成 5 個庫，根據用戶身份證哈希成 5 個散列值，分別對應了這 5 臺數據庫，用戶就被分流了。
只要用戶不是劇烈增長，老闆也滿意這種小而美的生意，這樣的架構可以一直沿用下去。基本不會有瓶頸。頂多就是時間長了，表數據越來越大了，我們用分庫的思想進行分表就可以了。當前年份（月份）數據放在主表裡面，而歷史數據就歸檔到聚合表裡；或者索性每月，每年分成子表存儲，而跨時間段的查詢用視圖來控制。
但用戶的行為始終是不可控的，我麼必須做一系列的事情來滿足和留住用戶。比如促銷、打折、團購等等。這個時候，用戶的行為不僅僅是下個單買杯咖啡這麼簡單了。他們會大量查詢他們的數據，帶來的是讀請求遠遠大於寫入請求。眾所周知，讀請求即使不影響寫入請求（比如 MVVC），但也會耗盡服務器的 CPU\IO\Network 資源。那麼我們必須更進入一層，讀寫分離。
讀寫分離
讀寫分離是另一種分庫，但與前面的分庫意圖不一樣。分出來的庫和源庫一模一樣，且只讀不接收用戶的寫入請求。實現細節每個數據庫都不一樣，也可以使用實時同步工具做，詳情可以參考《Designing Data-Intensive Applications》這本書。不僅僅給出了指導思想，更有每種數據庫的讀寫分離組件指南。
當然百萬級的表或許調一下索引和分區，就可以獲得很好的性能了，並不需要用到分庫分表，分佈式存儲與計算。
閱讀更多 java技術人 的文章
