工作中，經常有些Redis實例使用不恰當，或者對業務預估不準確，或者key沒有及時進行處理等等原因，導致某些KEY相當大。
那麽大Key會帶來哪些問題呢？

1. 如果是集群模式下，無法做到負載均衡，導致請求傾斜到某個實例上，而這個實例的QPS會比較大，內存占用也較多；對於Redis單線程模型又容易出現CPU瓶頸，當內存出現瓶頸時，只能進行縱向庫容，使用更牛逼的服務器。
2. 涉及到大key的操作，尤其是使用hgetall、lrange 0 -1、get、hmget 等操作時，網卡可能會成為瓶頸，也會到導致堵塞其它操作，qps 就有可能出現突降或者突升的情況，趨勢上看起來十分不平滑，嚴重時會導致應用程序連不上，實例或者集群在某些時間段內不可用的狀態。
3. 假如這個key需要進行刪除操作，如果直接進行DEL 操作，被操作的實例會被Block住，導致無法響應應用的請求，而這個Block的時間會隨著key的變大而變長。

有以下幾種辦法可以知道某個Redis實例是否存在大key：

1. 在redis實例上執行bgsave，然後我們對dump出來的rdb文件進行分析，找到其中的大KEY
2. 有個不太推薦的命令，debug object xxx 可以看到這個key在內存中序列化後的大小，當然我們可以通過SCAN+debug object xxx 得到當前實例所有key的大小。
3. redis-cli 原生自帶 –bigkeys 功能，可以找到某個實例 5種數據類型(String、hash、list、set、zset)的最大key。

通過Redis-cli –bigkeys 我們可以很方便的找到某個實例最大的幾個KEY，但是只能得到某種類型的最大的一個key，於是思考改改redis-cli findBigKeys 功能，增加查找多個key的代碼，用戶可以指定大key的數量。

修改後功能預覽如下：

VITOXIE-MB1:src xiean$ ./redis-cli-new -p 2837 --bigkeys --bigkey-numb  3

Biggest string Key Top   1  found ‘xxxG_NEWMATCH_VOD_DATA_7f7a2a2fb5f780a13fecd9f1e51bdf8a‘ has 53170 bytes
Biggest string Key Top   2  found ‘xxxG_NEWMATCH_VOD_DATA_a9758560d1874493c637dec0753909da‘ has 53159 bytes
Biggest string Key Top   3  found ‘xxxG_NEWMATCH_VOD_DATA_d0971977b0ce028141e53b020b93d822‘ has 53156 bytes
Biggest   list Key Top   1  found ‘UserPostInfo122_632789064‘ has 11028 items
Biggest   list Key Top   2  found ‘xxxG_FriendCallBack_PushList_23‘ has 1973 items
Biggest   list Key Top   3  found ‘xxxG_FriendCallBack_PushList_20‘ has 1824 items
 

ps，修改的源碼放在GitHub上，這裏還部分dba日常實用工具：https://github.com/xiepaup/OPS-Tools ，歡迎探討。

如何提取Redis中的大KEY