Redis 敢在線上做Keys正則匹配操作!你可以離職了!
一條鐵律
在業(yè)內(nèi)，redis開(kāi)發(fā)規(guī)范中有一條鐵律如下所示
線上Redis禁止使用Keys正則匹配操作
然而大家都知道，卻一直忘記，所以事故會(huì)不斷的發(fā)生。
下面講一講在線上執(zhí)行正則匹配操作，引起緩存雪崩，最終數(shù)據(jù)庫(kù)宕機(jī)的原因。
分析原因
OK，先說(shuō)兩句廢話
1、redis是單線程的，其所有操作都是原子的，不會(huì)因并發(fā)產(chǎn)生數(shù)據(jù)異常
2、使用高耗時(shí)的Redis命令是很危險(xiǎn)的，會(huì)占用***的一個(gè)線程的大量處理時(shí)間，導(dǎo)致所有的請(qǐng)求都被拖慢。(例如時(shí)間復(fù)雜度為O(N)的KEYS命令，嚴(yán)格禁止在生產(chǎn)環(huán)境中使用)
有上面兩句作鋪墊，原因就顯而易見(jiàn)了。
- (1)運(yùn)維人員進(jìn)行keys *操作，該操作比較耗時(shí)，又因?yàn)閞edis是單線程的，所以redis被鎖住。
- (2)此時(shí)QPS比較高，又來(lái)了幾萬(wàn)個(gè)對(duì)redis的讀寫(xiě)請(qǐng)求，因?yàn)閞edis被鎖住，所以全部Hang在那。
- (3)因?yàn)樘嗑€程Hang在那，CPU嚴(yán)重飆升，造成redis所在的服務(wù)器宕機(jī)
- (4)所有的線程在redis那取不到數(shù)據(jù)，一瞬間全去數(shù)據(jù)庫(kù)取數(shù)據(jù)，數(shù)據(jù)庫(kù)就宕機(jī)了。
需要注意的是，同樣危險(xiǎn)的命令不僅有keys *，還有以下幾組
- Flushdb 命令用于清空當(dāng)前數(shù)據(jù)庫(kù)中的所有key
- Flushall 命令用于清空整個(gè) Redis 服務(wù)器的數(shù)據(jù)(刪除所有數(shù)據(jù)庫(kù)的所有 key )
- CONFIG 客戶端連接后可配置服務(wù)器
因此，一個(gè)合格的redis運(yùn)維或者開(kāi)發(fā)，應(yīng)該懂得如何禁用上面的命令。所以我一直覺(jué)得出現(xiàn)新聞中那種情況的原因，一般是人員的水平問(wèn)題。
怎么禁用這些命令呢?
就是在redis.conf中，在SECURITY這一項(xiàng)中，我們新增以下命令：
- rename-command FLUSHALL ""
- rename-command FLUSHDB ""
- rename-command CONFIG ""
- rename-command KEYS ""
另外，對(duì)于FLUSHALL命令，需要設(shè)置配置文件中appendonly no，否則服務(wù)器是無(wú)法啟動(dòng)
注意了，上面的這些命令可能有遺漏，大家可以查官方文檔。除了Flushdb這類(lèi)和redis安全隱患有關(guān)的命令意外，但凡發(fā)現(xiàn)時(shí)間復(fù)雜度為O(N)的命令，都要慎重，不要在生產(chǎn)上隨便使用。例如hgetall、lrange、smembers、zrange、sinter等命令，它們并非不能使用，但這些命令的時(shí)間復(fù)雜度都為O(N)，使用這些命令需要明確N的值，否則也會(huì)出現(xiàn)緩存宕機(jī)。
改良建議
業(yè)內(nèi)建議使用scan命令來(lái)改良keys和SMEMBERS命令
redis2.8版本以后有了一個(gè)新命令scan，可以用來(lái)分批次掃描redis記錄，這樣肯定會(huì)導(dǎo)致整個(gè)查詢(xún)消耗的總時(shí)間變大，但不會(huì)影響redis服務(wù)卡頓，影響服務(wù)使用。
