[[138356]]

關(guān)于秒殺

隨著雙11活動(dòng)的不斷發(fā)展，小米饑餓營(yíng)銷模式的興起，“秒殺”已經(jīng)成為一個(gè)熱點(diǎn)詞匯。在一些活動(dòng)中，熱銷商品會(huì)以驚人的速度售罄，比如最近筆者在搶購(gòu)美圖M4手機(jī)，12點(diǎn)開(kāi)賣，1分鐘之內(nèi)就被售罄。

秒殺的實(shí)現(xiàn)

對(duì)于關(guān)注數(shù)據(jù)庫(kù)的筆者來(lái)說(shuō)，更關(guān)心的是如何高效的實(shí)現(xiàn)秒殺應(yīng)用。之前淘寶在2013年的數(shù)據(jù)庫(kù)大會(huì)上分享過(guò)他們的秒殺方案，修改MySQL數(shù)據(jù)庫(kù)源碼來(lái)實(shí)現(xiàn)高效的秒殺應(yīng)用。但是，那篇分享過(guò)于高大上，沒(méi)有給出具體的實(shí)現(xiàn)過(guò)程。另外，從其他渠道打聽(tīng)到的是這個(gè)方案并沒(méi)有在生產(chǎn)環(huán)境上線，不知道有沒(méi)有其他知道內(nèi)幕的小伙伴，具體來(lái)說(shuō)說(shuō)淘寶的方案是否有上線。

當(dāng)然，有多種方法來(lái)優(yōu)化秒殺應(yīng)用，比如使用memcached的CAS功能，但是這些方法都不能實(shí)現(xiàn)事務(wù)的特性。對(duì)于深受Jim Gray事務(wù)處理教育長(zhǎng)大的一代，筆者覺(jué)得任何事情都應(yīng)該事務(wù)的，不支持事務(wù)只不過(guò)能取得暫時(shí)的勝利，整個(gè)世界的哲學(xué)應(yīng)該就是事務(wù)，即要么全做，要么全不做，不要處于一個(gè)中間狀態(tài)。筆者的為人哲學(xué)就是，要么不去設(shè)定一個(gè)目標(biāo)，否則這個(gè)目標(biāo)一定會(huì)去實(shí)現(xiàn)。比如，筆者決定去讀博，那么一定會(huì)完成這個(gè)學(xué)業(yè)。

筆者感覺(jué)雖然淘寶沒(méi)有給出具體的實(shí)現(xiàn)方式，但是拋出了秒殺應(yīng)用對(duì)于數(shù)據(jù)庫(kù)壓力的問(wèn)題所在，即大并發(fā)量下更新同一行數(shù)據(jù)的壓力。例如并發(fā)執(zhí)行如下的SQL語(yǔ)句模擬秒殺場(chǎng)景：

BEGIN; 
 
INSERT INTO stock_log VALUES 
 
SELECT count FROM stock WHERE id=1 AND count>0 FOR UPDATE; 
 
UPDATE stock SET count = count -1 WHERE id=1 AND count > 0; 
 
COMMIT; 

在做秒殺時(shí)，最主要是對(duì)庫(kù)存表進(jìn)行操作，在操作前可能需要插入一些其他操作，比如日志等，然后就是對(duì)庫(kù)存表進(jìn)行更新。下圖顯示增大并發(fā)量的情況下，事務(wù)處理的性能：

顯而易見(jiàn)的是隨著并發(fā)量的增大，事務(wù)處理的性能越差。這和淘寶之前分享的數(shù)據(jù)基本一致。導(dǎo)致其中的原因就是秒殺是對(duì)同一件商品進(jìn)行更新，需要對(duì)同一行記錄加鎖，因此秒殺操作雖然是并行的，但是在數(shù)據(jù)庫(kù)層面是串行的。

隨著并發(fā)的不斷增大，不斷發(fā)生事務(wù)的鎖等待與喚醒操作，導(dǎo)致性能的急劇下降。如果通過(guò)perf工具來(lái)觀察的話，應(yīng)該可以觀察到類似如下的內(nèi)容：

# 
 
59.06% mysqld mysqld [.] lock_deadlock_recursive 
 
16.63% mysqld libc-2.13.so [.] 0x115171 3.09% mysqld mysqld [.] lock_rec_get_prev 
 
2.96% mysqld mysqld [.] my_strnncollsp_utf8 
 
...... 

可以發(fā)現(xiàn)鎖的死鎖檢測(cè)占據(jù)了大部分的CPU時(shí)間，究其原因，就是因?yàn)殒i等待。

innodb_thread_concurrency

有小伙伴或許會(huì)知道可以通過(guò)innodb_thread_concurrency參數(shù)來(lái)控制InnoDB存儲(chǔ)引擎層的并發(fā)量。的確，通過(guò)這個(gè)參數(shù)可以限制進(jìn)入InnoDB引擎層的事務(wù)數(shù)量，對(duì)比測(cè)試的話，性能上的確會(huì)有一定的提升：

可以發(fā)現(xiàn)，將innodb_thread_concurrency設(shè)置為16，性能的確會(huì)有一定的提升。并發(fā)線程數(shù)在128的時(shí)候，TPS從原有的4300提升為了7200，將近有65%的性能提升。但是在256線程之后，性能依舊堪憂。

導(dǎo)致上述的原因是雖然在InnoDB存儲(chǔ)引擎層做了“限流”，但是MySQL數(shù)據(jù)庫(kù)上層的線程依然需要等待喚醒。

#p#

線程池技術(shù)

業(yè)界提供了很多關(guān)于秒殺MySQL的解決方案，然而非常的定制化，并且需要應(yīng)用修改相信的程序，比如通過(guò)在SQL語(yǔ)句中寫hint來(lái)進(jìn)行排隊(duì)，而這種的排隊(duì)機(jī)制在我看來(lái)在低并發(fā)量下性能反而又會(huì)變差。因此，一個(gè)通用的解決方案是采用線程池技術(shù)。

線程池可以在MySQL上層限制住同時(shí)運(yùn)行的MySQL的事務(wù)數(shù)，這樣就解決了由秒殺而導(dǎo)致的資源競(jìng)爭(zhēng)問(wèn)題。例如，通過(guò)前面的測(cè)試，已經(jīng)得知并發(fā)16線程時(shí)，秒殺可以有***的性能，那么這時(shí)用戶將線程池的大小設(shè)置為16，這樣就能獲得用戶預(yù)期想要的性能：

可以發(fā)現(xiàn)即使在4096個(gè)并發(fā)線程下，秒殺依然可以有近10000的TPS。通過(guò)線程池技術(shù)，秒殺就是這么簡(jiǎn)單，無(wú)需任何應(yīng)用端的修改。

但是線程池這里有個(gè)參數(shù)thread_pool_oversubscribe，這個(gè)參數(shù)其實(shí)有點(diǎn)類似云計(jì)算中“超售”概念，即MySQL的線程池允許有額外的線程運(yùn)行。該參數(shù)默認(rèn)是3，之前thread_pool_size設(shè)置為16，那么總共允許16*(1+3)=64個(gè)線程同時(shí)運(yùn)行。這個(gè)參數(shù)的默認(rèn)值本身沒(méi)有問(wèn)題，但是對(duì)于秒殺應(yīng)用來(lái)說(shuō)確是不需要的，因?yàn)橹耙呀?jīng)討論過(guò)，秒殺應(yīng)用是串行的。所以將參數(shù)thread_pool_oversubscribe設(shè)置為1，秒殺應(yīng)用還能有進(jìn)一步的提升：

可以發(fā)現(xiàn)在大并發(fā)的線程下，性能還能有10%~30%的提升。

總結(jié)

其實(shí)秒殺應(yīng)用的數(shù)據(jù)庫(kù)層優(yōu)化非常簡(jiǎn)單，各個(gè)層面做好排隊(duì)即可，如：

• 應(yīng)用層做好對(duì)于單個(gè)商品搶購(gòu)的數(shù)量限制
• MySQL數(shù)據(jù)庫(kù)層使用線程池技術(shù)來(lái)保證大并發(fā)量下的性能
• 調(diào)整參數(shù)thread_pool_oversubscribe用來(lái)進(jìn)一步提升性能

MySQL企業(yè)版提供了線程池插件，但是需要額外的費(fèi)用。小伙伴們可以使用開(kāi)源的MySQL版本InnoSQL，其免費(fèi)提供了線程池，可以保證應(yīng)用在大并發(fā)量下依舊保證應(yīng)用的穩(wěn)定性，特別是對(duì)于秒殺類的應(yīng)用。

點(diǎn)擊下方原文閱讀可以下載InnoSQL 5.5.30-v6/InnoSQL 5.6.19-v1版本，其中提供了免費(fèi)的線程池，雙機(jī)高可用套件，TopSQL等插件，并行復(fù)制等功能。使用InnoSQL可以得到筆者完整的免費(fèi)技術(shù)支持，還等什么呢?