热门新闻事件或商品通常会给系统带来巨大的流量,对存储这类信息的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给出上述四种方案的特点。

表 12-5 寻找热点key的四种方案

方案

优点

缺点

客户端

实现简单

内存泄露隐患

维护成本高

只能统计单个客户端

代理

代理是客户端和服务端的桥梁,实

现最方便最系统

增加代理端的开发部署成本

服务端

实现简单

Monitor本身的使用成本和危害,只能短时间使用

只能统计单个Redis节点

机器

对于客户端和服务端无侵入和影响

需要专业的运维团队开发,并且增加了机器的部署成本

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

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

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

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

Redis热点key优化的更多相关文章

  1. Redis热点Key发现及常见解决方案!

    一.热点Key问题产生的原因 1.用户消费的数据远大于生产的数据(热卖商品.热点新闻.热点评论.明星直播). 在日常工作生活中一些突发的的事件,例如:双十一期间某些热门商品的降价促销,当这其中的某一件 ...

  2. 如何发现 Redis 热点 Key ,解决方案有哪些?

    Java技术栈 www.javastack.cn 优秀的Java技术公众号 来源:http://t.cn/EAEu4to 一.热点问题产生原因 热点问题产生的原因大致有以下两种: 1.1 用户消费的数 ...

  3. Redis雪崩、穿透、热点key等优化

    一.缓存 Redis做缓存是最常见的应用场景.客户端请求在缓存层命中就直接返回,如果miss就去读取存储层,存储层读取到就写入缓存层,然后再返回到客户端. 优点: 加速读写 降低后端负载 缺点: 数据 ...

  4. 第三节:Redis缓存雪崩、击穿、穿透、双写一致性、并发竞争、热点key重建优化、BigKey的优化 等解决方案

    一. 缓存雪崩 1. 含义 同一时刻,大量的缓存同时过期失效. 2. 产生原因和后果 (1). 原因:由于开发人员经验不足或失误,大量热点缓存设置了统一的过期时间. (2). 产生后果:恰逢秒杀高峰, ...

  5. Redis缓存雪崩、缓存穿透、热点Key解决方案和分析

    缓存穿透 缓存系统,按照KEY去查询VALUE,当KEY对应的VALUE一定不存在的时候并对KEY并发请求量很大的时候,就会对后端造成很大的压力. (查询一个必然不存在的数据.比如文章表,查询一个不存 ...

  6. Redis(十二)flush误操作、Redis安全、处理bigkey和寻找热点key

    一.flushall/flushdb误操作的处理 假设进行flush操作的Redis是一对主从结构的主节点,其中键值对的个数是100万,每秒写入量是1000. 1.缓存与存储 被误操作flush后,根 ...

  7. Redis缓存雪崩,缓存穿透,热点key解决方案和分析

    缓存穿透 缓存系统,按照KEY去查询VALUE,当KEY对应的VALUE一定不存在的时候并对KEY并发请求量很大的时候,就会对后端造成很大的压力. (查询一个必然不存在的数据.比如文章表,查询一个不存 ...

  8. Redis缓存雪崩、缓存穿透、热点key

    转载自  https://blog.csdn.net/wang0112233/article/details/79558612 https://www.sohu.com/a/230787856_231 ...

  9. REDIS 缓存的穿透,雪崩和热点key

    穿透 穿透:频繁查询一个不存在的数据,由于缓存不命中,每次都要查询持久层.从而失去缓存的意义. 解决办法:①用一个bitmap和n个hash函数做布隆过滤器过滤没有在缓存的键.   ②持久层查询不到就 ...

随机推荐

  1. .Net平台的GC垃圾回收

    一.先了解下必备的知识前提 内存中的托管与非托管,可简单理解为: 托管:可借助GC从内存中释放的数据对象(以下要描述的内容点) 非托管:必须手工借助Dispose释放资源(实现自IDisposable ...

  2. mysql知识点归纳-锁(死锁)

    愿历尽千帆,归来仍是少年 所遇问题: MySql 更新死锁问题 Deadlock found when trying to get lock; try restarting transaction 场 ...

  3. 前端Node的实用方法

    Node 一.什么是Node Node是以基于Chrome V8引擎的JavaScript运行环境,使用了一个事件驱动.非阻塞式I/O模型(I/O是 input/output的缩写,即输入输出端口,在 ...

  4. python3.7[列表] 索引切片

    python3.7[列表] 索引  切片 排序     #### 列表.sort 永久排序   sorted(列表) 临时排序   ### >>> print(sorted(a))[ ...

  5. (代替人类)很多操作都在Settings里面。 5.安装第三方库

    2020-02-01 pycharm 使用教程 LingSmart关注 0.0842020.02.07 15:08:50字数 1,394阅读 680 实在无聊,就来学习吧.学习pycharm的使用教程 ...

  6. tail -n 13 history |awk '{print $2,$3,$4,$5,$6,$7,$8.$9,$10}'提取第2到第11列

    # cat history |awk '{print $2,$3,$4,$5,$6,$7,$8.$9,$10}' # tail -n 13 history 215 systemctl stop 216 ...

  7. 攻防世界(五)Web_php_include

    攻防世界系列:Web_php_include 方法一:大小写绕过 strstr()函数对php我协议进行了过滤,但我们可以尝试大小写绕过 抓包POST传值让其执行我们输入的命令 ?page=Php:/ ...

  8. FreeRTOS相关转载-(朱工的专栏)

    FreeRTOS系列第1篇---为什么选择FreeRTOS? 1.为什么学习RTOS? 作为基于ARM7.Cortex-M3硬件开发的嵌入式工程师,我一直反对使用RTOS.不仅因为不恰当的使用RTOS ...

  9. Mybatis学习-GetMybatisInMyHead

    认知 Mybatis3 中文文档 练习代码 ​ MyBatis 是一款优秀的持久层框架,它支持自定义 SQL.存储过程以及高级映射.MyBatis 免除了几乎所有的 JDBC 代码以及设置参数和获取结 ...

  10. GO学习-(32) Go实现日志收集系统1

    Go实现日志收集系统1 项目背景 每个系统都有日志,当系统出现问题时,需要通过日志解决问题 当系统机器比较少时,登陆到服务器上查看即可满足 当系统机器规模巨大,登陆到机器上查看几乎不现实 当然即使是机 ...