目錄：

• 用一個(gè)創(chuàng)業(yè)公司的發(fā)展作為背景引入
• 用多臺(tái)服務(wù)器來(lái)分庫(kù)支撐高并發(fā)讀寫(xiě)
• 大量分表來(lái)保證海量數(shù)據(jù)下查詢性能
• 讀寫(xiě)分離來(lái)支撐按需擴(kuò)容及性能提升
• 高并發(fā)下的數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)總結(jié)

這篇文章，我們來(lái)聊一下對(duì)于一個(gè)支撐日活百萬(wàn)用戶的高并系統(tǒng)，他的數(shù)據(jù)庫(kù)架構(gòu)應(yīng)該如何設(shè)計(jì)？

看到這個(gè)題目，很多人第一反應(yīng)就是：

分庫(kù)分表??！

但是實(shí)際上，數(shù)據(jù)庫(kù)層面的分庫(kù)分表到底是用來(lái)干什么的，他的不同的作用如何應(yīng)對(duì)不同的場(chǎng)景，我覺(jué)得很多同學(xué)可能都沒(méi)搞清楚。

一、用一個(gè)創(chuàng)業(yè)公司的發(fā)展作為背景引入

假如我們現(xiàn)在是一個(gè)小創(chuàng)業(yè)公司，注冊(cè)用戶就20萬(wàn)，每天活躍用戶就1萬(wàn)，每天單表數(shù)據(jù)量就1000，然后高峰期每秒鐘并發(fā)請(qǐng)求最多就10。

天哪！就這種系統(tǒng)，隨便找一個(gè)有幾年工作經(jīng)驗(yàn)的高級(jí)工程師，然后帶幾個(gè)年輕工程師，隨便干干都可以做出來(lái)。

因?yàn)檫@樣的系統(tǒng)，實(shí)際上主要就是在前期快速的進(jìn)行業(yè)務(wù)功能的開(kāi)發(fā)，搞一個(gè)單塊系統(tǒng)部署在一臺(tái)服務(wù)器上，然后連接一個(gè)數(shù)據(jù)庫(kù)就可以了。

接著大家就是不停的在一個(gè)工程里填充進(jìn)去各種業(yè)務(wù)代碼，盡快把公司的業(yè)務(wù)支撐起來(lái)，如下圖所示。

結(jié)果呢，沒(méi)想到我們運(yùn)氣這么好，碰上個(gè)優(yōu)秀的CEO帶著我們走上了康莊大道！

公司業(yè)務(wù)發(fā)展迅猛，過(guò)了幾個(gè)月，注冊(cè)用戶數(shù)達(dá)到了2000萬(wàn)！每天活躍用戶數(shù)100萬(wàn)！每天單表新增數(shù)據(jù)量達(dá)到50萬(wàn)條！高峰期每秒請(qǐng)求量達(dá)到1萬(wàn)！

同時(shí)公司還順帶著融資了兩輪，估值達(dá)到了驚人的幾億美金！一只朝氣蓬勃的幼年獨(dú)角獸的節(jié)奏！

好吧，現(xiàn)在大家感覺(jué)壓力已經(jīng)有點(diǎn)大了，為啥呢？

因?yàn)槊刻靻伪硇略?0萬(wàn)條數(shù)據(jù)，一個(gè)月就多1500萬(wàn)條數(shù)據(jù)，一年下來(lái)單表會(huì)達(dá)到上億條數(shù)據(jù)。

經(jīng)過(guò)一段時(shí)間的運(yùn)行，現(xiàn)在咱們單表已經(jīng)兩三千萬(wàn)條數(shù)據(jù)了，勉強(qiáng)還能支撐著。

但是，眼見(jiàn)著系統(tǒng)訪問(wèn)數(shù)據(jù)庫(kù)的性能怎么越來(lái)越差呢，單表數(shù)據(jù)量越來(lái)越大，拖垮了一些復(fù)雜查詢SQL的性能??！

然后高峰期請(qǐng)求現(xiàn)在是每秒1萬(wàn)，咱們的系統(tǒng)在線上部署了20臺(tái)機(jī)器，平均每臺(tái)機(jī)器每秒支撐500請(qǐng)求，這個(gè)還能抗住，沒(méi)啥大問(wèn)題。

但是數(shù)據(jù)庫(kù)層面呢？

如果說(shuō)此時(shí)你還是一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器在支撐每秒上萬(wàn)的請(qǐng)求，負(fù)責(zé)任的告訴你，每次高峰期會(huì)出現(xiàn)下述問(wèn)題：

• 你的數(shù)據(jù)庫(kù)服務(wù)器的磁盤(pán)IO、網(wǎng)絡(luò)帶寬、CPU負(fù)載、內(nèi)存消耗，都會(huì)達(dá)到非常高的情況，數(shù)據(jù)庫(kù)所在服務(wù)器的整體負(fù)載會(huì)非常重，甚至都快不堪重負(fù)了
• 高峰期時(shí)，本來(lái)你單表數(shù)據(jù)量就很大，SQL性能就不太好，這時(shí)加上你的數(shù)據(jù)庫(kù)服務(wù)器負(fù)載太高導(dǎo)致性能下降，就會(huì)發(fā)現(xiàn)你的SQL性能更差了
• 最明顯的一個(gè)感覺(jué)，就是你的系統(tǒng)在高峰期各個(gè)功能都運(yùn)行的很慢，用戶體驗(yàn)很差，點(diǎn)一個(gè)按鈕可能要幾十秒才出來(lái)結(jié)果
• 如果你運(yùn)氣不太好，數(shù)據(jù)庫(kù)服務(wù)器的配置不是特別的高的話，弄不好你還會(huì)經(jīng)歷數(shù)據(jù)庫(kù)宕機(jī)的情況，因?yàn)樨?fù)載太高對(duì)數(shù)據(jù)庫(kù)壓力太大了

二、多臺(tái)服務(wù)器分庫(kù)支撐高并發(fā)讀寫(xiě)

首先我們先考慮第一個(gè)問(wèn)題，數(shù)據(jù)庫(kù)每秒上萬(wàn)的并發(fā)請(qǐng)求應(yīng)該如何來(lái)支撐呢？

要搞清楚這個(gè)問(wèn)題，先得明白一般數(shù)據(jù)庫(kù)部署在什么配置的服務(wù)器上。

通常來(lái)說(shuō)，假如你用普通配置的服務(wù)器來(lái)部署數(shù)據(jù)庫(kù)，那也起碼是16核32G的機(jī)器配置。

這種非常普通的機(jī)器配置部署的數(shù)據(jù)庫(kù)，一般線上的經(jīng)驗(yàn)是：不要讓其每秒請(qǐng)求支撐超過(guò)2000，一般控制在2000左右。

控制在這個(gè)程度，一般數(shù)據(jù)庫(kù)負(fù)載相對(duì)合理，不會(huì)帶來(lái)太大的壓力，沒(méi)有太大的宕機(jī)風(fēng)險(xiǎn)。

所以首先第一步，就是在上萬(wàn)并發(fā)請(qǐng)求的場(chǎng)景下，部署個(gè)5臺(tái)服務(wù)器，每臺(tái)服務(wù)器上都部署一個(gè)數(shù)據(jù)庫(kù)實(shí)例。

然后每個(gè)數(shù)據(jù)庫(kù)實(shí)例里，都創(chuàng)建一個(gè)一樣的庫(kù)，比如說(shuō)訂單庫(kù)。

此時(shí)在5臺(tái)服務(wù)器上都有一個(gè)訂單庫(kù)，名字可以類似為：db_order_01，db_order_02，等等。

然后每個(gè)訂單庫(kù)里，都有一個(gè)相同的表，比如說(shuō)訂單庫(kù)里有訂單信息表，那么此時(shí)5個(gè)訂單庫(kù)里都有一個(gè)訂單信息表。

比如db_order_01庫(kù)里就有一個(gè)tb_order_01表，db_order_02庫(kù)里就有一個(gè)tb_order_02表。

這就實(shí)現(xiàn)了一個(gè)基本的分庫(kù)分表的思路，原來(lái)的一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器變成了5臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，原來(lái)的一個(gè)庫(kù)變成了5個(gè)庫(kù)，原來(lái)的一張表變成了5個(gè)表。

然后你在寫(xiě)入數(shù)據(jù)的時(shí)候，需要借助數(shù)據(jù)庫(kù)中間件，比如sharding-jdbc，或者是mycat，都可以。

你可以根據(jù)比如訂單id來(lái)hash后按5取模，比如每天訂單表新增50萬(wàn)數(shù)據(jù)，此時(shí)其中10萬(wàn)條數(shù)據(jù)會(huì)落入db_order_01庫(kù)的tb_order_01表，另外10萬(wàn)條數(shù)據(jù)會(huì)落入db_order_02庫(kù)的tb_order_02表，以此類推。

這樣就可以把數(shù)據(jù)均勻分散在5臺(tái)服務(wù)器上了，查詢的時(shí)候，也可以通過(guò)訂單id來(lái)hash取模，去對(duì)應(yīng)的服務(wù)器上的數(shù)據(jù)庫(kù)里，從對(duì)應(yīng)的表里查詢那條數(shù)據(jù)出來(lái)即可。

依據(jù)這個(gè)思路畫(huà)出的圖如下所示，大家可以看看。

做這一步有什么好處呢？

第一個(gè)好處，原來(lái)比如訂單表就一張表，這個(gè)時(shí)候不就成了5張表了么，那么每個(gè)表的數(shù)據(jù)就變成1/5了。

假設(shè)訂單表一年有1億條數(shù)據(jù)，此時(shí)5張表里每張表一年就2000萬(wàn)數(shù)據(jù)了。

那么假設(shè)當(dāng)前訂單表里已經(jīng)有2000萬(wàn)數(shù)據(jù)了，此時(shí)做了上述拆分，每個(gè)表里就只有400萬(wàn)數(shù)據(jù)了。

而且每天新增50萬(wàn)數(shù)據(jù)的話，那么每個(gè)表才新增10萬(wàn)數(shù)據(jù)，這樣是不是初步緩解了單表數(shù)據(jù)量過(guò)大影響系統(tǒng)性能的問(wèn)題？

另外就是每秒1萬(wàn)請(qǐng)求到5臺(tái)數(shù)據(jù)庫(kù)上，每臺(tái)數(shù)據(jù)庫(kù)就承載每秒2000的請(qǐng)求，是不是一下子把每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的并發(fā)請(qǐng)求降低到了安全范圍內(nèi)？

這樣，降低了數(shù)據(jù)庫(kù)的高峰期負(fù)載，同時(shí)還保證了高峰期的性能。

三、大量分表來(lái)保證海量數(shù)據(jù)下的查詢性能

但是上述的數(shù)據(jù)庫(kù)架構(gòu)還有一個(gè)問(wèn)題，那就是單表數(shù)據(jù)量還是過(guò)大，現(xiàn)在訂單表才分為了5張表，那么如果訂單一年有1億條，每個(gè)表就有2000萬(wàn)條，這也還是太大了。

?所以還應(yīng)該繼續(xù)分表，大量分表。

比如可以把訂單表一共拆分為1024張表，這樣1億數(shù)據(jù)量的話，分散到每個(gè)表里也就才10萬(wàn)量級(jí)的數(shù)據(jù)量，然后這上千張表分散在5臺(tái)數(shù)據(jù)庫(kù)里就可以了。

在寫(xiě)入數(shù)據(jù)的時(shí)候，需要做兩次路由，先對(duì)訂單id hash后對(duì)數(shù)據(jù)庫(kù)的數(shù)量取模，可以路由到一臺(tái)數(shù)據(jù)庫(kù)上，然后再對(duì)那臺(tái)數(shù)據(jù)庫(kù)上的表數(shù)量取模，就可以路由到數(shù)據(jù)庫(kù)上的一個(gè)表里了。?

通過(guò)這個(gè)步驟，就可以讓每個(gè)表里的數(shù)據(jù)量非常小，每年1億數(shù)據(jù)增長(zhǎng)，但是到每個(gè)表里才10萬(wàn)條數(shù)據(jù)增長(zhǎng)，這個(gè)系統(tǒng)運(yùn)行10年，每個(gè)表里可能才百萬(wàn)級(jí)的數(shù)據(jù)量。

這樣可以一次性為系統(tǒng)未來(lái)的運(yùn)行做好充足的準(zhǔn)備，看下面的圖，一起來(lái)感受一下：

四、讀寫(xiě)分離來(lái)支撐按需擴(kuò)容以及性能提升

這個(gè)時(shí)候整體效果已經(jīng)挺不錯(cuò)了，大量分表的策略保證可能未來(lái)10年，每個(gè)表的數(shù)據(jù)量都不會(huì)太大，這可以保證單表內(nèi)的SQL執(zhí)行效率和性能。

然后多臺(tái)數(shù)據(jù)庫(kù)的拆分方式，可以保證每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器承載一部分的讀寫(xiě)請(qǐng)求，降低每臺(tái)服務(wù)器的負(fù)載。

但是此時(shí)還有一個(gè)問(wèn)題，假如說(shuō)每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器承載每秒2000的請(qǐng)求，然后其中400請(qǐng)求是寫(xiě)入，1600請(qǐng)求是查詢。

也就是說(shuō)，增刪改的SQL才占到了20%的比例，80%的請(qǐng)求是查詢。

此時(shí)假如說(shuō)隨著用戶量越來(lái)越大，假如說(shuō)又變成每臺(tái)服務(wù)器承載4000請(qǐng)求了。

那么其中800請(qǐng)求是寫(xiě)入，3200請(qǐng)求是查詢，如果說(shuō)你按照目前的情況來(lái)擴(kuò)容，就需要增加一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器.

但是此時(shí)可能就會(huì)涉及到表的遷移，因?yàn)樾枰w移一部分表到新的數(shù)據(jù)庫(kù)服務(wù)器上去，是不是很麻煩？

其實(shí)完全沒(méi)必要，數(shù)據(jù)庫(kù)一般都支持讀寫(xiě)分離，也就是做主從架構(gòu)。

寫(xiě)入的時(shí)候?qū)懭胫鲾?shù)據(jù)庫(kù)服務(wù)器，查詢的時(shí)候讀取從數(shù)據(jù)庫(kù)服務(wù)器，就可以讓一個(gè)表的讀寫(xiě)請(qǐng)求分開(kāi)落地到不同的數(shù)據(jù)庫(kù)上去執(zhí)行。

這樣的話，假如寫(xiě)入主庫(kù)的請(qǐng)求是每秒400，查詢從庫(kù)的請(qǐng)求是每秒1600，那么圖大概如下所示。

寫(xiě)入主庫(kù)的時(shí)候，會(huì)自動(dòng)同步數(shù)據(jù)到從庫(kù)上去，保證主庫(kù)和從庫(kù)數(shù)據(jù)一致。

然后查詢的時(shí)候都是走從庫(kù)去查詢的，這就通過(guò)數(shù)據(jù)庫(kù)的主從架構(gòu)實(shí)現(xiàn)了讀寫(xiě)分離的效果了。

現(xiàn)在的好處就是，假如說(shuō)現(xiàn)在主庫(kù)寫(xiě)請(qǐng)求增加到800，這個(gè)無(wú)所謂，不需要擴(kuò)容。然后從庫(kù)的讀請(qǐng)求增加到了3200，需要擴(kuò)容了。

這時(shí)，你直接給主庫(kù)再掛載一個(gè)新的從庫(kù)就可以了，兩個(gè)從庫(kù)，每個(gè)從庫(kù)支撐1600的讀請(qǐng)求，不需要因?yàn)樽x請(qǐng)求增長(zhǎng)來(lái)擴(kuò)容主庫(kù)。

實(shí)際上線上生產(chǎn)你會(huì)發(fā)現(xiàn)，讀請(qǐng)求的增長(zhǎng)速度遠(yuǎn)遠(yuǎn)高于寫(xiě)請(qǐng)求，所以讀寫(xiě)分離之后，大部分時(shí)候就是擴(kuò)容從庫(kù)支撐更高的讀請(qǐng)求就可以了。

而且另外一點(diǎn)，對(duì)同一個(gè)表，如果你既寫(xiě)入數(shù)據(jù)（涉及加鎖），還從該表查詢數(shù)據(jù)，可能會(huì)牽扯到鎖沖突等問(wèn)題，無(wú)論是寫(xiě)性能還是讀性能，都會(huì)有影響。

所以一旦讀寫(xiě)分離之后，對(duì)主庫(kù)的表就僅僅是寫(xiě)入，沒(méi)任何查詢會(huì)影響他，對(duì)從庫(kù)的表就僅僅是查詢。

五、高并發(fā)下的數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)總結(jié)

其實(shí)從大的一個(gè)簡(jiǎn)化的角度來(lái)說(shuō)，高并發(fā)的場(chǎng)景下，數(shù)據(jù)庫(kù)層面的架構(gòu)肯定是需要經(jīng)過(guò)精心的設(shè)計(jì)的。

尤其是涉及到分庫(kù)來(lái)支撐高并發(fā)的請(qǐng)求，大量分表保證每個(gè)表的數(shù)據(jù)量別太大，讀寫(xiě)分離實(shí)現(xiàn)主庫(kù)和從庫(kù)按需擴(kuò)容以及性能保證。

這篇文章就是從一個(gè)大的角度來(lái)梳理了一下思路，各位同學(xué)可以結(jié)合自己公司的業(yè)務(wù)和項(xiàng)目來(lái)考慮自己的系統(tǒng)如何做分庫(kù)分表應(yīng)該怎么做。

另外就是，具體的分庫(kù)分表落地的時(shí)候，需要借助數(shù)據(jù)庫(kù)中間件來(lái)實(shí)現(xiàn)分庫(kù)分表和讀寫(xiě)分離，大家可以自己參考 sharding-jdbc 或者 mycat 的官網(wǎng)即可，里面的文檔都有詳細(xì)的使用描述。