導火索
：線上頻發報警，閘道器頻繁**超時，系統很多服務響應時間過長，服務cpu過載，資料庫死鎖等不正常現象
問題排查
：目標範圍縮小在近兩日上線功能，並鎖定在新上線的操作redis快取功能上。
問題復現
：將功能在開發環境測試，由於訪問量不足並未發現異常。
將某需求下線後，線上環境得以好轉。
分析**
：發現如下
/**
* del.
** @param keys the keys
*/public static void del(string... keys) ));
} catch (exception e) ", exceptiontools.getexceptionstacktrace(e));
throw new runtimeexception(e);}}
/*** del by pattern
** @param pattern prefix*
*/public static long del(string pattern) else
} catch (exception e) ", exceptiontools.getexceptionstacktrace(e));
throw new runtimeexception(e);
}}
：工程師執行redis keys * 導致環境瀕臨宕機！
由於及時發現，雖然未造成重大事故，但實屬本年度po級特大事故：
由於工程師直接操作上線redis，執行：
keys * wxdb
（此處省略）cf8*
新增的單引數的del方法覆蓋了多引數的del方法，所有呼叫del的地方都走單參del方法，然而此方法內含有keys命令。
redis
是單執行緒服務，這樣的命令，導致redis鎖住，導致cpu飆公升，引起所有支付鏈路卡住，等十幾秒結束後，所有的請求流量全部擠壓到了rds資料庫中，使資料庫產生了雪崩效應，發生了資料庫宕機事件。
由於之前驗收環境快取量小，未發現此影響其他服務響應延遲的問題。
運維表示之後會逐步收回運維部各項許可權！
二、一條鐵律
在業內，redis開發規範中有一條鐵律如下所示：
線上redis禁止使用keys正則匹配操作！
三、深度分析1
、redis是單執行緒的，其所有操作都是原子的，不會因併發產生資料異常； 2
、使用高耗時的redis命令是很危險的，會占用唯一的乙個執行緒的大量處理時間，導致所有的請求都被拖慢。（例如時間複雜度為o(n)的keys命令，嚴格禁止在生產環境中使用）；
有上面兩句作鋪墊，原因就顯而易見了！
需要注意的是，同樣危險的命令不僅有keys *，還有以下幾組：
因此，乙個合格的redis運維或者開發，應該懂得如何禁用上面的命令。所以我一直覺得出現新聞中那種情況的原因，一般是人員的水平問題。
四、怎麼禁用這些命令呢？
就是在redis.conf中，在security這一項中，我們新增以下命令：
注意了，上面的這些命令可能有遺漏，大家可以查官方文件。除了flushdb這類和redis安全隱患有關的命令意外，但凡發現時間複雜度為o(n)的命令，都要慎重，不要在生產上隨便使用。例如hgetall、lrange、smembers、zrange、sinter等命令，它們並非不能使用，但這些命令的時間複雜度都為o(n)，使用這些命令需要明確n的值，否則也會出現快取宕機。
五、改良建議
業內置議使用scan命令來改良keys和smembers命令：
redis2.8
版本以後有了乙個新命令scan，可以用來分批次掃瞄redis記錄，這樣肯定會導致整個查詢消耗的總時間變大，但不會影響redis服務卡頓，影響服務使用。
Redis基礎三 Keys命令
常用命令 keys 返回滿足給定pattern 的所有key redis 127.0.0.1 6379 keys mylist 1 mylist 2 mylist5 3 mylist6 4 mylist7 5 mylist8 exists 確認乙個key 是否存在 示例 從結果來看，資料庫中不存在h...
redis 命令遠端批量刪除keys
1.首先在電腦上裝上 redis 客戶端 2.安裝成功後,進入 redis cli 客戶端目錄 連線 redis 1.redis 4.0.7 cd bin 執行 redis service 開啟 redis 資料庫 2.cd bin redis cli 開啟控制台 執行命令 redis cli h ...
Redis 千萬不要亂用KEYS命令，不然會挨打的
redis現如今使用的場景越來越多？如何批量刪除key呢？有人說用keys命令，剛開始學redis的時候就是用這個命令列出庫中鍵。keys命令要謹慎使用。為何？客觀別急，我們先一步步來看。上面是官方文件宣告，keys命令不能用在生產的環境中，這個時候如果數量過大效率是十分低的。同時也不要用keys正...