Redis鍵值設計
優雅的key結構
Redis的Key雖然可以自定義，到但是最好遵循下面的幾個最佳實踐約定：
l 遵循基本格式：[業務名稱]:[資料名]:[id]
l 長度不超過44位元組（長度越小，佔用的記憶體越少）
l 不包含特殊字元
優點：
① 可讀性強
② 避免key衝突
③ 方便管理
④ 更節省記憶體：key是string型別，底層編碼包含int、embstr和raw三種。embstr在小於44位元組使用，採用連續記憶體空間，記憶體佔用更小。
拒絕BigKey
BigKey通常以Key的大小和Key中成員的數量來綜合判定，例如：
l Key本身的資料量過大：一個String型別的Key，它的值為5MB。
l Key中的成員數過多：一個ZSET型別的Key，它的成員數量為10000個。
l Key中成員的資料量過大：一個Hash型別的Key，它的成員數量雖然只有1000個但這些成員的Value(值)總大小為100MB。
判斷Key的大小
上面的命令對CPU的使用率比較高
透過字串長度判斷大小
集合透過集合中元素數量的方式來衡量
推薦值：
l 單個Key的value小於10KB
l 對於集合型別的Key，建議元素數量小於1000
BigKey的危害
n 網路阻塞
對BigKey執行讀請求時，少量的QPS就可能導致頻寬使用率被佔滿，導致Redis例項，乃至所在物理機變慢
n 資料傾斜
BigKey所在的Redis例項記憶體使用率遠超其他例項，無法使用資料分片的記憶體資源達到均衡
n Redis阻塞
對元素較多的hash、list、zset等做運算會耗時較久，使主執行緒被阻塞
n CPU壓力
對BigKey的資料序列化和反序列化會導致CPU的使用率飆升，影響Redis例項和本機其它應用
如何發現BigKey
n redis-cli-bigkeys
利用reids-cli提供的--bigkeys引數，可以遍歷分析所有key，並返回Key的整體統計資訊與每個資料的Top1的big key
n scan掃描
自己程式設計，利用scan掃描Redis中所有key，利用strlen、hlen等命令判斷key的長度（此處不建議使用MEMORY USAGE）
n 第三方工具
利用第三方工具，如Redis-Rdb-Tools分析RDB快照分析，全面分析記憶體使用情況
n 網路監控
自定義工具，監控進出Redis的網路資料，超出預警值時主動告警
如何刪除BigKey
BigKey記憶體佔用較多，即便是刪除這樣的key也需要耗費很長時間，導致redis主執行緒阻塞，引發一系列問題。
Reids3.0及以下版本
如果是集合型別，則遍歷BigKey的元素，先逐個刪除子元素，最後刪除BigKey
Redis4.0以後
Redis在4.0後提供了非同步刪除的命令：unlink
恰當的資料型別
如何選擇合適的資料型別
