如果各位看官的 SQL 數(shù)據(jù)庫(kù)真有 2W+ 高并發(fā)，那真是要恭喜你。你已經(jīng)比很多公司的 MIS 都要前衛(wèi)得多。
2W 和 2K 差別有那么大嗎？
嗯，真是有的。2K 并發(fā)的 MIS 系統(tǒng)也經(jīng)常有無(wú)法訪問(wèn)，timeout 的異常，處理這些異常已經(jīng)夠很多朋友苦惱的了。2W+ 的并發(fā)那需要懂的知識(shí)框架就更復(fù)雜了。
筆者曾服務(wù)了 500W+ 用戶(hù)的電商系統(tǒng)，7*24 小時(shí)的噩夢(mèng)再也不想見(jiàn)。
前幾年在一家擁有 500 多萬(wàn)直銷(xiāo)顧問(wèn)的團(tuán)隊(duì)做電商平臺(tái)。平時(shí)的流量很平穩(wěn)，基本都在千把，月底拼業(yè)績(jī)才會(huì)沖一沖，來(lái)個(gè) 1W+ 的并發(fā)。
大部分的數(shù)據(jù)庫(kù)開(kāi)發(fā)人員在日常中還是沒(méi)心沒(méi)肺沒(méi)壓力的。但電商系統(tǒng)有個(gè)慣例，都是淘寶帶出來(lái)的，會(huì)搞促銷(xiāo)，類(lèi)似于雙 11. 一到這時(shí)間段，必須隨時(shí)警惕流量是不是井噴，一旦跨越紅線，系統(tǒng)就跟前期的 12306 一樣，頻頻延遲。
隨著 DBA 組的介入，才慢慢搞定這難題。本文的初衷也來(lái)自于這段經(jīng)歷的總結(jié)。
一、單實(shí)例數(shù)據(jù)庫(kù)應(yīng)用
這種應(yīng)用架構(gòu)最簡(jiǎn)單，UI + 應(yīng)用服務(wù)器 + 數(shù)據(jù)庫(kù)服務(wù)器，所有的請(qǐng)求，無(wú)論讀寫(xiě)都直接拋給數(shù)據(jù)庫(kù)。
往往項(xiàng)目初期，為了迅速的證明自己的點(diǎn)子靠譜，拿到市場(chǎng)，我們會(huì)選擇這樣的架構(gòu)來(lái)實(shí)現(xiàn)產(chǎn)品。此時(shí)往往 10 萬(wàn)用戶(hù)注冊(cè)了，但每天訪問(wèn)的人數(shù)剛過(guò) 200，每張數(shù)據(jù)庫(kù)表的總數(shù)，最大也不會(huì)超過(guò) 5000 條。
這樣的應(yīng)用，開(kāi)發(fā)能力強(qiáng)的，1 個(gè)人就可以搞定，業(yè)務(wù)復(fù)雜的需要分前端和后端。
但無(wú)論如何都屬于基礎(chǔ)項(xiàng)目，如果你工作 3，4 了還是停留在這種模式下，那該補(bǔ)補(bǔ)課了。
事物總是在發(fā)展之中的，只要系統(tǒng)正常運(yùn)行，總有一天用戶(hù)量會(huì)加大，隨之而來(lái)的請(qǐng)求會(huì)超乎你的想象（前提你是做了 pv, uv 的數(shù)據(jù)分析），很快這種架構(gòu)會(huì)遇到用戶(hù)超過(guò) 100 萬(wàn)，日訪問(wèn)量超過(guò) 20 萬(wàn)，峰值并發(fā) 2 萬(wàn)，而數(shù)據(jù)庫(kù)的表會(huì)趨近于億級(jí)的量。
此時(shí)應(yīng)用系統(tǒng)如果還是建立在當(dāng)初的硬件基礎(chǔ)上（比如 16GB，16 核，240GB 硬盤(pán)）應(yīng)該會(huì)明顯感覺(jué)得到拖卡慢的尷尬，增多的是用戶(hù)的抱怨和投訴。
就像 12306 前期的購(gòu)票一樣，往往輪到你的時(shí)候，票沒(méi)了。
二、多實(shí)例數(shù)據(jù)庫(kù)
遇到流量起來(lái)的應(yīng)用，如果壓力確定是在數(shù)據(jù)庫(kù)上了，那么分庫(kù)是必然的事情了。
將一個(gè)大庫(kù)拆成若干小庫(kù)，保持?jǐn)?shù)據(jù)庫(kù)對(duì)象都一致，這樣每個(gè)小庫(kù)分?jǐn)偟粢徊糠至髁浚瑧?yīng)用終將回歸第一種簡(jiǎn)單架構(gòu)上來(lái)，將用戶(hù)服務(wù)好。
以現(xiàn)在的硬件服務(wù) 4000 個(gè)并發(fā)，對(duì)于不復(fù)雜的商用沒(méi)有問(wèn)題。具體能負(fù)責(zé)多少看系統(tǒng)上線后的 baseline （基線）監(jiān)測(cè)，這里我們假定 4000 并發(fā)。所以分成 5 個(gè)相同的庫(kù)，來(lái)做分庫(kù)。這樣同時(shí)寫(xiě)入 4000 并發(fā)夠用。
這里會(huì)遇到一個(gè)技術(shù)細(xì)節(jié)，就是分庫(kù)路由。
如何將流量均攤到每個(gè)庫(kù)里，是需要研制算法的。比如已知全國(guó)用戶(hù)分布均衡，即華東、華北、華西、華南和華中，各有 4000 用戶(hù)。
我們依據(jù)地理位置分成 5 個(gè)庫(kù)，根據(jù)用戶(hù)身份證哈希成 5 個(gè)散列值，分別對(duì)應(yīng)了這 5 臺(tái)數(shù)據(jù)庫(kù)，用戶(hù)就被分流了。
只要用戶(hù)不是劇烈增長(zhǎng)，老板也滿(mǎn)意這種小而美的生意，這樣的架構(gòu)可以一直沿用下去。基本不會(huì)有瓶頸。頂多就是時(shí)間長(zhǎng)了，表數(shù)據(jù)越來(lái)越大了，我們用分庫(kù)的思想進(jìn)行分表就可以了。
當(dāng)前年份（月份）數(shù)據(jù)放在主表里面，而歷史數(shù)據(jù)就歸檔到聚合表里；或者索性每月，每年分成子表存儲(chǔ)，而跨時(shí)間段的查詢(xún)用視圖來(lái)控制。
但用戶(hù)的行為始終是不可控的，我么必須做一系列的事情來(lái)滿(mǎn)足和留住用戶(hù)。比如促銷(xiāo)、打折、團(tuán)購(gòu)等等。
這個(gè)時(shí)候，用戶(hù)的行為不僅僅是下個(gè)單買(mǎi)杯咖啡這么簡(jiǎn)單了。他們會(huì)大量查詢(xún)他們的數(shù)據(jù)，帶來(lái)的是讀請(qǐng)求遠(yuǎn)遠(yuǎn)大于寫(xiě)入請(qǐng)求。
眾所周知，讀請(qǐng)求即使不影響寫(xiě)入請(qǐng)求（比如 MVVC），但也會(huì)耗盡服務(wù)器的 CPUIONetwork 資源。那么我們必須更進(jìn)入一層，讀寫(xiě)分離。
三、讀寫(xiě)分離
讀寫(xiě)分離是另一種分庫(kù)，但與前面的分庫(kù)意圖不一樣。分出來(lái)的庫(kù)和源庫(kù)一模一樣，且只讀不接收用戶(hù)的寫(xiě)入請(qǐng)求。實(shí)現(xiàn)細(xì)節(jié)每個(gè)數(shù)據(jù)庫(kù)都不一樣，也可以使用實(shí)時(shí)同步工具做，詳情可以參考《Designing Data-Intensive Applications》這本書(shū)。不僅僅給出了指導(dǎo)思想，更有每種數(shù)據(jù)庫(kù)的讀寫(xiě)分離組件指南。
作者：Lenis
