背景

線上啟用memcached(以下簡(jiǎn)稱mc)作為熱點(diǎn)緩存組件已經(jīng)多年，其穩(wěn)定性和性能都經(jīng)歷住了考驗(yàn)，這里記錄一下踩過的幾個(gè)坑。

大key存儲(chǔ)

某年某月某日，觀察mysql的讀庫(kù)CPU占比有些異常偏高，去check慢查詢log，發(fā)現(xiàn)部分應(yīng)有緩存的慢sql居然存在幾秒執(zhí)行一次情況，不符合緩存數(shù)小時(shí)的代碼邏輯。查看業(yè)務(wù)log在每次查詢sql之后也確實(shí)有將結(jié)果set至mc之中：

# python代碼mc.set(cache_key, v, 3600)

而set返回的取值卻是False而非正常的True，很快想到mc著名的只可存儲(chǔ)不超過1MB大小的key限制，在以往的業(yè)務(wù)場(chǎng)景中沒有出現(xiàn)過這么大的key，所以一直沒達(dá)到過這個(gè)限制，直到這一次撞上。要解決超過1MB大小的key存儲(chǔ)問題有以下幾個(gè)思路：

(相關(guān)資料圖)

想辦法將cache結(jié)果變小換個(gè)cache組件mc >=1.4.2 版本其實(shí)已經(jīng)支持命令行參數(shù)-I指定最大key大小了，線上使用版本支持最小1KB最大128MB的設(shè)置將大key拆分為幾個(gè)子key，通過set_multi和get_multi實(shí)現(xiàn)統(tǒng)一的讀寫。

無論是通過2或3都可以支持更大的key存儲(chǔ)，但是更大的key存儲(chǔ)對(duì)于讀寫傳輸其實(shí)都更不友好，而思路4需要手動(dòng)拆分、組裝子key略顯麻煩，所以優(yōu)先從思路1著手，意外發(fā)現(xiàn)python使用的memcached庫(kù)其實(shí)提供了key壓縮功能，在寫入時(shí)指定min_compress_len參數(shù)即可：

mc.set(key, v, time=expires, min_compress_len=1024)

如上表示寫入的v對(duì)象序列化大小若>=1024則啟用壓縮存儲(chǔ)，庫(kù)底層會(huì)將其壓縮后再寫入mc，讀取時(shí)庫(kù)底層也會(huì)自動(dòng)解壓縮后再返回，業(yè)務(wù)層可以說完全無感，并且壓縮后還能極大降低存儲(chǔ)和傳輸成本。最終通過min_compress_len參數(shù)啟用大key壓縮后，原1MB大小的key直瘦身了4/5。

slab鈣化

啟用大key壓縮后mc度過了好一段歲月靜好的日子，直到某一天...

大規(guī)模key分布變動(dòng)導(dǎo)致的鈣化

查看zabbix上的相關(guān)監(jiān)控，發(fā)現(xiàn)mc的key查詢miss比例居然接近50%！這個(gè)緩存命中率著實(shí)讓人深思，進(jìn)一步check后發(fā)現(xiàn)同時(shí)異常的指標(biāo)還有evicted items數(shù)，日常取值居然可以達(dá)到數(shù)百/S的級(jí)別。mc官方文檔對(duì)evicted items的定義如下：

evicted                Number of times an item had to be evicted from the LRU before it expired.

即存儲(chǔ)的key在其實(shí)際過期前被從LRU強(qiáng)制清理了，這一般說明mc剩余可分配內(nèi)存不足了，所以新key寫入時(shí)只能先從LRU淘汰一部分key騰出空間后再給新key使用，但是查看mc的內(nèi)存使用率，明明還有超過>2GB的剩余內(nèi)存可用。最終調(diào)查后真相大白：mc明明剩余大量?jī)?nèi)存可用，寫入新key卻不斷導(dǎo)致舊key被提前清除的現(xiàn)象其實(shí)是mc特有的slab鈣化問題所致：

Memcached采用LRU(Least Recent Used）淘汰算法，在內(nèi)存容量滿時(shí)踢出過期失效和LRU數(shù)據(jù)，為新數(shù)據(jù)騰出內(nèi)存空間。不過該淘汰算法在內(nèi)存空間不足以分配新的Slab情況下，這時(shí)只會(huì)在同一類Slab內(nèi)部踢出數(shù)據(jù)。即當(dāng)某個(gè)Slab容量滿，且不能在內(nèi)存足夠分配新的Slab，只會(huì)在相同Slab內(nèi)部踢出數(shù)據(jù)，而不會(huì)挪用或者踢出其他Slab的數(shù)據(jù)。這種局部剔除數(shù)據(jù)的淘汰算法帶來一個(gè)問題：Slab鈣化。

簡(jiǎn)單來說memcached 使用的不同尺寸slab一旦分配完成就不可變了，所以如果某類slab已用盡，即便其他slab剩余大量空閑內(nèi)存也無法再對(duì)其加以利用。業(yè)務(wù)這邊之前對(duì)使用mc的部分緩存key進(jìn)行了整合優(yōu)化，在優(yōu)化之前單mc的全部5GB內(nèi)存均已根據(jù)key存儲(chǔ)情況分配給了特定的slab，而優(yōu)化之后大大降低了小key的數(shù)量，取而代之的是相對(duì)更緊湊的大key，key的數(shù)量和大小分布都發(fā)生了顯著的變化，于是原有的適用于大量小key的slab分配就無法滿足優(yōu)化后的key存儲(chǔ)了。最終體現(xiàn)為，中等大小的slab內(nèi)存已被耗盡，每次寫入新key只能先通過LRU淘汰部分舊key騰出空間，體現(xiàn)為evicted數(shù)異常偏高，并且直接影響了緩存命中率，而小尺寸的slab卻長(zhǎng)期大量空閑，體現(xiàn)為mc內(nèi)存使用剩余空間一直充足。網(wǎng)上檢索解決鈣化問題有三個(gè)辦法：

1) 重啟Memcached實(shí)例，簡(jiǎn)單粗暴，啟動(dòng)后重新分配Slab class，但是如果是單點(diǎn)可能造成大量請(qǐng)求訪問數(shù)據(jù)庫(kù)，出現(xiàn)雪崩現(xiàn)象，沖跨數(shù)據(jù)庫(kù)。2) 隨機(jī)過期：過期淘汰策略也支持淘汰其他slab class的數(shù)據(jù)，twitter工程師采用隨機(jī)選擇一個(gè)Slab，釋放該Slab的所有緩存數(shù)據(jù)，然后重新建立一個(gè)合適的Slab。3) 通過slab_reassign、slab_authmove參數(shù)控制。

方法2看上去應(yīng)是twitter的定制版mc Twemcache的特有功能，方法3則是線上mc已支持的方案，但首次接觸也不敢貿(mào)然直接在線上使用?？紤]到mc僅作為熱點(diǎn)緩存其數(shù)據(jù)可丟失，且部署有多臺(tái)分?jǐn)倝毫?，直接采用低峰時(shí)段分別重啟單個(gè)mc的策略解決，重啟后evicted item直接降為0，cache命中率升至90%上下。

少量大key變動(dòng)導(dǎo)致的鈣化

首次鈣化之后又是一段歲月靜好，直到...某段時(shí)間開始一個(gè)主要接口偶發(fā)耗時(shí)會(huì)突然飆升一下，對(duì)應(yīng)機(jī)器的CPU使用也會(huì)瞬間飚高一小陣，查看zabbix監(jiān)控時(shí)，發(fā)現(xiàn)mc的 evicted items>0已持續(xù)好一段時(shí)間，但一直是個(gè)位數(shù)/S的級(jí)別，看著影響不大。進(jìn)一步執(zhí)行stats items命令，發(fā)現(xiàn)發(fā)生key evict的是最大的chunk_size=1048576 的slab 42，這也就是說存在大小在512KB~1MB之間的大key，同時(shí)當(dāng)前mc分配的1MB slab個(gè)數(shù)已無法滿足其存儲(chǔ)，也無法再分配出新的1MB大小的slab，最終體現(xiàn)為對(duì)于大key的再次鈣化。由于slab鈣化大key會(huì)被頻繁evict，對(duì)應(yīng)緩存機(jī)制基本失效，所幸server端針對(duì)該類大key的讀取還做了一個(gè)短期的本地cache，避免了每次請(qǐng)求都穿透到db。在某些特定時(shí)刻，當(dāng)mc中對(duì)應(yīng)大key失效且本地cache失效，對(duì)應(yīng)請(qǐng)求又較多的時(shí)候，多個(gè)獨(dú)立的請(qǐng)求都會(huì)穿透到db獲取數(shù)據(jù)，而后再寫入mc，無論是穿透到db獲取數(shù)據(jù)后本地進(jìn)行相應(yīng)的數(shù)據(jù)組裝處理邏輯，還是讀寫mc的壓縮、解壓縮數(shù)據(jù)操作，都比較耗CPU，最終會(huì)體現(xiàn)為api耗時(shí)增加，且CPU使用率也存在飚高的現(xiàn)象。近期并沒有涉及大key讀寫的改動(dòng)，那這次的大key slab鈣化又是怎么來的？進(jìn)一步探查原因：觸發(fā)evict的大key近期確實(shí)無相關(guān)邏輯改動(dòng)，但該部分舊key的大小和運(yùn)營(yíng)放出的資源多少直接相關(guān)，近一段時(shí)間放出的資源一直持續(xù)增加，舊key原本大小是<512KB，所以使用的是512KB的slab 41，近期持續(xù)增大為>512KB后，就只能使用1MB的slab 42存儲(chǔ)了，對(duì)于slab 42來說相當(dāng)于在原有支持的大key數(shù)量基礎(chǔ)上又新的大key存儲(chǔ)需要支持，又由于slab鈣化無法再分配新的slab 42，最終觸發(fā)evict，cache命中率降低，api偶發(fā)耗時(shí)上升。最終解決方案：還是在業(yè)務(wù)低峰期逐個(gè)重啟mc，觸發(fā)slab重分配即可。

總結(jié)

memcached作為一個(gè)開源的純內(nèi)存kv緩存組件，上手簡(jiǎn)單、性能、穩(wěn)定性都有足夠保證，但是實(shí)際使用時(shí)也不可掉以輕心，對(duì)其相關(guān)監(jiān)控與關(guān)注不能少，對(duì)于其特有的最大key存儲(chǔ)限制、slab鈣化問題要有一定的認(rèn)識(shí)并能及時(shí)處理。轉(zhuǎn)載請(qǐng)注明出處，原文地址：https://www.cnblogs.com/AcAc-t/p/memcached_large_key_slab_calcification.html

參考

https://github.com/memcached/memcached/blob/master/doc/protocol.txt#L637https://github.com/memcached/memcached/wiki/ReleaseNotes142#configurable-maximum-item-sizehttps://www.jianshu.com/p/b91a45711460https://blog.twitter.com/engineering/en_us/a/2012/caching-with-twemcachehttps://www.cnblogs.com/AcAc-t/p/memcached_large_key_slab_calcification.htmlhttps://bugwz.com/2020/05/24/memcached-slab-calcification/#2-2-2、Rebalance執(zhí)行邏輯https://www.cnblogs.com/Leo_wl/p/3310294.html

關(guān)鍵詞：