热门新闻事件或商品通常会给系统带来巨大的流量，对存储这类信息的Redis来说却是一个巨大的挑战。以Redis Cluster为例，它会造成整体流量的不均知，个别节点出现OPS过大的情况，极端情况下热点key甚至会超过Redis本身能够承受的OPS, 因此寻找热点key对于开发和运维人员非常重要。下面就从四个方面来分析热点key。

1.客户端

　　客户端其实是距离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);
      ...
}

　　同时为了防止 atomic_long_map过大，可以对其进行定期清理。

public void scheduleCleanMap() {
         ERROR_NAME_VALUE_MAP.clear();
}

　　使用客户端进行热点key的统计非常容易实现，但是同时问题也非常多：

□ 无法预知key的个数，存在内存泄露的危险。

□ 对于客户端代码有侵人，各个语言的客户端都需要维护此逻辑，维护成本较高。

□ 只能了解当前客户端的热点key, 无法实现规模化运维统计。

　　当然除了使用本地字典计数外，还可以使用其他存储来完成异步计数，从而解决本地内存泄露问题。但是另两个问题还是不好解决。

2.代理端

　　像Twemproxy、Codis这些基于代理的Redis分布式架构，所有客户端的请求都是通过代理端完成的，此架构是最适合做热点key统计的，因为代理是所有Redis客户端和服务端的桥梁。但并不是所有Redis都是采用此种架构。

3.Redis 服务端

　　使用monitor命令统计热点 key 是很多开发和运维人员首先想到，monitor命令可以监控到 Redis 执行的所有命令，下面为一次monitor命令执行后部分结果:

1477638175.920489 [0 10.16.xx.183:54465] "GET" "tab:relate:kp:162818"
1477638175.925794 [0 10.10.xx.14:35334] "HGETALL" "rf:vl:84083217_83727736"
1477638175.938106 [0 10.16.xx.180:60413] "GET" "tab:relate:kp:900"
1477638175.939651 [0 10.16.xx.183:54320] "GET" "tab:relate:kp:15907"
1477638175.962519 [0 10.10.xx.14:35334] "GET" "tab:relate:kp:3079"
1477638175.963216 [0 10.10.xx.14:35334] "GET" "tab:relate:kp:3079"
1477638175.964395 [0 10.10.xx.204:57395] "HGETALL"  "rf:vl:80547158_83076533"

　　如图12-6所示，利用monitor命令的结果就可以统计出一段时间内的热点key排行榜、命令排行榜、客户端分布等数据，例如下面的伪代码统计了最近10万条命令中的热点 key:

//获取10万条命令
List<String> keyList = redis.monitor(100000);
//存入到字典中,分别是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尽可能在本机执行。

redis-cli -p 6380 monitor | head -n 100000 |  ./redis-faina.py
Overall Stats
=============================
Lines Processed 50000
Commands/Sec 900,48
Top Prefixes
=============================
tab 27565 (55.13%)
rf    15111 (30.22%)
ugc  2051 (4.10 %)
....
Top Keys
=============================
tab:relate:kp:9350 2110 (4.22%)
tab:relate:kp:15907 1594 (3.19%)
....
Top Commands
=============================
GET 25700 (51.40%)
HGETALL 15111 (30.22%)
...
Command Time (microsecs)
=============================
Median 622.75
75% 1504.0
90% 2820.0
99% 6798.0

　　此种方法会有两个问题：

□ 此前多次强调monitor命令在高并发条件下，会存在内存暴增和影响Redis性能的隐患，所以此种方法适合在短时间内使用。

□ 只能统计一个Redis节点的热点key，对于Redis集群需要进行汇总统计。

4.机器

　　Redis客户端使用TCP协议与服务端进行交互，通信协议采用的是RESP。如果站在机器的角度，可以通过对机器上所有Redis端口的TCP数据包进行抓取完成热点key的统计。

　　此种方法对于Redis客户端和服务端来说毫无侵入，是比较完美的方案，但是依然存在两个问题：

□ 需要一定的开发成本，但是一些开源方案实现了该功能，例如ELK(ElasticSearchLogstashKibana)体系下的packetbeat插件，可以实现对Redis、MySQL等众多主流服务的数据包抓取、分析、报表展示。

□ 由于是以机器为单位进行统计，要想了解一个集群的热点key, 需要进行后期汇总。

　　最后通过表12-5给出上述四种方案的特点。

　　最后我们总结出解决热点key问题的三种方案。选用哪种要根据具体业务场景来决定。下面是三种方案的思路。

1) 拆分复杂数据结构：如果当前key的类型是一个二级数据结构，例如哈希类型。如果该哈希元素个数较多，可以考虑将当前hash进行拆分，这样该热点key可以拆分为若干个新的 key 分布到不同 Redis 节点上，从而减轻压力。

2) 迁移热点key: 以Redis Cluster 为例，可以将热点 key 所在的 slot 单独迁移到一个新的Redis节点上，但此操作会增加运维成本。

3) 本地缓存加通知机制：可以将热点 key 放在业务端的本地缓存中，因为是在业务端的本地内存中，处理能力要高出 Redis 数十倍，但当数据更新时，此种模式会造成各个业务端和 Redis 数据不一致，通常会使用发布订阅机制来解决类似问题。