歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

精品學習資料獲取通道，參見文末

（1）用一個創業公司的發展作為背景引入

假如我們現在是一個小創業公司，註冊使用者就20萬，每天活躍使用者就1萬，每天單表資料量就1000，然後高峰期每秒鐘併發請求最多就10。

天哪！就這種系統，隨便找一個有幾年工作經驗的高階工程師，然後帶幾個年輕工程師，隨便乾乾都可以做出來。

因為這樣的系統，實際上主要就是在前期快速的進行業務功能的開發，搞一個單塊系統部署在一臺伺服器上，然後連線一個資料庫就可以了。

接著大家就是不停的在一個工程裡填充進去各種業務程式碼，儘快把公司的業務支撐起來，如下圖所示。

結果呢，沒想到我們運氣這麼好，碰上個優秀的CEO帶著我們走上了康莊大道！

公司業務發展迅猛，過了幾個月，註冊使用者數達到了2000萬！每天活躍使用者數100萬！每天單表新增資料量達到50萬條！高峰期每秒請求量達到1萬！

同時公司還順帶著融資了兩輪，估值達到了驚人的幾億美金！一隻朝氣蓬勃的幼年獨角獸的節奏！

好吧，現在大家感覺壓力已經有點大了，為啥呢？

因為每天單表新增50萬條資料，一個月就多1500萬條資料，一年下來單表會達到上億條資料。

經過一段時間的執行，現在我們們單表已經兩三千萬條資料了，勉強還能支撐著。

但是，眼見著系統訪問資料庫的效能怎麼越來越差呢，單表資料量越來越大，拖垮了一些複雜查詢SQL的效能啊！

然後高峰期請求現在是每秒1萬，我們們的系統線上上部署了20臺機器，平均每臺機器每秒支撐500請求，這個還能抗住，沒啥大問題。

但是資料庫層面呢？

如果說此時你還是一臺資料庫伺服器在支撐每秒上萬的請求，負責任的告訴你，每次高峰期會出現下述問題：

你的資料庫伺服器的磁碟IO、網路頻寬、CPU負載、記憶體消耗，都會達到非常高的情況，資料庫所在伺服器的整體負載會非常重，甚至都快不堪重負了

高峰期時，本來你單表資料量就很大，SQL效能就不太好，這時加上你的資料庫伺服器負載太高導致效能下降，就會發現你的SQL效能更差了

最明顯的一個感覺，就是你的系統在高峰期各個功能都執行的很慢，使用者體驗很差，點一個按鈕可能要幾十秒才出來結果

如果你運氣不太好，資料庫伺服器的配置不是特別的高的話，弄不好你還會經歷資料庫當機的情況，因為負載太高對資料庫壓力太大了

（2）多臺伺服器分庫支撐高併發讀寫

首先我們先考慮第一個問題，資料庫每秒上萬的併發請求應該如何來支撐呢？

要搞清楚這個問題，先得明白一般資料庫部署在什麼配置的伺服器上。

通常來說，假如你用普通配置的伺服器來部署資料庫，那也起碼是16核32G的機器配置。

這種非常普通的機器配置部署的資料庫，一般線上的經驗是：不要讓其每秒請求支撐超過2000，一般控制在2000左右。

控制在這個程度，一般資料庫負載相對合理，不會帶來太大的壓力，沒有太大的當機風險。

所以首先第一步，就是在上萬併發請求的場景下，部署個5臺伺服器，每臺伺服器上都部署一個資料庫例項。

然後每個資料庫例項裡，都建立一個一樣的庫，比如說訂單庫。

此時在5臺伺服器上都有一個訂單庫，名字可以類似為：db_order_01，db_order_02，等等。

然後每個訂單庫裡，都有一個相同的表，比如說訂單庫裡有訂單資訊表，那麼此時5個訂單庫裡都有一個訂單資訊表。

比如db_order_01庫裡就有一個tb_order_01表，db_order_02庫裡就有一個tb_order_02表。

這就實現了一個基本的分庫分表的思路，原來的一臺資料庫伺服器變成了5臺資料庫伺服器，原來的一個庫變成了5個庫，原來的一張表變成了5個表。

然後你在寫入資料的時候，需要藉助資料庫中介軟體，比如sharding-jdbc，或者是mycat，都可以。

你可以根據比如訂單id來hash後按5取模，比如每天訂單表新增50萬資料，此時其中10萬條資料會落入db_order_01庫的tb_order_01表，另外10萬條資料會落入db_order_02庫的tb_order_02表，以此類推。

這樣就可以把資料均勻分散在5臺伺服器上了，查詢的時候，也可以通過訂單id來hash取模，去對應的伺服器上的資料庫裡，從對應的表裡查詢那條資料出來即可。

依據這個思路畫出的圖如下所示，大家可以看看。

做這一步有什麼好處呢？

第一個好處，原來比如訂單表就一張表，這個時候不就成了5張表了麼，那麼每個表的資料就變成1/5了。

假設訂單表一年有1億條資料，此時5張表裡每張表一年就2000萬資料了。

那麼假設當前訂單表裡已經有2000萬資料了，此時做了上述拆分，每個表裡就只有400萬資料了。

而且每天新增50萬資料的話，那麼每個表才新增10萬資料，這樣是不是初步緩解了單表資料量過大影響系統效能的問題？

另外就是每秒1萬請求到5臺資料庫上，每臺資料庫就承載每秒2000的請求，是不是一下子把每臺資料庫伺服器的併發請求降低到了安全範圍內？

這樣，降低了資料庫的高峰期負載，同時還保證了高峰期的效能。

（3）大量分表來保證海量資料下的查詢效能

但是上述的資料庫架構還有一個問題，那就是單表資料量還是過大，現在訂單表才分為了5張表，那麼如果訂單一年有1億條，每個表就有2000萬條，這也還是太大了。

所以還應該繼續分表，大量分表。

比如可以把訂單表一共拆分為1024張表，這樣1億資料量的話，分散到每個表裡也就才10萬量級的資料量，然後這上千張表分散在5臺資料庫裡就可以了。

在寫入資料的時候，需要做兩次路由，先對訂單id hash後對資料庫的數量取模，可以路由到一臺資料庫上，然後再對那臺資料庫上的表數量取模，就可以路由到資料庫上的一個表裡了。

通過這個步驟，就可以讓每個表裡的資料量非常小，每年1億資料增長，但是到每個表裡才10萬條資料增長，這個系統執行10年，每個表裡可能才百萬級的資料量。

這樣可以一次性為系統未來的執行做好充足的準備，看下面的圖，一起來感受一下：

（4）讀寫分離來支撐按需擴容以及效能提升

這個時候整體效果已經挺不錯了，大量分表的策略保證可能未來10年，每個表的資料量都不會太大，這可以保證單表內的SQL執行效率和效能。

然後多臺資料庫的拆分方式，可以保證每臺資料庫伺服器承載一部分的讀寫請求，降低每臺伺服器的負載。

但是此時還有一個問題，假如說每臺資料庫伺服器承載每秒2000的請求，然後其中400請求是寫入，1600請求是查詢。

也就是說，增刪改的SQL才佔到了20%的比例，80%的請求是查詢。

此時假如說隨著使用者量越來越大，假如說又變成每臺伺服器承載4000請求了。

那麼其中800請求是寫入，3200請求是查詢，如果說你按照目前的情況來擴容，就需要增加一臺資料庫伺服器.

但是此時可能就會涉及到表的遷移，因為需要遷移一部分表到新的資料庫伺服器上去，是不是很麻煩？

其實完全沒必要，資料庫一般都支援讀寫分離，也就是做主從架構。

寫入的時候寫入主資料庫伺服器，查詢的時候讀取從資料庫伺服器，就可以讓一個表的讀寫請求分開落地到不同的資料庫上去執行。

這樣的話，假如寫入主庫的請求是每秒400，查詢從庫的請求是每秒1600，那麼圖大概如下所示。

寫入主庫的時候，會自動同步資料到從庫上去，保證主庫和從庫資料一致。

然後查詢的時候都是走從庫去查詢的，這就通過資料庫的主從架構實現了讀寫分離的效果了。

現在的好處就是，假如說現在主庫寫請求增加到800，這個無所謂，不需要擴容。然後從庫的讀請求增加到了3200，需要擴容了。

這時，你直接給主庫再掛載一個新的從庫就可以了，兩個從庫，每個從庫支撐1600的讀請求，不需要因為讀請求增長來擴容主庫。

實際上線上生產你會發現，讀請求的增長速度遠遠高於寫請求，所以讀寫分離之後，大部分時候就是擴容從庫支撐更高的讀請求就可以了。

而且另外一點，對同一個表，如果你既寫入資料（涉及加鎖），還從該表查詢資料，可能會牽扯到鎖衝突等問題，無論是寫效能還是讀效能，都會有影響。

所以一旦讀寫分離之後，對主庫的表就僅僅是寫入，沒任何查詢會影響他，對從庫的表就僅僅是查詢。

（5）高併發下的資料庫架構設計總結

其實從大的一個簡化的角度來說，高併發的場景下，資料庫層面的架構肯定是需要經過精心的設計的。

尤其是涉及到分庫來支撐高併發的請求，大量分表保證每個表的資料量別太大，讀寫分離實現主庫和從庫按需擴容以及效能保證。

這篇文章就是從一個大的角度來梳理了一下思路，各位同學可以結合自己公司的業務和專案來考慮自己的系統如何做分庫分表應該怎麼做。

另外就是，具體的分庫分表落地的時候，需要藉助資料庫中介軟體來實現分庫分表和讀寫分離，大家可以自己參考 sharding-jdbc 或者 mycat 的官網即可，裡面的文件都有詳細的使用描述。

（封面圖源網路，侵權刪除）

END

掃描下方二維碼，備註：“資料”，獲取更多“祕製” 精品學習資料

如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！

一大波微服務、分散式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

支撐日活百萬使用者的高併發系統，應該如何設計其資料庫架構？【石杉的架構筆記】

目錄：

（1）用一個創業公司的發展作為背景引入

（2）多臺伺服器分庫支撐高併發讀寫

（3）大量分表來保證海量資料下的查詢效能

（4）讀寫分離來支撐按需擴容以及效能提升

（5）高併發下的資料庫架構設計總結

END

相關文章