对于三高系统，Redis是必须/必需的，当并发高到一定的程度就可能会出现HotKey的问题，今天我们来看下Redis中的HotKey如何解决。
什么是HotKey
在较短的时间内，海量请求访问一个Key，这样的Key就被称为HotKey。
HotKey的危害
- 海量请求在较短的时间内，访问一个Key，势必会导致被访问的Redis服务器压力剧增，可能会将Redis服务器击垮，从而影响线上业务；
- HotKey过期的一瞬间，海量请求在较短的时间内，访问这个Key，因为Key过期了，这些请求会走到数据库，可能会将数据库击垮，从而影响线上业务。（这是缓存击穿问题）
HotKey如何解决
HotKey如何解决是一个比较宽泛的问题，涉及到多个方面，我们一个个来看。
Redis部署
通常来说，Redis有两种集群形式：数据分片集群、主从 哨兵集群，其实这两种集群形式或多或少的都一定程度上缓解了HotKey的问题。
主从 哨兵集群
如果我们采用单主：
- 所有的读请求都会打在仅有的一个Redis服务器，都不用管Key是什么，只要并发一高，就会导致Redis服务器压力剧增；
- 一旦仅有的一个Redis服务器挂了，就没有第二个Redis服务器顶上去了，无法继续提供服务。
如果我们采用主从 哨兵集群：
- 读请求会被分散到Master节点或者多台Slave节点，将请求进行了初步的分散；
- Master节点挂了，Slave节点会升级为新的Master节点，继续提供服务。
数据分片集群
Key被分散在了不同的Redis节点，将请求进行了进一步的分散。
如果采用数据分片集群，同时也会部署主从 哨兵，这样又有了主从 哨兵集群的特性：
- 读请求会被分散到Master节点或者多台Slave节点，将请求进行了初步的分散；
- Master节点挂了，Slave节点会升级为新的Master节点，继续提供服务。
画外音：我以前一直以为大部分公司都已经采用了数据分片集群，其实不然，某个我认为不差钱的公司，在2021年采用的还是主从 哨兵集群，出了问题，才转变成数据分片集群，我到我们公司一瞧，才发现我们公司也是主从 哨兵集群。
隔离
不同的业务分配不同的Redis集群，不要将所有的业务都“混杂”在一个Redis集群。
只要可以做到集群 隔离，在一定程度上就已经避免了HotKey，但是对于超高并发的系统来说，可能还有点不够，所以才会有下面的更进一步的措施。
如何应对HotKey
这个问题，可以拆分成三个子问题：如何发现HotKey、如何通知HotKey的产生、如何对HotKey进行处理。
如何发现HotKey
如何发现HotKey的前提是知道每个Key的使用情况，并进行统计，所以这又拆成了两个更小的子问题：如何知道每个Key的使用情况，如何进行统计。
如何知道每个Key的使用情况
谁最清楚知道每个Key的使用情况，当然是客户端、代理层，所以我们可以在客户端或者代理层进行埋点。
客户端埋点
在客户端请求Redis的代码中进行埋点。
优点：
- 实现较为简单
- 轻量级
- 几乎没有性能损耗
缺点：
- 进行统一管理较为麻烦：如果想开启或者关闭埋点、上报，会比较麻烦
- 升级、迭代较为麻烦：如果埋点、上报方式需要优化，就需要升级Jar包，再找一个黄道吉日进行发布
- 客户端会有一定的压力：不管是实时上报使用情况，还是准实时上报使用情况，都会对客户端造成一定的压力
代理层埋点
客户端不直接连接Redis集群，而是连接Redis代理，在代理层进行埋点。
优点：
- 客户端没有压力
- 对客户端完全透明
- 升级、迭代比较简单
- 进行统一管理比较简单
缺点：
- 实现复杂
- 会有一定的性能损耗：代理层需要转发请求到真正的Redis集群
- 单点故障问题：需要做到高可用，更复杂
- 单点热点问题：代理层本身就是一个热点，需要分散热点，更复杂
如何上报每个Key的使用情况
我们在客户端或者代理层进行了埋点，自然是由它们上报每个Key的使用情况，如何上报又是一个小话题。
实时/准实时
- 实时上报：每次请求，都进行上报
- 准实时上报：积累一定量或者一定时间的请求，再进行上报
是否预统计
如果采用准实时上报，在客户端或者代理层是否对使用情况进行预统计：
- 进行预统计：减少上报的数据量，减轻统计的压力，自身会有压力
- 不进行预统计：上报的数据量比较多，自身几乎没有压力
如何统计
不管如何进行上报，使用情况最终都会通过Kafka，发送到统计端，这个时候统计端就来活了。 一般来说，这个时候会借助于大数据，较为简单的方式：Flink开一个时间窗口，消费Kafka的数据，对时间窗口内的数据进行统计，如果在一个时间窗口内，某个Key的使用达了一定的阈值，就代表这是一个HotKey。
如何通知HotKey的产生
经过上面的步骤，我们已经知道了某个HotKey产生了，这个时候就需要通知到客户端或者代理层，那如何通知HotKey的产生呢？
- MQ：用MQ通知客户端或者代理层HotKey是什么
- RPC/Http：通过RPC/Http通知客户端或者代理层HotKey是什么
- 配置中心/注册中心指令：既然遇到了HotKey的问题，并且想解决，那基本上是技术实力非常强大的公司，应该有非常完善的服务治理体系，此时，可以通过配置中心/注册中心下发指令到客户端或者代理层，告知HotKey是什么
如何处理HotKey
客户端或者代理层已经知晓了HotKey产生了，就自动开启一定的策略，来避免HotKey带来的热点问题：
- 使用本地缓存，不至于让所有请求都打到Redis集群
- 将HotKey的数据复制多份，分散到不同的Redis节点上
在实际开发中，可能在很大程度上，都不会有埋点、上报、统计，通知、策略自动开启，这一套比较完善的Redis HotKey解决方案，我们能做到的就是预估某个Key可能会成为热点，就采用本地缓存 复制多份HotKey数据的方式来避免HotKey带来的热点问题。我们还经常会因为偷懒，所以设计了一个大而全的Key，所有的业务都从这个Key中读取数据，但是有些业务只需要其中的一小部分数据，有些业务只需要另外一小部分数据，如果不同的业务读取不同的Key，又可以将请求进行分散，这是非常简单，而且有效的方式。
