在有数据访问倾斜时，如果热点数据突然过期了，而 Redis 中的数据是缓存，数据的最终值保存在后端数据库，此时会发生什么问题？ 此时会发生缓存击穿，热点请求会直接打到后端数据库上，数据库的压力剧增，可能会压垮数据库。 Redis 的很多性能问题，例如导致 Redis 阻塞的场景：bigkey、集中过期、大实例 RDB 等等，这些场景都与数据倾斜类似，都是因为数据集中、处理逻辑集中导致的耗时变长。其解决思路也类似，都是把集中变分散，例如 bigkey 拆分为小 key、单个大实例拆分为切片集群等。 从软件架构演进过程来看，从单机到分布式，再到后来出现的消息队列、负载均衡等技术，也都是为了将请求压力分散开，避免数据集中、请求集中的问题，这样既可以让系统承载更大的请求量，同时还保证了系统的稳定性。

我们把热点数据复制多份，在每一个数据副本的 key 中增加一个随机前缀，让它和其它副本数据不会被映射到同一个 Slot 中。 这样做了以后怎么查呢？key前边加了随机数，客户端也不知道用啥key去查数据了

终于追上了，期待课代表的留言！课后问题我理解的话，只读模式下会发生缓存击穿，严重的话还可能造成雪崩。

不过业界中解决热key的话一般不采用hotkey+随机数的方式吧。毕竟如果集群实例个数特别多的话，删除hotkey的话成本有点大。 查看网上资料说解决热key更多的采用是将热点key加入到二级缓存（如JVM缓存） 不知道对不对？

感觉后面干货越来越少了,前几篇,一篇一看就是一晚上,后面一晚上看8,9篇,还是我变强了呢?

课后题：将发生缓存击穿，导致数据库压力激增，可能导致数据库奔溃。与之相对的解决方法是不设置热点 Key 的过期时间，并以采用热点数据多副本的方法减少单实例压力。 疑问：老师您好，热点数据多副本的方法使得每一个数据副本的 key 都有一个随机前缀，那么客户端在读取的时候怎么获取这个随机前缀？又怎么保证带上随机前缀后的热点 Key 会被较为均匀的请求呢？

针对流量倾斜问题，对key作切分 理论上其实很简单 但是联合业务实践上挺复杂的，某个key一开始是非热点数据状态的，需要有监控redis key的工具，需要有相关自动切分或者人工干预切分的行为，切分以后业务端查询也需要同步被告知切分的规则，否则业务查询时候无法获取正确的key，切换的过程中新key与旧key需要同时存在一小段时间，否则肯能存在读旧key的请求异常。目前唯一能想到的是通过zookeeper这种配置中心去协调（watch机制），但是大量读会给zookeeper带来比较大的压力。增加二级缓存又会有数据延迟的情况，真的不清楚实际上业务是如何实现这种联动的。

缓存击穿

热点多副本方案的使用：客户端请求时带上客户端标记即可，不同的客户端请求就会hash分散到不同的热点副本。