????????今天給大家分享一個(gè)知識(shí)點(diǎn)，是關(guān)于MySQL數(shù)據(jù)庫架構(gòu)演進(jìn)的，因?yàn)楹芏嘈值芴焯旎趍ysql做系統(tǒng)開發(fā)，但是寫的系統(tǒng)都是那種低并發(fā)壓力、小數(shù)據(jù)量的，所以哪怕上線了也就是這么正常跑著而已，但是你知道你連接的這個(gè)MySQL數(shù)據(jù)庫他到底能抗多大并發(fā)壓力嗎？如果MySQL數(shù)據(jù)庫扛不住壓力了，應(yīng)該如何演進(jìn)你知道嗎？
目錄
一般業(yè)務(wù)系統(tǒng)運(yùn)行流程圖
一臺(tái)4核8G的機(jī)器能扛多少并發(fā)量呢？
?高并發(fā)來襲時(shí)數(shù)據(jù)庫會(huì)先被打死嗎？
8核16G的數(shù)據(jù)庫每秒大概可以抗多少并發(fā)壓力？
數(shù)據(jù)庫架構(gòu)可以從哪些方面優(yōu)化？
1.根據(jù)業(yè)務(wù)系統(tǒng)拆分多個(gè)數(shù)據(jù)庫機(jī)器優(yōu)化方案
2. 讀寫分離架構(gòu)優(yōu)化方案
3、分庫分表架構(gòu)優(yōu)化方案
總結(jié)優(yōu)化
真實(shí)環(huán)境問題
30萬用戶的web系統(tǒng)，單臺(tái)mysql服務(wù)器可以扛住嗎？
qps是什么？
一，分析
二，qps計(jì)算
三，總結(jié)
一般業(yè)務(wù)系統(tǒng)運(yùn)行流程圖
????????首先，我們先來看一個(gè)最最基礎(chǔ)的java業(yè)務(wù)系統(tǒng)連接數(shù)據(jù)庫運(yùn)行的架構(gòu)，其實(shí)簡(jiǎn)單來說，我們平時(shí)都是用spring boot+ssm技術(shù)棧開發(fā)一個(gè)java業(yè)務(wù)系統(tǒng)的，用spring boot內(nèi)嵌tomcat就可以對(duì)外提供http接口了，然后最多現(xiàn)在會(huì)加上nacos+dubbo調(diào)用別的系統(tǒng)接口，數(shù)據(jù)全部靠連接mysql數(shù)據(jù)庫進(jìn)行crud就可以了，如下圖。
????????上面那種架構(gòu)的系統(tǒng)，估計(jì)就是很多兄弟日常做的最多的系統(tǒng)架構(gòu)了，有的兄弟稍微做的高大上一點(diǎn)，大概來說，可能就是會(huì)加入一些es、redis、rocketmq一類的中間件簡(jiǎn)單使用一下，但是大致來說也就這么回事了，那么還是回歸主題，大家知道你上述那種系統(tǒng)下，他連接的數(shù)據(jù)庫能抗多大壓力嗎？
一臺(tái)4核8G的機(jī)器能扛多少并發(fā)量呢？
????????說實(shí)話，要解決這個(gè)問題，一般來說，不是先聊數(shù)據(jù)能抗多少壓力，因?yàn)橥皇菙?shù)據(jù)庫先去抗高并發(fā)，而是你連接數(shù)據(jù)庫的web系統(tǒng)得先去抗高并發(fā)！也就是我們的spring boot+ssm那套業(yè)務(wù)系統(tǒng)能抗多高并發(fā)我們得先搞清楚！
????????所以要搞明白這個(gè)問題，就得先說一個(gè)主題，一般來說我們的spring boot應(yīng)用系統(tǒng)大致就是部署在2核4G或者4核8G的機(jī)器上，這個(gè)機(jī)器配置其實(shí)是很關(guān)鍵的，所以這里直接告訴大家一個(gè)經(jīng)驗(yàn)值，即使說咱們?nèi)绻渴鸬氖且粋€(gè)4核8G的機(jī)器，然后spring boot內(nèi)嵌的tomcat默認(rèn)開了200個(gè)線程來處理請(qǐng)求，接著每個(gè)請(qǐng)求都要讀寫多次數(shù)據(jù)庫，那么此時(shí)，大致來說你的一臺(tái)機(jī)器可以抗大概500~1000這個(gè)并發(fā)量，具體多少得看你的接口復(fù)雜度，如下圖。
?高并發(fā)來襲時(shí)數(shù)據(jù)庫會(huì)先被打死嗎？
????????所以其實(shí)一般來說，當(dāng)你的高并發(fā)壓力來襲的時(shí)候，通常不會(huì)是數(shù)據(jù)庫先扛不住了，而是你的業(yè)務(wù)系統(tǒng)所在機(jī)器抗不住了，比如你部署了2臺(tái)機(jī)器，那么其實(shí)到每秒一兩千并發(fā)的時(shí)候，這兩臺(tái)機(jī)器基本上cpu負(fù)載都得飆升到90%以上 ，壓力很大，而且接口性能會(huì)開始往下掉很多了，如下圖。
????????那么這個(gè)時(shí)候我們的數(shù)據(jù)庫壓力會(huì)如何呢？其實(shí)一般來說你的兩臺(tái)機(jī)器抗下每秒一兩千的請(qǐng)求的時(shí)候后，數(shù)據(jù)庫壓力通常也會(huì)到一個(gè)小瓶頸，因?yàn)闉槭裁茨兀筷P(guān)鍵是你的業(yè)務(wù)系統(tǒng)處理每個(gè)業(yè)務(wù)請(qǐng)求的時(shí)候，他是會(huì)讀寫多次數(shù)據(jù)庫的，所以業(yè)務(wù)系統(tǒng)的一次請(qǐng)求可能會(huì)導(dǎo)致數(shù)據(jù)庫有多次請(qǐng)求，也正因?yàn)檫@樣，所以此時(shí)可能你的數(shù)據(jù)庫并發(fā)壓力會(huì)到幾千的樣子。
8核16G的數(shù)據(jù)庫每秒大概可以抗多少并發(fā)壓力？
????????那么所以下一個(gè)問題來了，你的數(shù)據(jù)庫通常是部署在什么樣配置的機(jī)器上？一般來說給大家說，數(shù)據(jù)庫的配置如果是那種特別低并發(fā)的場(chǎng)景，其實(shí)2核4G或者4核8G也是夠了，但是如果是常規(guī)化一點(diǎn)的公司的生產(chǎn)環(huán)境數(shù)據(jù)庫，通常會(huì)是8核16G。那么8核16G的數(shù)據(jù)庫每秒大概可以抗多少并發(fā)壓力？大體上來說，在幾千這個(gè)數(shù)量級(jí)。
????????因?yàn)檫@個(gè)具體能抗多少并發(fā)也得看你數(shù)據(jù)庫里的數(shù)據(jù)量 以及你的SQL語句的復(fù)雜度，所以一般來說8核16G的機(jī)器，大概也就是抗到每秒幾千并發(fā)就差不多了，量再大基本就扛不住了，因?yàn)橥竭@個(gè)量級(jí)下，數(shù)據(jù)庫的cpu、內(nèi)存、網(wǎng)絡(luò)、io的負(fù)載基本都很高了，尤其是cpu，可能至少也在百分之七八十了，如下圖。
數(shù)據(jù)庫架構(gòu)可以從哪些方面優(yōu)化？
1.根據(jù)業(yè)務(wù)系統(tǒng)拆分多個(gè)數(shù)據(jù)庫機(jī)器優(yōu)化方案
????????那么接著說，如果到了這個(gè)并發(fā)壓力之下，通常來說可以如何進(jìn)行**數(shù)據(jù)庫架構(gòu)的優(yōu)化呢？**其實(shí)也簡(jiǎn)單，我們完全可以加機(jī)器，把數(shù)據(jù)庫部署到多臺(tái)機(jī)器上去。因?yàn)橥ǔ碚f，我們的一個(gè)數(shù)據(jù)庫里會(huì)放很多業(yè)務(wù)系統(tǒng)的db和tables，所以首先就是可以按照業(yè)務(wù)系統(tǒng)來進(jìn)行拆分，比如說多加一臺(tái)機(jī)器，再部署一個(gè)數(shù)據(jù)庫，然后這里放一部分業(yè)務(wù)系統(tǒng)的db和tables，老數(shù)據(jù)庫機(jī)器放另外一部分業(yè)務(wù)系統(tǒng)的db和tables，此時(shí)一下子就可以緩解老數(shù)據(jù)庫機(jī)器的壓力了，如下圖。
2. 讀寫分離架構(gòu)優(yōu)化方案
????????那么接著問題來了，如果說并發(fā)壓力繼續(xù)提升，導(dǎo)致拆分出去的兩臺(tái)數(shù)據(jù)庫壓力越來越大了呢？此時(shí)可以上一招，叫做讀寫分離，就是說給每個(gè)數(shù)據(jù)庫掛一個(gè)從庫，讓主數(shù)據(jù)庫基于binlog數(shù)據(jù)更新日志同步復(fù)制給從數(shù)據(jù)庫，讓主從數(shù)據(jù)庫保持?jǐn)?shù)據(jù)一致，然后我們的系統(tǒng)其實(shí)可以往主庫里寫入，在從庫里查詢，此時(shí)就又可以緩解原來的主數(shù)據(jù)庫的壓力了，如下圖。
3、分庫分表架構(gòu)優(yōu)化方案
再往下說，如果說即使是給主數(shù)據(jù)庫掛了從庫，然后接著并發(fā)壓力繼續(xù)提升，讓我們的主數(shù)據(jù)庫寫入壓力過大，每秒幾千寫入，又要扛不住了呢？此時(shí)就只能上終極方案，分庫分表了，就是把主庫拆分為多個(gè)庫，每個(gè)庫里放一個(gè)表的部分?jǐn)?shù)據(jù)，然后用多個(gè)主庫抗高并發(fā)寫入壓力，這樣就可以再次分散我們的壓力了，如下圖所示。
總結(jié)優(yōu)化
????????好了，今天分享的知識(shí)就到這里了，其實(shí)我們的數(shù)據(jù)庫架構(gòu)演進(jìn)基本上就是按照今天說的這個(gè)順序和思路逐步逐步的演進(jìn)的，剛開始你單臺(tái)數(shù)據(jù)庫機(jī)器抗幾千并發(fā)扛不住了，就按照業(yè)務(wù)系統(tǒng)拆分多個(gè)數(shù)據(jù)庫機(jī)器，然后再扛不住了，就上主從架構(gòu)分?jǐn)傋x寫壓力，再扛不住了就分庫分表，多個(gè)機(jī)器抗數(shù)據(jù)庫寫入壓力，最后總是可以用數(shù)據(jù)庫架構(gòu)抗住高并發(fā)壓力的。
真實(shí)環(huán)境問題
30萬用戶的web系統(tǒng)，單臺(tái)mysql服務(wù)器可以扛住嗎？
????????最近看了很多高可用，集群的方案，越看越頭疼?？春蟮母杏X就是，維護(hù)成本太大，對(duì)于我這種沒這方面經(jīng)驗(yàn)的新手，實(shí)在頭大。
????????實(shí)在不想弄那種集群，高可用的方案，什么分表，分庫，水平拆分，垂直拆分，什么mycat啥的，統(tǒng)統(tǒng)都不想弄。我技術(shù)水平駕馭不??！
????????服務(wù)器，32g-ddr3內(nèi)存，ssd-240g硬盤，cpu-xeon系列！
????????單mysql服務(wù)器，實(shí)在好控制，不用操心，不在自己技術(shù)范圍外的異常情況！
????????例如redis，我沒經(jīng)驗(yàn)，寫到是能寫出來，照葫蘆畫瓢，但是他有數(shù)據(jù)不一致的問題，需要額外處理，這個(gè)沒經(jīng)驗(yàn)，感覺還是駕馭不了。
????????主要是沒時(shí)間，去試錯(cuò)。
????????平均每天5萬條數(shù)據(jù)左右寫入，剩下的基本都是讀！
qps是什么？
????????QPS(Query Per Second)意思為“每秒查詢率”，是一臺(tái)服務(wù)器每秒能夠響應(yīng)的查詢次數(shù)，是對(duì)一個(gè)特定的查詢服務(wù)器在規(guī)定時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)。
一，分析
一般應(yīng)用來說，并發(fā)估算公式如下：
qps = 5 * 日pv / 86400
5是通用峰值倍數(shù)，如果你有高峰值特性自行調(diào)整，比如秒殺功能。
mysql通常在實(shí)體機(jī)的讀寫綜合qps在幾千左右，具體你可以自己壓測(cè)一下，跟機(jī)器配置有關(guān)。
所以首先你需要通過收集日志得到日pv，然后通過估算得到當(dāng)前qps，再根據(jù)未來一段時(shí)間的用戶量和場(chǎng)景看看夠不夠。
比如你每天數(shù)據(jù)庫訪問次數(shù)是100萬，可估算峰值qps為60左右，比如數(shù)據(jù)庫qps可達(dá)3000，那么可估算你的服務(wù)器還能撐同等場(chǎng)景50倍增長。
以上方法都是通用方法，杠精退散。
????????脫離具體方法來說，題主這種小型站點(diǎn)，我的建議是不要聽某些人說的用什么牛逼方案，用最成熟的通用方案就對(duì)了，有問題方便解決，以后也便于別人接盤。
切忌過度優(yōu)化，互聯(lián)網(wǎng)老兵給你的成熟建議。
????????根據(jù)全日的qps計(jì)算，該用戶一天大概只能5萬的寫入量，如果是平均的話每兩秒只有一次寫入，qps只有0.5左右，當(dāng)前服務(wù)器綽綽有余的就可以接盤，如果是在同一個(gè)時(shí)間段有上萬數(shù)據(jù)同時(shí)涌入的話，數(shù)據(jù)庫會(huì)到達(dá)一個(gè)瓶頸，有可能會(huì)出現(xiàn)崩潰的情況，但是如果這么高的并發(fā)的話，大可能是前面web端的服務(wù)器先支撐不住。
二，qps計(jì)算
業(yè)務(wù)qps的估算一般按照?qǐng)鼍皝韯澐郑U述下常見場(chǎng)景的估算方法：
1、搶購和活動(dòng)場(chǎng)景
按照80%的訪問量集中在20%的時(shí)間內(nèi)
qps=pv*80%/86400*20%
2、白天提供業(yè)務(wù)的場(chǎng)景（例如政務(wù)查詢系統(tǒng)等）
按照一半時(shí)間去計(jì)算4w秒
qps=pv/40000
3、全天后無明顯波峰場(chǎng)景
qps=pv/86400
至于mysql的性能直接測(cè)試一下，不同機(jī)器配置差異太大，一般qps幾k沒有問題
附帶建議：不要只一臺(tái)服務(wù)，怎么也搞個(gè)主從，只為少些晚上被叫起來搞事情?
三，總結(jié)
1、通常情況下，線上環(huán)境應(yīng)用部署在4核8G的機(jī)器上，而數(shù)據(jù)庫應(yīng)部署在8核16G或者16核32G，正常情況下單節(jié)點(diǎn)應(yīng)用服務(wù)可支撐500左右的并發(fā)，當(dāng)然還要根據(jù)請(qǐng)求的處理時(shí)長來計(jì)算，比如接口請(qǐng)求響應(yīng)過慢就會(huì)導(dǎo)致并發(fā)降低
2、在一個(gè)系統(tǒng)中，往往壓力會(huì)集中在數(shù)據(jù)庫上，因?yàn)檎?qǐng)求一般最終會(huì)落到數(shù)據(jù)庫上，而數(shù)據(jù)庫需要在內(nèi)存以及磁盤上進(jìn)行大量的IO操作。一般來說8核16G的機(jī)器部署mysql數(shù)據(jù)庫可以扛住一兩千的并發(fā)，如果并發(fā)量再高些比如幾千，就會(huì)造成數(shù)據(jù)庫CPU、磁盤、IO、內(nèi)存等負(fù)載過高，嚴(yán)重會(huì)引起宕機(jī)
3、16核32G的機(jī)器，一般可以扛住兩三千的并發(fā)、甚至到三四千也都可以，具體還是有要看sql的復(fù)雜度等，對(duì)于數(shù)據(jù)庫而已，一般采用的SSD固態(tài)硬盤，因?yàn)閿?shù)據(jù)操作需要大量的磁盤IO，SSD的IO會(huì)相對(duì)大很多。?
參考文章
天天用MySQL開發(fā)，你知道數(shù)據(jù)庫能抗多大并發(fā)壓力嗎？ - 掘金 (juejin.cn)?文章來源：http://www.zghlxwxcb.cn/news/detail-485458.html
(1 封私信) 30萬用戶的web系統(tǒng)，單臺(tái)mysql服務(wù)器可以扛住嗎？ - 知乎 (zhihu.com)文章來源地址http://www.zghlxwxcb.cn/news/detail-485458.html
到了這里，關(guān)于天天使用MySQL，你知道MySQL數(shù)據(jù)庫能抗多少壓力嗎？附（真實(shí)案例）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
