做网站现在用什么软件,响应式网站 html,软件开发工程师访谈报告,山西网站制作公司哪家好文章目录 背景一、怎么发现热key1.1 方法一:凭借业务经验#xff0c;进行预估哪些是热key1.2 方法二:在客户端进行收集1.3 方法三:在Proxy层做收集1.4 方法四:用redis自带命令1.5 方法五:自己抓包评估 二、如何解决2.1. 利用二级缓存2.2. 备份热key2.3 永不过期2.4 分布式锁 三… 文章目录 背景一、怎么发现热key1.1 方法一:凭借业务经验进行预估哪些是热key1.2 方法二:在客户端进行收集1.3 方法三:在Proxy层做收集1.4 方法四:用redis自带命令1.5 方法五:自己抓包评估 二、如何解决2.1. 利用二级缓存2.2. 备份热key2.3 永不过期2.4 分布式锁 三、redis cluster集群部署方案3.1 读写分离3.2 本地缓存 背景
“这个商品不错大家来看啊“每个平台都有会有些大卖的商品简称为爆品。这些商品会有个特点就是访问量特别大。我们专业上面可以称之为热点数据在处理这些热点商品时系统需要做一些特殊的处理。
针对热点商品这些类型的数据要考虑到访问量比较大大家首先想到的是缓存上redis缓存这点肯定没有错。系统框架如下
上图中先从缓存中获取没有再到DB获取并保存到缓存中。但有个问题会产生热点数据的访问会比较大如果缓存一旦失效所有请求同一时刻会打到DB上面DB肯定会崩溃。那怎么办呢
上面提到所谓热key问题就是突然有几十万的请求去访问redis上的某个特定key。那么这样会造成流量过于集中达到物理网卡上限从而导致这台redis的服务器宕机。
那接下来这个key的请求就会直接怼到你的数据库上导致你的服务不可用。
一、怎么发现热key
1.1 方法一:凭借业务经验进行预估哪些是热key
其实这个方法还是挺有可行性的。比如某商品在做秒杀那这个商品的key就可以判断出是热key。缺点很明显并非所有业务都能预估出哪些key是热key。
1.2 方法二:在客户端进行收集
这个方式就是在操作redis之前加入一行代码进行数据统计。那么这个数据统计的方式有很多种也可以是给外部的通讯系统发送一个通知信息。缺点就是对客户端代码造成入侵。
1.3 方法三:在Proxy层做收集
有些集群架构是下面这样的Proxy可以是Twemproxy是统一的入口。可以在Proxy层做收集上报但是缺点很明显并非所有的redis集群架构都有proxy。 1.4 方法四:用redis自带命令 monitor命令该命令可以实时抓取出redis服务器接收到的命令然后写代码统计出热key是啥。当然也有现成的分析工具可以给你使用比如redis-faina。但是该命令在高并发的条件下有内存增暴增的隐患还会降低redis的性能。 hotkeys参数redis 4.0.3提供了redis-cli的热点key发现功能执行redis-cli时加上–hotkeys选项即可。但是该参数在执行的时候如果key比较多执行起来比较慢。
1.5 方法五:自己抓包评估
Redis客户端使用TCP协议与服务端进行交互通信协议采用的是RESP。自己写程序监听端口按照RESP协议规则解析数据进行分析。缺点就是开发成本高维护困难有丢包可能性。
以上五种方案各有优缺点。根据自己业务场景进行抉择即可。那么发现热key后如何解决呢
二、如何解决
目前业内的方案有两种
2.1. 利用二级缓存
比如利用ehcache或者一个HashMap都可以。在你发现热key以后把热key加载到系统的JVM中。
针对这种热key请求会直接从jvm中取而不会走到redis层。
假设此时有十万个针对同一个key的请求过来,如果没有本地缓存这十万个请求就直接怼到同一台redis上了。
现在假设你的应用层有50台机器OK你也有jvm缓存了。这十万个请求平均分散开来每个机器有2000个请求会从JVM中取到value值然后返回数据。避免了十万个请求怼到同一台redis上的情形。
2.2. 备份热key
这个方案也很简单。不要让key走到同一台redis上不就行了。我们把这个key在多个redis上都存一份不就好了。接下来有热key请求进来的时候我们就在有备份的redis上随机选取一台进行访问取值返回数据。
假设redis的集群数量为N步骤如下图所示 注:不一定是2N你想取3N4N都可以看要求。
伪代码如下
const M N * 2//生成随机数random GenRandom(0, M)//构造备份新keybakHotKey hotKey “_” randomdata redis.GET(bakHotKey)if data NULL {data GetFromDB()redis.SET(bakHotKey, expireTime GenRandom(0,5))}2.3 永不过期
这个方案就是利用redis本身的特性导致的问题是因为缓存失效了那我们可以让缓存永不过期就行了。这个方案中需要考虑两个情况
热点商品上线前需要预热也就是在商品正式发布到前端时需要提前把商品信息进行缓存避免跟缓存失效的情况一样。更新商品信息机制如何在商品信息更新后及时更新缓存中的商品信息。这个也比较简单在更新商品事件中增加个更新消息由缓存服务进行消费更新缓存信息。
2.4 分布式锁
缓存一旦失效如何重新构建缓存首先需要避免失效那一刻大量请求同时去重新构建缓存。因为重新构建缓存需要到数据库DB中获取数据那一个时刻的所有请求到DB上面。
方案有两种
第一个方案是把请求进入队列中还有一个方案就比较简单利用分布式锁只允许一个请求线程去访问DB其他请求阻塞这样就避免了很多请求打到DB上。 上面两个方案是网上经常提到的方案其实这两个方案会存在一个问题也就是redis达到了负载极限怎么办也就是热点商品的访问量我们的单台redis扛不住了。 三、redis cluster集群部署方案 上图是redis经典的三主三从集群方案客户端进行set和get时都是走的主redis从redis只是个备份主要作用是用来做高可用的如主redis挂了从redis顶上。
备注这里介绍的是redis集群部署方案如果是之前的redis主从方案另外讨论 从redis是不负责set和get请求的即使请求打到从redis节点从redis也会转发给主redis。而其他的主redis是用来做数据扩容的。
即就是商品A的信息只会存在一个主redis中其他主redis是没有此商品A的信息的这就是redis集群哈希槽的特点。
也就是小伙伴刚才想到的做redis集群这个方案是不行的因为热点数据只会在一个主redis中。会存在单台redis负载不足达到网卡、网络上限。达到这个瓶颈流量代表非常大了。那怎么办呢
3.1 读写分离
上面我们提到从redis只不负责读和写请求的但redis官方提供了一个方法在操作读请求时可以先加上readonly命令这样从redis就可以提供读请求服务了不需要转发到主redis。 根据这个特性我们可以对客户端工具进行改造读请求方法时加上readonly这个命令从而实现读写分离提高了从redis的利用率。 即达到了多台从redis去扛大量请求了减少了主redis压力。这个方案需要对客户端进行改造而且redis官方推荐没有必要使用读写分离
3.2 本地缓存
这个方案就是多级缓存的方案把缓存前置架构图如下
改造web应用服务在获取到redis缓存后在web服务本地把热点的数据进行缓存因为热点的商品不会很多所以保存在本地缓存中是没有问题的。这样请求数据时如果web本地有缓存数据就直接返回了。
这样前端3个web应用就分担了redis缓存的压力如访问过大就可以增加web应用服务本来web应用服务就需要集群化
