今天給大家分享一個知識點，是關于MySQL數(shù)據(jù)庫架構(gòu)演進的，因為很多兄弟天天基于mysql做系統(tǒng)開發(fā)，但是寫的系統(tǒng)都是那種低并發(fā)壓力、小數(shù)據(jù)量的，所以哪怕上線了也就是這么正常跑著而已，但是你知道你連接的這個MySQL數(shù)據(jù)庫他到底能抗多大并發(fā)壓力嗎?如果MySQL數(shù)據(jù)庫扛不住壓力了，應該如何演進你知道嗎?

一般業(yè)務系統(tǒng)運行流程圖

首先，我們先來看一個最最基礎的java業(yè)務系統(tǒng)連接數(shù)據(jù)庫運行的架構(gòu)，其實簡單來說，我們平時都是用spring boot+ssm技術(shù)棧開發(fā)一個java業(yè)務系統(tǒng)的，用spring boot內(nèi)嵌tomcat就可以對外提供http接口了，然后最多現(xiàn)在會加上nacos+dubbo調(diào)用別的系統(tǒng)接口，數(shù)據(jù)全部靠連接mysql數(shù)據(jù)庫進行crud就可以了，如下圖。

上面那種架構(gòu)的系統(tǒng)，估計就是很多兄弟日常做的最多的系統(tǒng)架構(gòu)了，有的兄弟稍微做的高大上一點，大概來說，可能就是會加入一些es、redis、rocketmq一類的中間件簡單使用一下，但是大致來說也就這么回事了，那么還是回歸主題，大家知道你上述那種系統(tǒng)下，他連接的數(shù)據(jù)庫能抗多大壓力嗎?

一臺4核8G的機器能扛多少并發(fā)量呢?

說實話，要解決這個問題，一般來說，不是先聊數(shù)據(jù)能抗多少壓力，因為往往不是數(shù)據(jù)庫先去抗高并發(fā)，而是你連接數(shù)據(jù)庫的web系統(tǒng)得先去抗高并發(fā)!也就是我們的spring boot+ssm那套業(yè)務系統(tǒng)能抗多高并發(fā)我們得先搞清楚!

所以要搞明白這個問題，就得先說一個主題，一般來說我們的spring boot應用系統(tǒng)大致就是部署在2核4G或者4核8G的機器上，這個機器配置其實是很關鍵的，所以這里直接告訴大家一個經(jīng)驗值，即使說咱們?nèi)绻渴鸬氖且粋€4核8G的機器，然后spring boot內(nèi)嵌的tomcat默認開了200個線程來處理請求，接著每個請求都要讀寫多次數(shù)據(jù)庫，那么此時，大致來說你的一臺機器可以抗大概500~1000這個并發(fā)量，具體多少得看你的接口復雜度，如下圖。

高并發(fā)來襲時數(shù)據(jù)庫會先被打死嗎?

所以其實一般來說，當你的高并發(fā)壓力來襲的時候，通常不會是數(shù)據(jù)庫先扛不住了，而是你的業(yè)務系統(tǒng)所在機器抗不住了，比如你部署了2臺機器，那么其實到每秒一兩千并發(fā)的時候，這兩臺機器基本上cpu負載都得飆升到90%以上 ，壓力很大，而且接口性能會開始往下掉很多了，如下圖。

那么這個時候我們的數(shù)據(jù)庫壓力會如何呢?其實一般來說你的兩臺機器抗下每秒一兩千的請求的時候后，數(shù)據(jù)庫壓力通常也會到一個小瓶頸，因為為什么呢?關鍵是你的業(yè)務系統(tǒng)處理每個業(yè)務請求的時候，他是會讀寫多次數(shù)據(jù)庫的，所以業(yè)務系統(tǒng)的一次請求可能會導致數(shù)據(jù)庫有多次請求，也正因為這樣，所以此時可能你的數(shù)據(jù)庫并發(fā)壓力會到幾千的樣子。

8核16G的數(shù)據(jù)庫每秒大概可以抗多少并發(fā)壓力?

那么所以下一個問題來了，你的數(shù)據(jù)庫通常是部署在什么樣配置的機器上?一般來說給大家說，數(shù)據(jù)庫的配置如果是那種特別低并發(fā)的場景，其實2核4G或者4核8G也是夠了，但是如果是常規(guī)化一點的公司的生產(chǎn)環(huán)境數(shù)據(jù)庫，通常會是8核16G。那么8核16G的數(shù)據(jù)庫每秒大概可以抗多少并發(fā)壓力?大體上來說，在幾千這個數(shù)量級。

因為這個具體能抗多少并發(fā)也得看你數(shù)據(jù)庫里的數(shù)據(jù)量 以及你的SQL語句的復雜度，所以一般來說8核16G的機器，大概也就是抗到每秒幾千并發(fā)就差不多了，量再大基本就扛不住了，因為往往到這個量級下，數(shù)據(jù)庫的cpu、內(nèi)存、網(wǎng)絡、io的負載基本都很高了，尤其是cpu，可能至少也在百分之七八十了，如下圖。

數(shù)據(jù)庫架構(gòu)可以從哪些方面優(yōu)化?

1、根據(jù)業(yè)務系統(tǒng)拆分多個數(shù)據(jù)庫機器優(yōu)化方案

那么接著說，如果到了這個并發(fā)壓力之下，通常來說可以如何進行數(shù)據(jù)庫架構(gòu)的優(yōu)化呢?其實也簡單，我們完全可以加機器，把數(shù)據(jù)庫部署到多臺機器上去。因為通常來說，我們的一個數(shù)據(jù)庫里會放很多業(yè)務系統(tǒng)的db和tables，所以首先就是可以按照業(yè)務系統(tǒng)來進行拆分，比如說多加一臺機器，再部署一個數(shù)據(jù)庫，然后這里放一部分業(yè)務系統(tǒng)的db和tables，老數(shù)據(jù)庫機器放另外一部分業(yè)務系統(tǒng)的db和tables，此時一下子就可以緩解老數(shù)據(jù)庫機器的壓力了，如下圖。

2、讀寫分離架構(gòu)優(yōu)化方案

那么接著問題來了，如果說并發(fā)壓力繼續(xù)提升，導致拆分出去的兩臺數(shù)據(jù)庫壓力越來越大了呢?此時可以上一招，叫做讀寫分離，就是說給每個數(shù)據(jù)庫掛一個從庫，讓主數(shù)據(jù)庫基于binlog數(shù)據(jù)更新日志同步復制給從數(shù)據(jù)庫，讓主從數(shù)據(jù)庫保持數(shù)據(jù)一致，然后我們的系統(tǒng)其實可以往主庫里寫入，在從庫里查詢，此時就又可以緩解原來的主數(shù)據(jù)庫的壓力了，如下圖。

3、分庫分表架構(gòu)優(yōu)化方案

再往下說，如果說即使是給主數(shù)據(jù)庫掛了從庫，然后接著并發(fā)壓力繼續(xù)提升，讓我們的主數(shù)據(jù)庫寫入壓力過大，每秒幾千寫入，又要扛不住了呢?此時就只能上終極方案，分庫分表了，就是把主庫拆分為多個庫，每個庫里放一個表的部分數(shù)據(jù)，然后用多個主庫抗高并發(fā)寫入壓力，這樣就可以再次分散我們的壓力了，如下圖所示。

總結(jié)

好了，今天分享的知識就到這里了，其實我們的數(shù)據(jù)庫架構(gòu)演進基本上就是按照今天說的這個順序和思路逐步逐步的演進的，剛開始你單臺數(shù)據(jù)庫機器抗幾千并發(fā)扛不住了，就按照業(yè)務系統(tǒng)拆分多個數(shù)據(jù)庫機器，然后再扛不住了，就上主從架構(gòu)分攤讀寫壓力，再扛不住了就分庫分表，多個機器抗數(shù)據(jù)庫寫入壓力，最后總是可以用數(shù)據(jù)庫架構(gòu)抗住高并發(fā) 壓力的。