快捷導(dǎo)航

MySQL如何支撐起億級(jí)流量

更新時(shí)間：2021年09月15日 14:55:05 作者：JavaEdge.

當(dāng)每天新增數(shù)據(jù)上億級(jí)的時(shí)候，單表數(shù)據(jù)量在百萬(wàn)級(jí)別，數(shù)據(jù)庫(kù)服務(wù)器的高峰期寫(xiě)入壓力、查詢(xún)壓力在都很高的時(shí)候，該如何讓MySQL順利支撐起來(lái)呢？本片文章將教給你詳細(xì)的方案

1 主從讀寫(xiě)分離

大部分互聯(lián)網(wǎng)業(yè)務(wù)都是讀多寫(xiě)少，因此優(yōu)先考慮DB如何支撐更高查詢(xún)數(shù)，首先就需要區(qū)分讀、寫(xiě)流量，這才方便針對(duì)讀流量單獨(dú)擴(kuò)展，即主從讀寫(xiě)分離。

若前端流量突增導(dǎo)致從庫(kù)負(fù)載過(guò)高，DBA會(huì)優(yōu)先做個(gè)從庫(kù)擴(kuò)容上去，這樣對(duì)DB的讀流量就會(huì)落到多個(gè)從庫(kù)，每個(gè)從庫(kù)的負(fù)載就降了下來(lái)，然后開(kāi)發(fā)再盡力將流量擋在DB層之上。

Cache V.S MySQL讀寫(xiě)分離
由于從開(kāi)發(fā)和維護(hù)的難度考慮，引入緩存會(huì)引入復(fù)雜度，要考慮緩存數(shù)據(jù)一致性，穿透，防雪崩等問(wèn)題，并且也多維護(hù)一類(lèi)組件。所以推薦優(yōu)先采用讀寫(xiě)分離，扛不住了再使用Cache。

1.1 core

主從讀寫(xiě)分離一般將一個(gè)DB的數(shù)據(jù)拷貝為一或多份，并且寫(xiě)入到其它的DB服務(wù)器中：

原始DB為主庫(kù)，負(fù)責(zé)數(shù)據(jù)寫(xiě)入
拷貝目標(biāo)DB為從庫(kù)，負(fù)責(zé)數(shù)據(jù)查詢(xún)

所以主從讀寫(xiě)分離的關(guān)鍵：

數(shù)據(jù)的拷貝

即主從復(fù)制

屏蔽主從分離帶來(lái)的訪(fǎng)問(wèn)DB方式的變化

讓開(kāi)發(fā)人員使用感覺(jué)依舊在使用單一DB

2 主從復(fù)制

MySQL的主從復(fù)制依賴(lài)于binlog，即記錄MySQL上的所有變化并以二進(jìn)制形式保存在磁盤(pán)上二進(jìn)制日志文件。

主從復(fù)制就是將binlog中的數(shù)據(jù)從主庫(kù)傳輸?shù)綇膸?kù)，一般異步：主庫(kù)操作不會(huì)等待binlog同步完成。

2.1 主從復(fù)制的過(guò)程

從庫(kù)在連接到主節(jié)點(diǎn)時(shí)會(huì)創(chuàng)建一個(gè)I/O線(xiàn)程，以請(qǐng)求主庫(kù)更新的binlog，并把接收到的binlog寫(xiě)入relay log文件，主庫(kù)也會(huì)創(chuàng)建一個(gè)log dump線(xiàn)程發(fā)送binlog給從庫(kù)
從庫(kù)還會(huì)創(chuàng)建一個(gè)SQL線(xiàn)程，讀relay log，并在從庫(kù)中做回放，最終實(shí)現(xiàn)主從的一致性

使用獨(dú)立的log dump線(xiàn)程是異步，避免影響主庫(kù)的主體更新流程，而從庫(kù)在接收到信息后并不是寫(xiě)入從庫(kù)的存儲(chǔ)，是寫(xiě)入一個(gè)relay log，這是為避免寫(xiě)入從庫(kù)實(shí)際存儲(chǔ)會(huì)比較耗時(shí)，最終造成從庫(kù)和主庫(kù)延遲變長(zhǎng)。

主從異步復(fù)制的過(guò)程

基于性能考慮，主庫(kù)寫(xiě)入流程并沒(méi)有等待主從同步完成就返回結(jié)果，極端情況下，比如主庫(kù)上binlog還沒(méi)來(lái)得及落盤(pán)，就發(fā)生磁盤(pán)損壞或機(jī)器掉電，導(dǎo)致binlog丟失，主從數(shù)據(jù)不一致。不過(guò)概率很低，可容忍。

主庫(kù)宕機(jī)后，binlog丟失導(dǎo)致的主從數(shù)據(jù)不一致也只能手動(dòng)恢復(fù)。

主從復(fù)制后，即可：

在寫(xiě)入時(shí)只寫(xiě)主庫(kù)
在讀數(shù)據(jù)時(shí)只讀從庫(kù)

這樣即使寫(xiě)請(qǐng)求會(huì)鎖表或鎖記錄，也不會(huì)影響讀請(qǐng)求執(zhí)行。高并發(fā)下，可部署多個(gè)從庫(kù)共同承擔(dān)讀流量，即一主多從支撐高并發(fā)讀。

從庫(kù)也能當(dāng)成個(gè)備庫(kù)，以避免主庫(kù)故障導(dǎo)致數(shù)據(jù)丟失。

那無(wú)限制地增加從庫(kù)就能支撐更高并發(fā)嗎？
NO！從庫(kù)越多，從庫(kù)連接上來(lái)的I/O線(xiàn)程越多，主庫(kù)也要?jiǎng)?chuàng)建同樣多l(xiāng)og dump線(xiàn)程處理復(fù)制的請(qǐng)求，對(duì)于主庫(kù)資源消耗較高，同時(shí)受限于主庫(kù)的網(wǎng)絡(luò)帶寬，所以一般一個(gè)主庫(kù)最多掛3～5個(gè)從庫(kù)。

2.2 主從復(fù)制的副作用

比如發(fā)朋友圈這一操作，就存在數(shù)據(jù)的：

同步操作

如更新DB

異步操作

如將朋友圈內(nèi)容同步給審核系統(tǒng)

所以更新完主庫(kù)后，會(huì)將朋友圈ID寫(xiě)入MQ，由Consumer依據(jù)ID在從庫(kù)獲取朋友圈信息再發(fā)給審核系統(tǒng)。
此時(shí)若主從DB存在延遲，會(huì)導(dǎo)致在從庫(kù)取不到朋友圈信息，出現(xiàn)異常！

主從延遲對(duì)業(yè)務(wù)的影響示意圖

2.3 避免主從復(fù)制的延遲

這咋辦呢？其實(shí)解決方案有很多，核心思想都是盡量不去從庫(kù)查詢(xún)數(shù)據(jù)。因此針對(duì)上述案例，就有如下方案：

2.3.1 數(shù)據(jù)冗余

可在發(fā)MQ時(shí)，不止發(fā)送朋友圈ID，而是發(fā)給Consumer需要的所有朋友圈信息，避免從DB重新查詢(xún)數(shù)據(jù)。

推薦該方案，因?yàn)樽銐蚝?jiǎn)單，不過(guò)可能造成單條消息較大，從而增加消息發(fā)送的帶寬和時(shí)間。

2.3.2 使用Cache

在同步寫(xiě)DB的同時(shí)，把朋友圈數(shù)據(jù)寫(xiě)Cache，這樣Consumer在獲取朋友圈信息時(shí)，優(yōu)先查詢(xún)Cache，這也能保證數(shù)據(jù)一致性。

該方案適合新增數(shù)據(jù)的場(chǎng)景。若是在更新數(shù)據(jù)場(chǎng)景下，先更新Cache可能導(dǎo)致數(shù)據(jù)不一致。比如兩個(gè)線(xiàn)程同時(shí)更新數(shù)據(jù)：

線(xiàn)程A把Cache數(shù)據(jù)更新為1
另一個(gè)線(xiàn)程B把Cache數(shù)據(jù)更新為2
然后線(xiàn)程B又更新DB數(shù)據(jù)為2
線(xiàn)程A再更新DB數(shù)據(jù)為1

最終DB值（1）和Cache值（2）不一致！

2.3.3 查詢(xún)主庫(kù)

可以在Consumer中不查詢(xún)從庫(kù)，而改為查詢(xún)主庫(kù)。

使用要慎重，要明確查詢(xún)的量級(jí)不會(huì)很大，是在主庫(kù)的可承受范圍之內(nèi)，否則會(huì)對(duì)主庫(kù)造成較大壓力。

若非萬(wàn)不得已，不要使用該方案。因?yàn)橐峁┮粋€(gè)查詢(xún)主庫(kù)的接口，很難保證其他人不濫用該方法。

主從同步延遲也是排查問(wèn)題時(shí)容易忽略。
有時(shí)會(huì)遇到從DB獲取不到信息的詭異問(wèn)題，會(huì)糾結(jié)代碼中是否有一些邏輯把之前寫(xiě)入內(nèi)容刪除了，但發(fā)現(xiàn)過(guò)段時(shí)間再去查詢(xún)時(shí)又能讀到數(shù)據(jù)，這基本就是主從延遲問(wèn)題。
所以，一般把從庫(kù)落后的時(shí)間作為一個(gè)重點(diǎn)DB指標(biāo)，做監(jiān)控和報(bào)警，正常時(shí)間在ms級(jí)，達(dá)到s級(jí)就要告警。

主從的延遲時(shí)間預(yù)警，那如何通過(guò)哪個(gè)數(shù)據(jù)庫(kù)中的哪個(gè)指標(biāo)來(lái)判別？在從從庫(kù)中，通過(guò)監(jiān)控show slave
status\G命令輸出的Seconds_Behind_Master參數(shù)的值判斷，是否有發(fā)生主從延時(shí)。
這個(gè)參數(shù)值是通過(guò)比較sql_thread執(zhí)行的event的timestamp和io_thread復(fù)制好的
event的timestamp(簡(jiǎn)寫(xiě)為ts)進(jìn)行比較，而得到的這么一個(gè)差值。
但如果復(fù)制同步主庫(kù)bin_log日志的io_thread線(xiàn)程負(fù)載過(guò)高，則Seconds_Behind_Master一直為0，即無(wú)法預(yù)警，通過(guò)Seconds_Behind_Master這個(gè)值來(lái)判斷延遲是不夠準(zhǔn)確。其實(shí)還可以通過(guò)比對(duì)master和slave的binlog位置。

3 如何訪(fǎng)問(wèn)DB

使用主從復(fù)制將數(shù)據(jù)復(fù)制到多個(gè)節(jié)點(diǎn)，也實(shí)現(xiàn)了DB的讀寫(xiě)分離，這時(shí)，對(duì)DB的使用也發(fā)生了變化：

以前只需使用一個(gè)DB地址
現(xiàn)在需使用一個(gè)主庫(kù)地址，多個(gè)從庫(kù)地址，且需區(qū)分寫(xiě)入操作和查詢(xún)操作，再結(jié)合“分庫(kù)分表”，復(fù)雜度大大提升。

為降低實(shí)現(xiàn)的復(fù)雜度，業(yè)界涌現(xiàn)了很多DB中間件解決DB的訪(fǎng)問(wèn)問(wèn)題，大致分為：

3.1 應(yīng)用程序內(nèi)部

如TDDL（ Taobao Distributed Data Layer），以代碼形式內(nèi)嵌運(yùn)行在應(yīng)用程序內(nèi)部?？煽闯墒且环N數(shù)據(jù)源代理，它的配置管理多個(gè)數(shù)據(jù)源，每個(gè)數(shù)據(jù)源對(duì)應(yīng)一個(gè)DB，可能是主庫(kù)或從庫(kù)。
當(dāng)有一個(gè)DB請(qǐng)求時(shí)，中間件將SQL語(yǔ)句發(fā)給某個(gè)指定數(shù)據(jù)源，然后返回處理結(jié)果。

優(yōu)點(diǎn)

簡(jiǎn)單易用，部署成本低，因?yàn)橹踩霊?yīng)用程序內(nèi)部，與程序一同運(yùn)行，適合運(yùn)維較弱的小團(tuán)隊(duì)。

缺點(diǎn)

缺乏多語(yǔ)言支持，都是Java語(yǔ)言開(kāi)發(fā)的，無(wú)法支持其他的語(yǔ)言。版本升級(jí)也依賴(lài)使用方的更新。

3.2 獨(dú)立部署的代理層方案

如Mycat、Atlas、DBProxy。

這類(lèi)中間件部署在獨(dú)立服務(wù)器，業(yè)務(wù)代碼如同在使用單一DB，實(shí)際上它內(nèi)部管理著很多的數(shù)據(jù)源，當(dāng)有DB請(qǐng)求時(shí)，它會(huì)對(duì)SQL語(yǔ)句做必要的改寫(xiě)，然后發(fā)往指定數(shù)據(jù)源。

優(yōu)點(diǎn)

一般使用標(biāo)準(zhǔn)MySQL通信協(xié)議，所以可支持多種語(yǔ)言
獨(dú)立部署，所以方便維護(hù)升級(jí)，適合有運(yùn)維能力的大中型團(tuán)隊(duì)

缺點(diǎn)

所有的SQL語(yǔ)句都需要跨兩次網(wǎng)絡(luò)：從應(yīng)用到代理層和從代理層到數(shù)據(jù)源，所以在性能上會(huì)有一些損耗。

4 總結(jié)

可以把主從復(fù)制引申為存儲(chǔ)節(jié)點(diǎn)之間互相復(fù)制存儲(chǔ)數(shù)據(jù)的技術(shù)，可以實(shí)現(xiàn)數(shù)據(jù)冗余，以達(dá)到備份和提升橫向擴(kuò)展能力。

使用主從復(fù)制時(shí)，需考慮：

主從的一致性和寫(xiě)入性能的權(quán)衡

若保證所有從節(jié)點(diǎn)都寫(xiě)入成功，則寫(xiě)性能一定受影響；若只寫(xiě)主節(jié)點(diǎn)就返回成功，則從節(jié)點(diǎn)就可能出現(xiàn)數(shù)據(jù)同步失敗，導(dǎo)致主從不一致。互聯(lián)網(wǎng)項(xiàng)目，一般優(yōu)先考慮性能而非數(shù)據(jù)的強(qiáng)一致性