1.redis的热点数据是什么，可能出现什么问题？
某个key的访问频率很高，当一个key的qps到达1000的时候就需要关注了。redis中数据分布在集群的不同节点上，当某个key的qps过高，容易出现大量的读请求落在某一个redis数据分片节点上，造成负载不平衡，即访问倾斜从而将该节点打挂，那么该节点的所有缓存都不可用了，就会出现缓存雪崩等情况，造成大量的请求直接落到数据库上，造成数据库的查询阻塞甚至宕机。比较严重的就像微博某个明星宣布离婚，粉丝涌入留言，造成评论功能失效。
2.该如何定位热点数据？
热点数据定位这个问题的解决方案比较宽泛：
(1)根据业务进行判断，如果我们要做产品促销或秒杀活动，那么很明显这类产品信息就是热点数据，我们可以提前获知
(2)可以在项目获取redis数据的时候中统计key的请求次数，但这种方式对项目的代码入侵性比较强，不是很推荐
(3)可以监控每个redis节点的qps，当某节点的qps达到一定程度时，使用redis提供的monitor命令，可以获取一定时间内该节点的所有请求命令，从命令中分析热点key，但是它只能统计一个节点的命令，对于集群来说的话需要汇总统计，会稍微麻烦一点
(4)(个人思路)还有就是我看redis4.0里面为我们提供了一些新的特性，其中就有基于lfu的热点key发现机制，也可以利用这个特性去发现热点key
3. 热点key如何处理
热点key的处理有两个思路，一个是数据切分，将其分布在每个节点上，防止单个节点被打挂；另一个思路是数据迁移隔离
(1)在代码层面我们可以考虑将热点数据value拆分成多个部分，每部分有他们自己的key，对key进行特殊的hash处理，将其映射到属于不同分片的redis槽中，然后访问时根据相要获取数据的不同访问不同的key，使qps访问热度均匀分配到不同节点上
(2)当我们发现热点key之后可以将其所在的slot槽迁移到一个单独的redis节点中，这样即使热点数据造成分片节点的qps过高，也不会太影响整个集群的其他业务，还可以定制化开发，将热点key自动迁移到独立节点中，这种方案现在应该是比较成熟的。
(3)如果热点key的数据一致性不高的话，我们可以将热点数据缓存到业务服务的本地缓存中，这样使用时就可以省去一次网络查询IO，但是当redis中数据更新时可以会造成业务机器缓存与redis中数据不一致
4.大value数据是什么，会有怎样的问题？
当String类型的数据>10K，list、hash、set、sort set中元素个数超过1000时就可以被称为大value，当超过100K，或集合元素个数超过10000时可以被称为是超大value。大value最直接的影响就是有可能造成机器内存不足，就是数据倾斜；同时因为redis数据处理是单线程的，当value过大时，处理起来响应时间也会变慢。 常见的例子有：参与人数很多的盖楼活动或者很活跃的群聊消息列表等
5.怎么处理大value？
大value的处理方式还是结合业务，对其进行拆分，将其数据分布在各个redis节点中，将操作压力平摊开，防止对单个实例IO或内存影响过大。
简单说一下 热点数据和大value的拆分，如果它是一个list、 set集合类型，比如原来的 为key value，value为list为拆为 list1 、list2、list3，那么新的key为 key+hash(list1)%10000 得到新的key，再对对应数据value进行set或get操作
如果是一个对象的json字符串，可以考虑将该对象的不同属性映射到hash结构中去
hset(key+hash(filed)%10000, filed, value) filed为对象中属性名，value为该属性对应的值
标签：数据,redis,value,key,及大,热点,节点 From： https://blog.51cto.com/u_15973676/6069332