尋找熱點key
熱門新聞事件或商品通常會給系統帶來巨大的流量，對存儲這類信息的Redis來說卻是一個巨大的挑戰。以Redis Cluster為例，它會造成整體流量的不均衡，個別節點出現OPS過大的情況，極端情況下熱點key甚至會超過Redis本身能夠承受的OPS，因此尋找熱點key對于開發和運維人員非常重要。下面就會從四個方面來分析熱點key。
-
客戶端
客戶端其實是距離key“最近”的地方，因為Redis命令就是從客戶端發出的，例如在客戶端設置全局字典（key和調用次數），每次調用Redis命令是，使用這個字典進行記錄，如下所示。
// 使用Guava的AtomicLongMap，記錄key的調用次數 public static final AtomicLongMap<String> ATOMIC_LONG_MAP = AtomicLongMap.create(); String get(String key) { counterKey(key); ... } String set(String key, String value) { counterKey(key); ... } void counterKey(String key) { ATOMIC_LONG_MAP.incrementAndGet(key); }為了減少對客戶端代碼的侵入，可以在Redis客戶端的關鍵部分進行計數，例如Jedis的Connection類中的sendCommand方法是所有命令執行的樞紐：
public Connection sendCommand(final ProtocolCommand cmd, final byte[]... args) { //從參數中獲取key String key = analysis(args); //計數 counterKey(key); ... }同時為了防止ATVOMIC_LONG_MAP過大，可以對其進行定期清理。
public void scheduleCleanMap() { ERROR_NAME_VALUE_MAP.clear(); }使用客戶端進行熱點key的統計非常容易發現，但是同時問題也非常多：
無法預知key的個數，存在內存泄露的危險。
對于客戶端代碼有侵入，各個語言的客戶端都需要維護此邏輯，維護成本較高。
只能了解當前客戶端的熱點key，無法實現規?；\維統計。
當然除了使用本地字典技術外，還可以使用其他存儲來完成異步計數，從而解決本地內存泄露問題。但是另兩個問題還是不好解決。
-
代理端
像Twemproxy、Codis這些基于代理的Redis分布式架構，所有客戶端的請求都是通過代理端完成的。此構架是最適合做熱點key統計的，因為代理是所有Redis客戶端和服務端的橋梁。但并不是所有Redis都是采用此種架構。
-
Redis服務端
使用monitor命令統計熱點key是很多很多開發和運維人員首先想到，monitor命令可以監控到Redis執行的所有命令。
利用monitor命令的結果就可以統計出一段時間內的熱點key排行榜、命令排行榜、客戶端分布等數據，例如下面的偽代碼統計了最近10萬條命令中的熱點key：
//獲取10萬條命令 List<String> keyList = redis.monitor(10000); //存入到字典中，分別是key和對應的次數 AtomicLongMap<String> ATOMIC_LONG_MAP = AtomicLongMap.create(); //統計 for (String command : commandList) { ATOMIC_LONG_MAP.incrementAndGet(key); } //后續統計和分析熱點key statHotKey(ATOMIC_LONG_MAP);Facebook開源的redis-faina正是利用上述原理使用Python語言實現的，例如下面獲取最近10萬條命令的熱點key、熱點命令、耗時分布等數據。為了減少網絡開銷以及加快輸出緩沖區的消費速度，monitor盡可能在本機執行。
此種方法會有兩個問題：
本書多次強調monitor命令在高并發條件下，會存在內存暴增和影響Redis性能的隱患，所以此種方法適合在短時間內使用。
只能統計一個Redis節點的熱點key，對于Redis集群需要進行匯總統計。
-
機器
Redis客戶端會使用TCP協議與服務端進行交互，通信協議采用的是RESP。如果站在機器的角度，可以通過對機器上所有Redis端口的TCP數據包進行抓取完成熱點key的統計。
此種方法對于Redis客戶端服務端來說毫無侵入，是比較完美的方案，但是依然存在兩個問題：
需要一定的開發成本，但是一些開源方案實現了該功能，例如ELK（ElasticSearch Logstash Kibana）體系下的packetbeat插件，可以實現對Redis、MySQL等眾多主流服務的數據包抓取、分析、報表展示。
由于是以機器為單位進行統計，要想了解一個集群的熱點key，需要進行后期匯總。
方案 優點 缺點 客戶端 實現簡單 1.內存泄露隱患 2.維護成本高 3.只能統計單個客戶端 代理 代理是客戶端和服務端的橋梁，實現最方便最系統 增加代理端的開發部署成本 服務端 實現簡單 1.Monitor本身的使用成本和危害，只能短時間使用 2.只能統計的單個Redis節點 機器 對于客戶端和服務端無侵入和影響 需要專業的運維團隊開發，并且增加了機器的部署成本 最后我們總結出解決熱點key問題的三種方案。選用哪種要根據具體業務場景來決定。下面是三種方案的思路。
1）拆分復雜數據結構：如果當前key的類型是一個二級數據結構，例如哈希類型。如果該哈希元素個數較多，可以考慮將當前hash進行拆分，這樣該熱點key可以拆分為若干個新的key分布到不同Redis節點上，從而減輕壓力。
2）遷移熱點key：以Redis Cluster為例，可以將熱點key所在的slot單獨遷移到一個新的Redis節點上，但此操作會增加運維成本。
3）本地緩存加通知機制：可以將熱點key放在業務端的本地緩存中，因為是在業務端的本地內存中，處理能力要高出Redis數十倍，但當數據更新時，此種模式會造成各個業務端和Redis數據不一致，通常會使用發布訂閱機制來解決類型問題。
