寻找热点key1、客户端2、代理端3、Redis服务端4、机器热门新闻事件或商品通常会给系统带来巨大的流量对存储这类信息的Redis来说却是一个巨大的挑战。以Redis Cluster为例它会造成整体流量的不均衡个别节点出现OPS过大的情况极端情况下热点key甚至会超过Redis本身能够承受的OPS因此寻找热点key对于开发和运维人员非常重要。下面就从四个方面来分析热点key。1、客户端客户端其实是距离key“最近”的地方因为Redis命令就是从客户端发出的例如在客户端设置全局字典key和调用次数每次调用Redis命令时使用这个字典进行记录如下所示。// 使用Guava的AtomicLongMap,记录key的调用次数publicstaticfinalAtomicLongMapStringATOMIC_LONG_MAPAtomicLongMap.create();Stringget(Stringkey){counterKey(key);…}Stringset(Stringkey,Stringvalue){counterKey(key);…}voidcounterKey(Stringkey){ATOMIC_LONG_MAP.incrementAndGet(key);}为了减少对客户端代码的侵入可以在Redis客户端的关键部分进行计数例如Jedis的Connection类中的sendCommand方法是所有命令执行的枢纽publicConnectionsendCommand(finalProtocolCommandcmd,finalbyte[]… args){// 从参数中获取keyStringkeyanalysis(args);// 计数counterKey(key);…}同时为了防止ATvOMIC_LONG_MAP过大可以对其进行定期清理。publicvoidscheduleCleanMap(){ERROR_NAME_VALUE_MAP.clear();}使用客户端进行热点key的统计非常容易实现但是同时问题也非常多无法预知key的个数存在内存泄露的危险。对于客户端代码有侵入各个语言的客户端都需要维护此逻辑维护成本较高。只能了解当前客户端的热点key无法实现规模化运维统计。当然除了使用本地字典计数外还可以使用其他存储来完成异步计数从而解决本地内存泄露问题。但是另两个问题还是不好解决。2、代理端像Twemproxy、Codis这些基于代理的Redis分布式架构所有客户端的请求都是通过代理端完成的如图所示。此架构是最适合做热点key统计的因为代理是所有Redis客户端和服务端的桥梁。但并不是所有Redis都是采用此种架构。3、Redis服务端使用monitor命令统计热点key是很多开发和运维人员首先想到monitor命令可以监控到Redis执行的所有命令下面为一次monitor命令执行后部分结果1477638175.920489[010.16.xx.183:54465]GETtab:relate:kp:1628181477638175.925794[010.10.xx.14:35334]HGETALLrf:v1:84083217_837277361477638175.938106[010.16.xx.180:60413]GETtab:relate:kp:9001477638175.939651[010.16.xx.183:54320]GETtab:relate:kp:15907…1477638175.962519[010.10.xx.14:35334]GETtab:relate:kp:30791477638175.963216[010.10.xx.14:35334]GETtab:relate:kp:30791477638175.964395[010.10.xx.204:57395]HGETALLrf:v1:80547158_83076533如图所示利用monitor命令的结果就可以统计出一段时间内的热点key排行榜、命令排行榜、客户端分布等数据例如下面的伪代码统计了最近10万条命令中的热点key// 获取10万条命令ListStringkeyListredis.monitor(100000);// 存入到字典中分别是key和对应的次数AtomicLongMapStringATOMIC_LONG_MAPAtomicLongMap.create();// 统计for(Stringcommand:commandList){ATOMIC_LONG_MAP.incrementAndGet(key);}// 后续统计和分析热点keystatHotKey(ATOMIC_LONG_MAP);Facebook开源的redis-faina[插图]正是利用上述原理使用Python语言实现的例如下面获取最近10万条命令的热点key、热点命令、耗时分布等数据。为了减少网络开销以及加快输出缓冲区的消费速度monitor尽可能在本机执行。redis-cli-p6380monitor|head-n100000|./redis-faina.py Overall StatsLines Processed50000Commands/Sec900.48Top Prefixestab27565(55.13%)rf15111(30.22%)ugc2051(4.10%)… Top Keystab:relate:kp:93502110(4.22%)tab:relate:kp:159071594(3.19%)… Top CommandsGET25700(51.40%)HGETALL15111(30.22%)… Command Time(microsecs)Median622.7575%1504.090%2820.099%6798.0此种方法会有两个问题monitor命令在高并发条件下会存在内存暴增和影响Redis性能的隐患所以此种方法适合在短时间内使用。只能统计一个Redis节点的热点key对于Redis集群需要进行汇总统计。4、机器Redis客户端使用TCP协议与服务端进行交互通信协议采用的是RESP。如果站在机器的角度可以通过对机器上所有Redis端口的TCP数据包进行抓取完成热点key的统计如图所示。此种方法对于Redis客户端和服务端来说毫无侵入是比较完美的方案但是依然存在两个问题需要一定的开发成本但是一些开源方案实现了该功能例如ELK(ElasticSearch Logstash Kibana)体系下的packetbeat插件可以实现对Redis、MySQL等众多主流服务的数据包抓取、分析、报表展示。由于是以机器为单位进行统计要想了解一个集群的热点key需要进行后期汇总。最后通过下表给出上述四种方案的特点。最后我们总结出解决热点key问题的三种方案。选用哪种要根据具体业务场景来决定。下面是三种方案的思路。拆分复杂数据结构如果当前key的类型是一个二级数据结构例如哈希类型。如果该哈希元素个数较多可以考虑将当前hash进行拆分这样该热点key可以拆分为若干个新的key分布到不同Redis节点上从而减轻压力。迁移热点key以Redis Cluster为例可以将热点key所在的slot单独迁移到一个新的Redis节点上但此操作会增加运维成本。本地缓存加通知机制可以将热点key放在业务端的本地缓存中因为是在业务端的本地内存中处理能力要高出Redis数十倍但当数据更新时此种模式会造成各个业务端和Redis数据不一致通常会使用发布订阅机制来解决类似问题。