來自公眾號：有關(guān)SQL
作者Lenis

如果各位看官的 SQL 數(shù)據(jù)庫真有 2W+ 高并發(fā)谐岁，那真是要恭喜你墨礁。你已經(jīng)比很多公司的 MIS 都要前衛(wèi)得多幢竹。2W 和 2K 差別有那么大嗎，嗯恩静，真是有的焕毫。2K 并發(fā)的 MIS 系統(tǒng)也經(jīng)常有無法訪問，timeout 的異常驶乾，處理這些異常已經(jīng)夠很多朋友苦惱的了邑飒。2W+ 的并發(fā)那需要懂的知識框架就更復雜了。

筆者曾服務(wù)了 500W+ 用戶的電商系統(tǒng)级乐，7*24 小時的噩夢再也不想見

前幾年在一家擁有 500 多萬直銷顧問的團隊做電商平臺疙咸。平時的流量很平穩(wěn)，基本都在千把风科，月底拼業(yè)績才會沖一沖撒轮，來個 1W+ 的并發(fā)。大部分的數(shù)據(jù)庫開發(fā)人員在日常中還是沒心沒肺沒壓力的贼穆。但電商系統(tǒng)有個慣例题山，都是淘寶帶出來的，會搞促銷故痊，類似于雙 11. 一到這時間段顶瞳，必須隨時警惕流量是不是井噴，一旦跨越紅線，系統(tǒng)就跟前期的 12306 一樣慨菱，頻頻延遲焰络。隨著 DBA 組的介入，才慢慢搞定這難題抡柿。本文的初衷也來自于這段經(jīng)歷的總結(jié)舔琅。

單實例數(shù)據(jù)庫應用

這種應用架構(gòu)最簡單，UI + 應用服務(wù)器 + 數(shù)據(jù)庫服務(wù)器洲劣，所有的請求备蚓，無論讀寫都直接拋給數(shù)據(jù)庫。往往項目初期囱稽，為了迅速的證明自己的點子靠譜郊尝，拿到市場，我們會選擇這樣的架構(gòu)來實現(xiàn)產(chǎn)品战惊。此時往往 10 萬用戶注冊了流昏，但每天訪問的人數(shù)剛過 200， 每張數(shù)據(jù)庫表的總數(shù)吞获，最大也不會超過 5000 條况凉。這樣的應用，開發(fā)能力強的各拷，1 個人就可以搞定刁绒，業(yè)務(wù)復雜的需要分前端和后端。但無論如何都屬于基礎(chǔ)項目烤黍，如果你工作 3知市，4 了還是停留在這種模式下，那該補補課了速蕊。

image

事物總是在發(fā)展之中的嫂丙，只要系統(tǒng)正常運行，總有一天用戶量會加大规哲，隨之而來的請求會超乎你的想象（前提你是做了 pv, uv 的數(shù)據(jù)分析）跟啤，很快這種架構(gòu)會遇到用戶超過 100 萬，日訪問量超過 20 萬唉锌，峰值并發(fā) 2 萬腥光，而數(shù)據(jù)庫的表會趨近于億級的量。此時應用系統(tǒng)如果還是建立在當初的硬件基礎(chǔ)上（比如 16GB糊秆，16 核，240GB 硬盤）應該會明顯感覺得到拖卡慢的尷尬议双，增多的是用戶的抱怨和投訴痘番。就像 12306 前期的購票一樣，往往輪到你的時候，票沒了汞舱。

image

多實例數(shù)據(jù)庫

遇到流量起來的應用伍纫，如果壓力確定是在數(shù)據(jù)庫上了，那么分庫是必然的事情了昂芜。將一個大庫拆成若干小庫莹规，保持數(shù)據(jù)庫對象都一致，這樣每個小庫分攤掉一部分流量泌神，應用終將回歸第一種簡單架構(gòu)上來良漱，將用戶服務(wù)好。以現(xiàn)在的硬件服務(wù) 4000 個并發(fā)欢际，對于不復雜的商用沒有問題母市。具體能負責多少看系統(tǒng)上線后的 baseline （基線）監(jiān)測，這里我們假定 4000 并發(fā)损趋。所以分成 5 個相同的庫患久，來做分庫。這樣同時寫入 4000 并發(fā)夠用浑槽。

image

這里會遇到一個技術(shù)細節(jié)蒋失，就是分庫路由。如何將流量均攤到每個庫里桐玻，是需要研制算法的篙挽。比如已知全國用戶分布均衡，即華東畸冲、華北嫉髓、華西、華南和華中邑闲，各有 4000 用戶算行。我們依據(jù)地理位置分成 5 個庫，根據(jù)用戶身份證哈希成 5 個散列值苫耸，分別對應了這 5 臺數(shù)據(jù)庫州邢，用戶就被分流了。

只要用戶不是劇烈增長褪子，老板也滿意這種小而美的生意量淌，這樣的架構(gòu)可以一直沿用下去∠油剩基本不會有瓶頸呀枢。頂多就是時間長了，表數(shù)據(jù)越來越大了笼痛，我們用分庫的思想進行分表就可以了裙秋。當前年份（月份）數(shù)據(jù)放在主表里面琅拌，而歷史數(shù)據(jù)就歸檔到聚合表里；或者索性每月摘刑，每年分成子表存儲进宝，而跨時間段的查詢用視圖來控制。

但用戶的行為始終是不可控的枷恕，我么必須做一系列的事情來滿足和留住用戶党晋。比如促銷、打折徐块、團購等等未玻。這個時候，用戶的行為不僅僅是下個單買杯咖啡這么簡單了蛹锰。他們會大量查詢他們的數(shù)據(jù)深胳，帶來的是讀請求遠遠大于寫入請求。眾所周知铜犬，讀請求即使不影響寫入請求（比如 MVVC）舞终，但也會耗盡服務(wù)器的 CPU\IO\Network 資源。那么我們必須更進入一層癣猾，讀寫分離敛劝。

讀寫分離

讀寫分離是另一種分庫，但與前面的分庫意圖不一樣纷宇。分出來的庫和源庫一模一樣夸盟，且只讀不接收用戶的寫入請求。實現(xiàn)細節(jié)每個數(shù)據(jù)庫都不一樣像捶，也可以使用實時同步工具做上陕，詳情可以參考《Designing Data-Intensive Applications》這本書。不僅僅給出了指導思想拓春，更有每種數(shù)據(jù)庫的讀寫分離組件指南释簿。

image