谈谈redis的热key问题如何解决

引言

讲了几天的数据库系列的文章,大家一定看烦了,其实还没讲完。。。(以下省略一万字)。
今天我们换换口味,来写redis方面的内容,谈谈热key问题如何解决。
其实热key问题说来也很简单,就是瞬间有几十万的请求去访问redis上某个固定的key,从而压垮缓存服务的情情况。
其实生活中也是有不少这样的例子。比如XX明星结婚。那么关于XX明星的Key就会瞬间增大,就会出现热数据问题。
ps:hot key和big key问题,大家一定要有所了解。
本文预计分为如下几个部分

  • 热key问题
  • 如何发现
  • 业内方案

正文

热Key问题

上面提到,所谓热key问题就是,突然有几十万的请求去访问redis上的某个特定key。那么,这样会造成流量过于集中,达到物理网卡上限,从而导致这台redis的服务器宕机。
那接下来这个key的请求,就会直接怼到你的数据库上,导致你的服务不可用。

怎么发现热key

方法一:凭借业务经验,进行预估哪些是热key
其实这个方法还是挺有可行性的。比如某商品在做秒杀,那这个商品的key就可以判断出是热key。缺点很明显,并非所有业务都能预估出哪些key是热key。
方法二:在客户端进行收集
这个方式就是在操作redis之前,加入一行代码进行数据统计。那么这个数据统计的方式有很多种,也可以是给外部的通讯系统发送一个通知信息。缺点就是对客户端代码造成入侵。
方法三:在Proxy层做收集
有些集群架构是下面这样的,Proxy可以是Twemproxy,是统一的入口。可以在Proxy层做收集上报,但是缺点很明显,并非所有的redis集群架构都有proxy。

方法四:用redis自带命令
(1)monitor命令,该命令可以实时抓取出redis服务器接收到的命令,然后写代码统计出热key是啥。当然,也有现成的分析工具可以给你使用,比如redis-faina。但是该命令在高并发的条件下,有内存增暴增的隐患,还会降低redis的性能。
(2)hotkeys参数,redis 4.0.3提供了redis-cli的热点key发现功能,执行redis-cli时加上–hotkeys选项即可。但是该参数在执行的时候,如果key比较多,执行起来比较慢。
方法五:自己抓包评估
Redis客户端使用TCP协议与服务端进行交互,通信协议采用的是RESP。自己写程序监听端口,按照RESP协议规则解析数据,进行分析。缺点就是开发成本高,维护困难,有丢包可能性。

以上五种方案,各有优缺点。根据自己业务场景进行抉择即可。那么发现热key后,如何解决呢?

如何解决

目前业内的方案有两种
(1)利用二级缓存
比如利用ehcache,或者一个HashMap都可以。在你发现热key以后,把热key加载到系统的JVM中。
针对这种热key请求,会直接从jvm中取,而不会走到redis层。
假设此时有十万个针对同一个key的请求过来,如果没有本地缓存,这十万个请求就直接怼到同一台redis上了。
现在假设,你的应用层有50台机器,OK,你也有jvm缓存了。这十万个请求平均分散开来,每个机器有2000个请求,会从JVM中取到value值,然后返回数据。避免了十万个请求怼到同一台redis上的情形。
(2)备份热key
这个方案也很简单。不要让key走到同一台redis上不就行了。我们把这个key,在多个redis上都存一份不就好了。接下来,有热key请求进来的时候,我们就在有备份的redis上随机选取一台,进行访问取值,返回数据。
假设redis的集群数量为N,步骤如下图所示

注:不一定是2N,你想取3N,4N都可以,看要求。
伪代码如下

const M = N * 2
//生成随机数
random = GenRandom(0, M)
//构造备份新key
bakHotKey = hotKey + “_” + random
data = redis.GET(bakHotKey)
if data == NULL {
    data = GetFromDB()
    redis.SET(bakHotKey, expireTime + GenRandom(0,5))
}

业内方案

OK,其实看完上面的内容,大家可能会有一个疑问。

烟哥,有办法在项目运行过程中,自动发现热key,然后程序自动处理么?

嗯,好问题,那我们来讲讲业内怎么做的。其实只有两步
(1)监控热key
(2)通知系统做处理
正巧,前几天有赞出了一篇《有赞透明多级缓存解决方案(TMC)》,里头也有提到热点key问题,我们刚好借此说明
(1)监控热key
在监控热key方面,有赞用的是方式二:在客户端进行收集
在《有赞透明多级缓存解决方案(TMC)》中有一句话提到

TMC 对原生jedis包的JedisPool和Jedis类做了改造,在JedisPool初始化过程中集成TMC“热点发现”+“本地缓存”功能Hermes-SDK包的初始化逻辑。

也就说人家改写了jedis原生的jar包,加入了Hermes-SDK包。
那Hermes-SDK包用来干嘛?
OK,就是做热点发现本地缓存
从监控的角度看,该包对于Jedis-Client的每次key值访问请求,Hermes-SDK 都会通过其通信模块将key访问事件异步上报给Hermes服务端集群,以便其根据上报数据进行“热点探测”。

当然,这只是其中一种方式,有的公司在监控方面用的是方式五:自己抓包评估
具体是这么做的,先利用flink搭建一套流式计算系统。然后自己写一个抓包程序抓redis监听端口的数据,抓到数据后往kafka里丢。
接下来,流式计算系统消费kafka里的数据,进行数据统计即可,也能达到监控热key的目的。

(2)通知系统做处理
在这个角度,有赞用的是上面的解决方案一:利用二级缓存进行处理。
有赞在监控到热key后,Hermes服务端集群会通过各种手段通知各业务系统里的Hermes-SDK,告诉他们:"老弟,这个key是热key,记得做本地缓存。"
于是Hermes-SDK就会将该key缓存在本地,对于后面的请求。Hermes-SDK发现这个是一个热key,直接从本地中拿,而不会去访问集群。

除了这种通知方式以外。我们也可以这么做,比如你的流式计算系统监控到热key了,往zookeeper里头的某个节点里写。然后你的业务系统监听该节点,发现节点数据变化了,就代表发现热key。最后往本地缓存里写,也是可以的。

通知方式各种各样,大家可以自由发挥。本文只是提供一个思路。

总结

希望通过本文,大家明白如何处理生产上遇到的热key问题。

原文地址:https://www.cnblogs.com/leeego-123/p/11588429.html

时间: 2024-10-27 12:38:13

谈谈redis的热key问题如何解决的相关文章

利用redis replication实现redis服务器热迁移

利用redis replication实现redis服务器热迁移 文章开头我先声明:标题过于高大上,主要是为了装逼. 某个月黑风高的夜晚,一只运维攻城狮和一只PHP程序猿在促膝长谈,只见PHP程序猿双眼目光呆滞的盯着眼前屏幕上的一坨坨代码状文本,突然问出一句:"这个你会搞吗?"语气中透着一股程序猿的傲娇与对运维这一行业的轻蔑.攻城狮显然感觉到了空气中的那一缕杀气,但为了不给这个行业丢脸,攻城狮还是傲娇的仰头,冷冷的说:"我瞅瞅!" 问题是这样的,程序员他们公司最近要

redis运用连接池报错解决

redis使用连接池报错解决redis使用十几小时就一直报异常 redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool at redis.clients.util.Pool.getResource(Pool.java:22) at com.derbysoft.jredis.longkeytest.BorrowObject.run(BorrowObject.jav

高并发架构系列:Redis并发竞争key的解决方案详解

需求由来 1.Redis高并发的问题 Redis缓存的高性能有目共睹,应用的场景也是非常广泛,但是在高并发的场景下,也会出现问题:缓存击穿.缓存雪崩.缓存和数据一致性,以及今天要谈到的缓存并发竞争. 这里的并发指的是多个redis的client同时set key引起的并发问题. 2.出现并发设置Key的原因 Redis是一种单线程机制的nosql数据库,基于key-value,数据可持久化落盘.由于单线程所以Redis本身并没有锁的概念,多个客户端连接并不存在竞争关系,但是利用jedis等客户端

单点登录filter根据redis中的key判断是否退出

package com.ailk.biapp.ci.localization.cntv.filter; import java.io.IOException; import java.util.HashMap; import java.util.Map; import javax.servlet.FilterChain; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; imp

谈谈Redis的SETNX

在 Redis 里,所谓 SETNX,是「SET if Not eXists」的缩写,也就是只有不存在的时候才设置,可以利用它来实现锁的效果,不过很多人没有意识到 SETNX 有陷阱! 比如说:某个查询数据库的接口,因为调用量比较大,所以加了缓存,并设定缓存过期后刷新,问题是当并发量比较大的时候,如果没有锁机制,那么缓存过期的瞬间,大量并发请求会穿透缓存直接查询数据库,造成雪崩效应,如果有锁机制,那么就可以控制只有一个请求去更新缓存,其它的请求视情况要么等待,要么使用过期的缓存. 下面以目前 P

Putty使用公钥认证时,报错:Disconnected: No supported authentication methods available(server sent:public key) 问题的解决

Putty使用公钥认证时,按照常规方法设置,一直报错:Disconnected: No supported authentication methods available (server sent:public key). 如截图: 找了半天没找到问题出在哪里,sshd的设置一切正常.这个做过多次居然也能错???? 最后发现原来是 ~/.ssh/authorized_keys 文件的内容有问题,putty生成的pub文件的格式如下: ---- BEGIN SSH2 PUBLIC KEY ---

Redis遍历所有key的两个命令 -- KEYS 和 SCAN

当我们需要遍历Redis所有key或者指定模式的key时,首先想到的是KEYS命令: KEYS pattern   官网对于KEYS命令有一个提示: KEYS 的速度非常快,例如,Redis在一个有1百万个key的数据库里面执行一次查询需要的时间是40毫秒 .但在一个大的数据库中使用它仍然可能造成性能问题,如果你需要从一个数据集中查找特定的 KEYS, 你最好还是用 Redis 的集合结构 SETS 来代替. KEYS命令使用很简单. redis> MSET one 1 two 2 three

Redis 键(key)

Redis 键(key) Redis键命令用于管理redis的键. 语法 Redis键命令的基本语法如下: redis 127.0.0.1:6379> COMMAND KEY_NAME 实例 redis 127.0.0.1:6379> SET runoobkey redis OK redis 127.0.0.1:6379> DEL runoobkey (integer) 1     在以上实例中DEL是一个命令,runoobkey是一个键.如果键被删除成功,命令执行后输出(integer

解决redis运行期间key值过期但是内存memory依然占用过高

要解决这个问题,首先要了解redis info信息中几个数据的意义: used_memory:810575104 //数据占用了多少内存(字节) used_memory_human:773.02M //数据占用了多少内存(带单位的,可读性好) used_memory_rss:885465088  //redis占用了多少内存 used_memory_rss_human:844.45M //redis占用了多少内存(带单位的,可读性好) used_memory_peak:2001274696 //