轉(zhuǎn)載至微信公眾號：【架構(gòu)師小秘圈】 作者：孤獨煙，資深后端工程師，業(yè)內(nèi)知名原創(chuàng)作者

一個新聞

新聞內(nèi)容如下：
PHP工程師執(zhí)行redis keys \* 導(dǎo)致數(shù)據(jù)庫宕機

某公司技術(shù)部發(fā)生2起本年度PO級特大事故，造成公司資金損失400萬，原因如下：

由于PHP工程師直接操作上線redis，執(zhí)行

keys * wxdb（此處省略）cf8*

這樣的命令，導(dǎo)致redis鎖住，從而導(dǎo)致CPU飆升，引起所有支付鏈路卡住，等十幾秒結(jié)束后，所有的請求流量全部擠壓到了rds數(shù)據(jù)庫中，使數(shù)據(jù)庫產(chǎn)生了雪崩效應(yīng)，發(fā)生了數(shù)據(jù)庫宕機事件。

該公司表示，如再犯類似事故，將直接開除，并表示之后會逐步收回運維部各項權(quán)限。

正文

一條鐵律

在業(yè)內(nèi)，redis開發(fā)規(guī)范中有一條鐵律如下所示

線上Redis禁止使用Keys正則匹配操作

然而大家都知道，卻一直忘記，所以事故會不斷的發(fā)生。
下面講一講在線上執(zhí)行正則匹配操作，引起緩存雪崩，最終數(shù)據(jù)庫宕機的原因。

分析原因

OK，先說兩句廢話

1、redis是單線程的，其所有操作都是原子的，不會因并發(fā)產(chǎn)生數(shù)據(jù)異常

2、使用高耗時的Redis命令是很危險的，會占用唯一的一個線程的大量處理時間，導(dǎo)致所有的請求都被拖慢。（例如時間復(fù)雜度為O(N)的KEYS命令，嚴(yán)格禁止在生產(chǎn)環(huán)境中使用）

有上面兩句作鋪墊，原因就顯而易見了。

• (1)運維人員進行keys *操作，該操作比較耗時，又因為redis是單線程的，所以redis被鎖住。
• (2)此時QPS比較高，又來了幾萬個對redis的讀寫請求，因為redis被鎖住，所以全部Hang在那。
• (3)因為太多線程Hang在那，CPU嚴(yán)重飆升，造成redis所在的服務(wù)器宕機
• (4)所有的線程在redis那取不到數(shù)據(jù)，一瞬間全去數(shù)據(jù)庫取數(shù)據(jù)，數(shù)據(jù)庫就宕機了。

需要注意的是，同樣危險的命令不僅有keys *，還有以下幾組

Flushdb 命令用于清空當(dāng)前數(shù)據(jù)庫中的所有 key

Flushall 命令用于清空整個 Redis 服務(wù)器的數(shù)據(jù)(刪除所有數(shù)據(jù)庫的所有 key )

CONFIG 客戶端連接后可配置服務(wù)器

因此，一個合格的redis運維或者開發(fā)，應(yīng)該懂得如何禁用上面的命令。所以我一直覺得出現(xiàn)新聞中那種情況的原因，一般是人員的水平問題。

怎么禁用這些命令呢？
就是在redis.conf中，在SECURITY這一項中，我們新增以下命令：

rename-command FLUSHALL ""
rename-command FLUSHDB  ""
rename-command CONFIG   ""
rename-command KEYS     ""

另外，對于FLUSHALL命令，需要設(shè)置配置文件中appendonly no，否則服務(wù)器是無法啟動

注意了，上面的這些命令可能有遺漏，大家可以查官方文檔。除了Flushdb這類和redis安全隱患有關(guān)的命令意外，但凡發(fā)現(xiàn)時間復(fù)雜度為O(N)的命令，都要慎重，不要在生產(chǎn)上隨便使用。例如hgetall、lrange、smembers、zrange、sinter等命令，它們并非不能使用，但這些命令的時間復(fù)雜度都為O(N)，使用這些命令需要明確N的值，否則也會出現(xiàn)緩存宕機。

改良建議

業(yè)內(nèi)建議使用scan命令來改良keys和SMEMBERS命令

redis2.8版本以后有了一個新命令scan，可以用來分批次掃描redis記錄，這樣肯定會導(dǎo)致整個查詢消耗的總時間變大，但不會影響redis服務(wù)卡頓，影響服務(wù)使用。

具體使用，大家可以參考這份文檔http://doc.redisfans.com/key/scan.html