關(guān)于數(shù)據(jù)庫(kù)性能的故事

面試時(shí)多多少少會(huì)講到數(shù)據(jù)庫(kù)上的事情，“你對(duì)數(shù)據(jù)庫(kù)的掌握如何？”，什么時(shí)候最考驗(yàn)數(shù)據(jù)庫(kù)的性能，答應(yīng)主要方面上講就是大數(shù)據(jù)量的讀寫(xiě)時(shí)，而電商類(lèi)的大促活動(dòng)就是考驗(yàn)各自的數(shù)據(jù)庫(kù)性能的時(shí)候啦。

對(duì)于web服務(wù)器而言，數(shù)據(jù)量大時(shí)，我們可以簡(jiǎn)單的通過(guò)橫向擴(kuò)展來(lái)減少單個(gè)服務(wù)器的負(fù)擔(dān)，但是對(duì)于數(shù)據(jù)庫(kù)服務(wù)器來(lái)說(shuō)就沒(méi)有那么簡(jiǎn)單了，他們不可能做到輕易的橫向擴(kuò)展，這樣也違背了數(shù)據(jù)庫(kù)的完整性與一致性的原則，那么我們的數(shù)據(jù)庫(kù)架構(gòu)該如何搭建呢？

對(duì)于大促類(lèi)活動(dòng)而言，不管是產(chǎn)品多好、策劃多成功，如果沒(méi)有穩(wěn)定的數(shù)據(jù)庫(kù)及服務(wù)器環(huán)境，則這所謂的一切都將是一場(chǎng)空呀。

數(shù)據(jù)庫(kù)架構(gòu)案例

如圖所示，主從服務(wù)器之間沒(méi)有任何主從復(fù)制組件，即當(dāng)主服務(wù)器出現(xiàn)了故障，很難進(jìn)行主服務(wù)器的切換，這需要DBA在從服務(wù)器中選擇數(shù)據(jù)最新的從服務(wù)器將其提升為主服務(wù)器并同步其他從服務(wù)器，這個(gè)過(guò)程的時(shí)間成本也是非常沉重的。

且過(guò)多的從服務(wù)器，當(dāng)業(yè)務(wù)量大時(shí)對(duì)主服務(wù)器的網(wǎng)卡也是一定的挑戰(zhàn)。

我們可以通過(guò)對(duì)集群的監(jiān)控信息來(lái)了解是什么影響了數(shù)據(jù)庫(kù)性能。

答應(yīng)其實(shí)是肯定的，一般情況下主要是QPS與TPS、并發(fā)量（同一時(shí)間處理的請(qǐng)求的數(shù)量，避免和同時(shí)連接數(shù)混淆）、磁盤(pán)IO、讀操作過(guò)于高

這里有個(gè)建議：最好不要在主庫(kù)上數(shù)據(jù)備份，起碼在大型活動(dòng)前要取消這類(lèi)計(jì)劃、

影響數(shù)據(jù)庫(kù)的因素

• sql查詢(xún)速度
• 服務(wù)器硬件
• 網(wǎng)卡流量
• 磁盤(pán)IO

超高的QPS和TPS

風(fēng)險(xiǎn)：效率底下的SQL(QPS：每秒鐘處理的查詢(xún)量)

大量的并發(fā)和超高的CPU使用率

風(fēng)險(xiǎn)：大量的并發(fā)（數(shù)據(jù)庫(kù)連接數(shù)被占滿(mǎn)（max_connections默認(rèn)100））

風(fēng)險(xiǎn)：超高的CPU使用率（因CPU資源耗盡而出現(xiàn)宕機(jī)）

磁盤(pán)IO

風(fēng)險(xiǎn)：磁盤(pán)IO性能突然下降（使用更快的磁盤(pán)設(shè)備）

風(fēng)險(xiǎn)：其他大量消耗磁盤(pán)性能的計(jì)劃任務(wù)（調(diào)整計(jì)劃任務(wù)）

網(wǎng)卡流量

風(fēng)險(xiǎn)：網(wǎng)卡IO被占滿(mǎn)（1000Mb/8=100MB）

如何避免無(wú)法連接數(shù)據(jù)庫(kù)的情況：

1、減少?gòu)姆?wù)器的數(shù)量
2、進(jìn)行分級(jí)緩存
3、避免使用“select * ”進(jìn)行查詢(xún)
4、分離業(yè)務(wù)網(wǎng)絡(luò)和服務(wù)器網(wǎng)絡(luò)