<address id="fvpxj"><progress id="fvpxj"><font id="fvpxj"></font></progress></address>
    <address id="fvpxj"></address>

      <address id="fvpxj"><progress id="fvpxj"></progress></address>
      <sub id="fvpxj"></sub>

      <address id="fvpxj"></address>

        <track id="fvpxj"><big id="fvpxj"></big></track>

          <address id="fvpxj"><big id="fvpxj"><font id="fvpxj"></font></big></address>

          <dl id="fvpxj"><em id="fvpxj"><form id="fvpxj"></form></em></dl>

            【原创】谈谈redis的热key问题如何解决

            引言

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

            • 热key问题
            • 如何发现
            • ?#30340;?#26041;案

            正文

            热Key问题

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

            怎么发现热key

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

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

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

            如何解决

            目前?#30340;?#30340;方案有两种
            (1)利用二级缓存
            ?#28909;?#21033;用ehcache,或者一个HashMap都可以。在你发现热key以后,把热key加载到系统的JVM中。
            针对这种热key请求,会直接从jvm中取,而?#25442;?#36208;到redis层。
            假设此时有十万个针对同一个key的请求过来,如果没有本地缓存,这十万个请求就直接怼到同一台redis上了。
            现在假设,你的应用层有50台机器,OK,你也有jvm缓存了。这十万个请求平均分散开来,每个机器有2000个请求,会从JVM中取到value值,?#32531;?#36820;回数据。避免了十万个请求怼到同一台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))
            }

            ?#30340;?#26041;案

            OK,其实看完上面的内容,大家可能会有一个疑?#30465;?/p>

            ?#35848;紓?#26377;办法在项目运行过程中,自动发现热key,?#32531;?#31243;序自动处理么?

            嗯,好问题,那我们来讲讲?#30340;?#24590;么做的。其实只有?#35762;?br /> (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的?#30475;蝛ey值访问请求,Hermes-SDK 都会通过其通信模块将key访问事件异步上报给Hermes服务端集群,以便其根据上报数据进行“热点?#35762;狻薄?/p>

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

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

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

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

            总结

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

            posted @ 2019-05-16 11:26 孤独烟 阅读(...) 评论(...) 编辑 收藏
            加拿大app

              <address id="fvpxj"><progress id="fvpxj"><font id="fvpxj"></font></progress></address>
              <address id="fvpxj"></address>

                <address id="fvpxj"><progress id="fvpxj"></progress></address>
                <sub id="fvpxj"></sub>

                <address id="fvpxj"></address>

                  <track id="fvpxj"><big id="fvpxj"></big></track>

                    <address id="fvpxj"><big id="fvpxj"><font id="fvpxj"></font></big></address>

                    <dl id="fvpxj"><em id="fvpxj"><form id="fvpxj"></form></em></dl>

                        <address id="fvpxj"><progress id="fvpxj"><font id="fvpxj"></font></progress></address>
                        <address id="fvpxj"></address>

                          <address id="fvpxj"><progress id="fvpxj"></progress></address>
                          <sub id="fvpxj"></sub>

                          <address id="fvpxj"></address>

                            <track id="fvpxj"><big id="fvpxj"></big></track>

                              <address id="fvpxj"><big id="fvpxj"><font id="fvpxj"></font></big></address>

                              <dl id="fvpxj"><em id="fvpxj"><form id="fvpxj"></form></em></dl>

                                新疆十一选五中奖技巧 网上重庆快乐十分害死人 重庆幸运农场网上购买 老板发2元彩票当年终奖 时时彩一天赚2000技巧 360足球直播 黑龙江福利彩票p62开奖结果 腾讯分分彩是官方彩吗 象棋人生 象棋小游戏7k7k 3d动力彩票论坛 bbin真人游戏 贵州十一选五走势图手机板 好运快3彩票 大乐透开结果