| 失效链接处理 |
|
行业案例：有赞100Wqps透明多级缓存解决方案（TMC）PDF 下载
相关截图：
 主要内容：
什么是HotKey？
在某个Key接收到的访问次数、显著高于其它Key时，我们可以将其称之为HotKey，
从访问量上来说，常见的HotKey如：
某Redis实例的每秒总访问量为10000，而其中一个Key的每秒访问量达到了7000（访问次数显著
高于其它Key）
对一个拥有上千个成员且总大小为1MB的HASH Key每秒发送大量的HGETALL（带宽占用显著高于
其它Key）
对一个拥有数万个成员的ZSET Key每秒发送大量的ZRANGE（CPU时间占用显著高于其它Key）
从业务上来说， 常见的HotKey如：
1 、MySQL等数据库会被频繁访问的热数据
如爆款商品的skuId。
2 、redis的被密集访问的key
如爆款商品的各维度信息，skuId、shopId等。
3 、机器人、爬虫、刷子用户
如用户的userId、uuid、ip等。
4 、某个接口地址
如/sku/query或者更精细维度的。
注意，我们的HotKey探测框架只关心key，其实就是一个字符串，
HotKey对服务层和数据层的风险
在拥有大量并发用户的系统中，HotKey一直以来都是一个不可避免的问题。
或许是突然某些商品成了爆款，
或许是海量用户突然涌入某个店铺，
或许是秒杀时瞬间大量开启的爬虫用户，
突发大批机器人
以远超正常用户的速度发起极其密集的请求，这些机器人只需要很小的代价，就能
发出百倍于普通用户的请求量，从而大幅挤占正常用户的资源。
以京东为例的这些头部互联网公司，动辄某个爆品，会瞬间引入每秒上百万甚至数百万的请求，当然流
量多数会在几秒内就消失。
但就是这短短的几秒的HotKey，就会瞬间造成其所在redis分片集群瘫痪。
原因也很简单，redis作为一个单线程的结构，所有的请求到来后都会去排队，当请求量远大于自身处理
能力时，后面的请求会陷入等待、超时。
由于该redis分片完全被这个key的请求给打满，导致该分片上所有其他数据操作都无法继续提供服务，
也就是HotKey不仅仅影响自己，还会影响和它合租的数据。
这样，redis 缓存没有响应之后，相当于 redis 击穿， 请求直接转向DB
DB的吞吐量，比如会低很多，DB 就会雪崩。
总结一下，HotKey带来的常见问题
HotKey占用大量的Redis CPU时间，使其性能变差并影响其它请求；
Redis Cluster中各node流量不均衡造成Redis Cluster的分布式优势无法被Client利用，一个分片
负载很高而其它分片十分空闲从而产生读/写热点问题；
在抢购、秒杀活动中，由于商品对应库存Key的请求量过大，超出Redis处理能力造成超卖；
HotKey的请求压力数量超出Redis的承受能力造成缓存击穿，此时大量强求将直接指向后端存储，
将后端存储打挂并影响到其它业务；
HotKey问题的根本：
HotKey问题归根到底就是如何找到HotKey，并将HotKey放到本地内存的问题。
只要该key在内存里，我们就能极快地来对它做逻辑，内存访问和redis访问的速度不在一个量级。
如果该key是在本地内存中，读取一个内存中的值，每秒多少个万次都是很正常的，不存在任何数据层
的瓶颈。
但问题是事先不知道HotKey在哪里？
那么，问题就来了，如何进行 HotKey的探测？
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
