聊聊军演压测中热key导致Redis实例CPU100%的问题

        在Redis集群中，热key指得是那些在某一段时间内访问特别高的键值。热key的问题在于，大量访问流量集中到某一个Redis实例中，达到单个实例处理上限，可能会导致该实例CPU使用率100%，或者网卡流量达到上限等，对集群以及应用系统的稳定性和可用性造成影响，更为严重出现服务器宕机。 

可造成的影响

1、热key会导致流量集中，redis缓存与数据库被击穿，从而引发系统雪崩（大量请求失败，直接访问数据库等）。

2、请求分配不均，存在热key的节点面临较大的访问压力，可能导致该数据分片的连接数被耗尽甚至宕机，如{hashTag}在大流量场景下较易出现这种情况，对于热点的hashTag请求集群于某一个节点实例。

对于热key，增加redis的分片是无能为力的，也违背了降本的初心。

如何发现热key

最有力的手段还是监控、监控、监控。监控过程中发现redis的get使用率有所降级，出现了ConnectionFailureException异常，新的redis连接不能创建。

下面分享一个在军演压测过程中的热key监控图。

对上面的第一个实例查看热key，发现某个key的请求次数远超过其他key。

解决方案

1、多级缓存，如增加本地缓存。

对于本地缓存，需要考虑的点：防止本地缓存过大，影响系统性能；本地缓存与Redi集群数据的一致性问题。

2、热key备份，即将该热key通过添加一些前/后缀，将热key分散到不同的实例中，请求时分散请求不同的key，从而实现访问量均衡到不同的实例。

3、使用读写分离架构，这种方案我本人不太推荐

当然，避免热key这个问题，根本上还是在架构设计上去思考，提前预测系统存在的风险点。