《阿里價(jià)值“千萬(wàn)”的秒殺場(chǎng)景參數(shù)優(yōu)化》要點(diǎn)：
本文介紹了阿里價(jià)值“千萬(wàn)”的秒殺場(chǎng)景參數(shù)優(yōu)化，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

秒殺最早來(lái)自天貓雙11各種商品的促銷(xiāo)活動(dòng)中,現(xiàn)在已經(jīng)有很多業(yè)務(wù)場(chǎng)景在使用,比如搶紅包,搶票等.其特點(diǎn)有三高：瞬時(shí)并發(fā)高,數(shù)據(jù)一致性高,熱點(diǎn)更新頻度高.這樣三高的場(chǎng)景下往往給數(shù)據(jù)庫(kù)造成極大的壓力,大量更新數(shù)據(jù)庫(kù)中的同一行,這樣必然會(huì)產(chǎn)生鎖等待,導(dǎo)致數(shù)據(jù)庫(kù)的性能急劇下降的問(wèn)題,很容易出現(xiàn)雪崩效應(yīng).筆者記得有一年春節(jié),一個(gè)電視臺(tái)定時(shí)在整點(diǎn)發(fā)放紅包,結(jié)果由于壓力太高,導(dǎo)致更新數(shù)據(jù)庫(kù)紅包數(shù)額的請(qǐng)求全部堆積,業(yè)務(wù)全部掛掉,面對(duì)這樣的情況我們當(dāng)時(shí)也束手無(wú)策.

面對(duì)秒殺業(yè)務(wù)的場(chǎng)景,數(shù)據(jù)庫(kù)成為了底層系統(tǒng)中最重要的瓶頸點(diǎn),阿里經(jīng)過(guò)幾年的沉淀也誕生了很多的技術(shù)手段來(lái)進(jìn)行優(yōu)化,這里我們就重點(diǎn)講一下底層數(shù)據(jù)所做的優(yōu)化.當(dāng)大量的并發(fā)更新同一條記錄時(shí),使用排隊(duì)的方式來(lái)保證高并發(fā)下熱點(diǎn)記錄更新依然能保持較好的性能,為threads_running設(shè)置一個(gè)硬上線,當(dāng)并發(fā)超過(guò)此值是,拒絕執(zhí)行sql,保護(hù)MySQL,我們將這個(gè)稱(chēng)之為高水位限流,這樣就給數(shù)據(jù)庫(kù)加上了一層限流的功能,使得數(shù)據(jù)庫(kù)不被瞬間的高爆發(fā)請(qǐng)求打爆.

高水位限流實(shí)現(xiàn)：

監(jiān)控系統(tǒng)status變量threads_running,當(dāng)滿(mǎn)足拒絕條件,拒絕執(zhí)行sql,返回用戶(hù)：MySQL Server is too busy,判斷邏輯在dispatch_command中,sql解析之后.

增加的系統(tǒng)variables：

1. threads_running_ctl_mode： 限流的sql類(lèi)型,有兩個(gè)取值：[ALL | SELECTS],默認(rèn)SELECTS,設(shè)置為ALL需謹(jǐn)慎.
2. threads_running_high_watermark： 限流水位值,只有threads_running超過(guò)此值才會(huì)觸發(fā),默認(rèn)值為max_connections,當(dāng)set global threads_running_high_watermark=0時(shí)自動(dòng)設(shè)置為max_connections.

拒絕必要條件：

1. threads_running超過(guò)threads_running_high_watermark.
2. threads_running_ctl_mode與sql類(lèi)型相符.

以下情況不拒絕：

1. 用戶(hù)具有super權(quán)限.
2. sql所在事務(wù)已經(jīng)開(kāi)啟.
3. sql為commit/rollback.

阿里云的RDS已經(jīng)集成了阿里秒殺場(chǎng)景下的參數(shù)優(yōu)化,所以如果你的應(yīng)用場(chǎng)景中具有大量并發(fā)更新同一行記錄的場(chǎng)景,你可以打開(kāi)數(shù)據(jù)庫(kù)的限流參數(shù)：threads_running_ctl_mode和threads_running_high_watermark來(lái)保護(hù)數(shù)據(jù)庫(kù),讓你的數(shù)據(jù)庫(kù)平穩(wěn)過(guò)渡.下面我們來(lái)看一則生產(chǎn)案例.

從上圖中看到該數(shù)據(jù)庫(kù)的活躍連接數(shù)最高的時(shí)候到達(dá)了1W,通過(guò)show processlist可以看到大量的并發(fā)更新.

我們來(lái)看一下數(shù)據(jù)庫(kù)并發(fā)更新的TPS有多大：

可以看到數(shù)據(jù)庫(kù)中的活躍連接數(shù)非常高,每秒的update非常不穩(wěn)定.

我們?cè)诎严蘖鏖_(kāi)關(guān)打開(kāi)后看一下性能表現(xiàn)：

從上圖可以明顯觀察到,通過(guò)打開(kāi)數(shù)據(jù)庫(kù)的限流開(kāi)關(guān),數(shù)據(jù)庫(kù)的活躍連接數(shù)在300左右,同時(shí)數(shù)據(jù)庫(kù)的TPS也沒(méi)有再出現(xiàn)很大的波動(dòng),這樣很好地保護(hù)住了DB.

文/羅龍九

玄慚,阿里云資深DBA專(zhuān)家；

有著豐厚的DBA經(jīng)驗(yàn),經(jīng)歷阿里歷年雙11考驗(yàn),保持著“無(wú)一丟單”的優(yōu)異紀(jì)錄.同時(shí)積累了6年對(duì)阿里云數(shù)據(jù)庫(kù)用戶(hù)的運(yùn)維、調(diào)優(yōu)、診斷等豐富的經(jīng)驗(yàn).

文章出處——DBAplus社群微信公眾

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4509.html