Redis入门完整教程:寻找热点key
热门新闻事件或商品通常会给系统带来巨大的流量,对存储这类信息的Redis来说却是一个巨大的挑战。以Redis Cluster为例,它会造成整体流量的不均衡,个别节点出现OPS过大的情况,极端情况下热点key甚至会超过Redis本身能够承受的OPS,因此寻找热点key对于开发和运维人员非常重要。下面就从四个方面来分析热点key。1.客户端客户端其实是距离key“最近”的地方,因为Redis命令就是从
热门新闻事件或商品通常会给系统带来巨大的流量,对存储这类信息的
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);
...
}
同时为了防止ATvOMIC_LONG_MAP过大,可以对其进行定期清理。
public void scheduleCleanMap() {
ERROR_NAME_VALUE_MAP.clear();
}
使用客户端进行热点key的统计非常容易实现,但是同时问题也非常
多:
·无法预知key的个数,存在内存泄露的危险。
·对于客户端代码有侵入,各个语言的客户端都需要维护此逻辑,维护
成本较高。
·只能了解当前客户端的热点key,无法实现规模化运维统计。
当然除了使用本地字典计数外,还可以使用其他存储来完成异步计数,
从而解决本地内存泄露问题。但是另两个问题还是不好解决。
2.代理端
像Twemproxy、Codis这些基于代理的Redis分布式架构,所有客户端的
请求都是通过代理端完成的,如图12-5所示。此架构是最适合做热点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:v1: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:v1: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 [1] 正是利用上述原理使用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.机器
4.1节我们介绍过,Redis客户端使用TCP协议与服务端进行交互,通信
协议采用的是RESP。如果站在机器的角度,可以通过对机器上所有Redis端
口的TCP数据包进行抓取完成热点key的统计,如图12-7所示。
此种方法对于Redis客户端和服务端来说毫无侵入,是比较完美的方
案,但是依然存在两个问题:
784
·需要一定的开发成本,但是一些开源方案实现了该功能,例如
ELK(ElasticSearch Logstash Kibana)体系下的packetbeat [2] 插件,可以实现
对Redis、MySQL等众多主流服务的数据包抓取、分析、报表展示。
·由于是以机器为单位进行统计,要想了解一个集群的热点key,需要进
行后期汇总。
最后通过表12-5给出上述四种方案的特点。
最后我们总结出解决热点key问题的三种方案。选用哪种要根据具体业
务场景来决定。下面是三种方案的思路。
1)拆分复杂数据结构:如果当前key的类型是一个二级数据结构,例如
哈希类型。如果该哈希元素个数较多,可以考虑将当前hash进行拆分,这样
该热点key可以拆分为若干个新的key分布到不同Redis节点上,从而减轻压
力。
2)迁移热点key:以Redis Cluster为例,可以将热点key所在的slot单独
迁移到一个新的Redis节点上,但此操作会增加运维成本。
3)本地缓存加通知机制:可以将热点key放在业务端的本地缓存中,因
为是在业务端的本地内存中,处理能力要高出Redis数十倍,但当数据更新
时,此种模式会造成各个业务端和Redis数据不一致,通常会使用发布订阅
机制来解决类似问题。
[1] https://github.com/facebookarchive/redis-faina
[2] https://www.elastic.co/products/beats/packetbeat
12.6 本章重点回顾
1)Linux相关优化:
·vm.overcommit_memory建议为1。
·Linux>3.5,vm.swappiness建议为1,否则建议为0。
·Transparent Huge Pages(THP)建议关闭掉,但需要注意Linux发行版本
改变了THP的配置位置。
·可以为Redis进程设置oom_adj,减少Redis被OOM killer杀掉的概率,
但不要过度依赖此特性。
·建议对Redis所有节点所在机器使用NTP服务。
·设置合理的ulimit保证网络连接正常。
·设置合理的tcp-backlog参数。
2)理解Redis的持久化有助于解决flush操作之后的数据快速恢复问题。
3)Redis安全建议:
·根据具体网络环境决定是否设置Redis密码。
·rename-command可以伪装命令,但是要注意成本。
·合理的防火墙是防止攻击的利器。
787
·bind可以将Redis的访问绑定到指定网卡上。
·定期备份数据应该作为习惯性操作。
·可以适当错开Redis默认端口启动。
·使用非root用户启动Redis。
4)bigkey的危害不容忽视:数据倾斜、超时阻塞、网络拥塞,可能是
Redis生产环境中的一颗定时炸弹,删除bigkey时通常使用渐进式遍历的方
式,防止出现Redis阻塞的情况。
5)通过客户端、代理、monitor、机器抓包四种方式找到热点key,这几
种方式各具优势,具体使用哪种要根据当前场景来决定。
更多推荐
所有评论(0)