Redis中大key问题，热key问题的解决方案

遇到大key、热key问题，主要是去拆分

大key问题

业务场景中经常会有各种大key的情况， 比如：
1. 单个简单的key存储的value很大（例如排行榜信息，key是固定的，value排行榜几十万的数据）
2. hash、set、zset、list中存储过多的元素（以万为单位）

由于redis是单线程运行的，如果一次操作的value很大会对整个redis的响应时间造成负面影响，所以，业务上能拆则拆，

解决方案：

1. 现在本地计算最后存储在哪个key中，计算出key的hash值，默认是通过（pin）的hash值，模除100，然后确认存在那个key上面

2. 取得时候，同样也需要计算，即

newHashKey = hashKey + (hash(field) % 10000);
hset(newHashKey, field, value);
hget(newHashKey, field)

热key问题：

解释：热门的key值，被频繁的访问，例如秒杀的信息，导致redis直接死掉

解决方案： 通过把热门的key，放在不同的服务器，即通过redis分片的策略，线上的Redis一般都是集群进行部署，对于Redis-Cluster模式，热点的key会导致部分分片的负载非常高而被拖垮

1. 可以将热key，通过轮询放在不同的服务器， 

2. 查询的时候，同样按照轮询，查询不同的服务器，（然后通过拼接各台服务器的数据）降低单台服务器的压力

 

 

 

一、缓存读热点key问题：

某个热点缓存model读取流量极大。带来问题：

1. 读缓存问题：读流量集中到某key，导致指定缓存机器压力过大
2. 写缓存问题：缓存失效时，大量线程穿透构建缓存，带来db和服务压力。

解决：

1. 读缓存问题
   1. 将缓存在分布式服务机器做二次缓存
   2. 备份热点Key：即将热点Key+随机数，随机分配至Redis其他节点中。这样访问热点key的时候就不会全部命中到一台机器上了。
   3. 限流熔断保护。
2. 写缓存问题
   1. 使用互斥锁(mutex key)，只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了（如下图）。
      1. 
   2. redis上不设置过期时间，过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期。对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据。

二、缓存大key问题

Redis使用过程中经常会有各种大key的情况， 比如单个简单的key存储的value很大。
由于redis是单线程运行的，如果一次操作的value很大会对整个redis的响应时间造成负面影响，导致IO网络拥塞。

解决：

将整存整取的大对象，分拆为多个小对象。可以尝试将对象分拆成几个key-value， 使用multiGet获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响；