哈喽，大家好！我是小米，29岁，喜欢分享技术的小米上线啦！今天咱们来聊聊在互联网高并发场景下，一个让大家又爱又恨的问题——热Key问题。热Key是什么呢？简单来说，就是某些缓存数据由于被频繁访问，造成了缓存集群的压力激增，导致系统负载过高，最终可能影响服务的稳定性。面对海量的请求，我们要如何从容应对呢？别急，今天我会分享一些常见的解决方案，包括Redis集群、本地缓存、限流和Key加随机值等技术手段。让我们开始吧！
热Key是什么？
热Key的核心问题在于某些Key的访问量远超其他Key，过多的请求涌入，导致这些热点Key所在的缓存节点压力激增，甚至出现缓存击穿和缓存雪崩的问题。常见的场景有秒杀活动、爆款商品等热点数据，在短时间内承载了极高的流量。
如果我们不采取应对措施，整个系统可能因为这些“热Key”而出现性能瓶颈。那么问题来了，如何解决这个困扰了无数技术人的热Key问题呢？接下来，我们从几个层面来分析。
解决热Key问题的思路，可以归结为缓存、限流、负载分布和降级四个方面。接下来我会一步步剖析。
Redis集群：主从复制与垂直扩容
首先，我们来看看Redis缓存集群。缓存集群是分布式系统中应对高并发的重要手段。当热Key问题出现时，常见的做法是通过扩容来增加缓存节点，减轻每个节点的压力。Redis支持两种扩容方式：
- 主从复制：Redis的主从复制是一种经典的架构。我们可以通过主从复制来保证数据的冗余性，并分担读流量。也就是说，写操作依然由主节点承担，但读操作可以通过多个从节点分担，从而减轻单个节点的压力。
- 垂直扩容：当单节点的负载过高时，我们还可以通过垂直扩容的方式，也就是提升单个节点的处理能力，比如增加CPU、内存等硬件资源。当然，垂直扩容有其局限性，所以在更大规模的并发场景下，水平扩展、增加节点数会更加有效。
应用内前置缓存：本地缓存+上限控制
本地缓存是Redis之外的另一个加速手段，尤其是在热点数据访问频繁时，本地缓存可以显著减少请求流向Redis，从而降低缓存压力。但使用本地缓存时，一定要注意控制缓存的上限，防止占用过多的应用内存，导致内存泄漏或OOM问题。
使用本地缓存的好处：
- 缓存命中率更高：直接从本地缓存中读取数据，比从远程Redis获取更加快速。
- 减少Redis请求：降低Redis集群的压力，避免过多的流量涌入。
需要注意的风险：
- 数据不一致：由于数据可能更新，而本地缓存没有及时同步，可能导致返回的数据是“旧数据”。因此，必须设置合理的过期时间和刷新机制。
- 内存占用过大：本地缓存容易无限制增长，必须设置一个合理的容量上限，保证应用不会因为内存问题崩溃。
延迟不敏感场景：定时刷新+实时感知+主动刷新
如果你的业务场景对于数据的实时性要求不高，可以采用定时刷新的方式。比如一些不敏感的数据，我们可以在业务层面设定一个刷新周期，定期刷新缓存中的数据，避免频繁地回源数据库。
同时，可以结合主动刷新机制。在某些场景下，比如用户发起某个操作导致了缓存失效，我们可以主动触发缓存更新，而不需要等到缓存过期才去更新数据。
定时刷新与主动刷新的结合可以帮助我们避免大量的无效请求从数据库获取数据，从而有效降低数据库压力。
限制逃逸流量：单请求回源+刷新前置缓存
和缓存穿透一样，热Key问题下也容易出现流量逃逸到后端数据库的情况。为了防止这种情况发生，我们可以采取限制逃逸流量的措施。比如说，当某个Key的缓存失效时，只允许一次请求回源数据库，其他请求等待前置缓存更新完毕后，再返回结果。
这就避免了多个请求同时回源数据库，造成数据库的压力过大。而且，这样设计可以避免短时间内的大量数据库请求，防止系统崩溃。
实现步骤：
- 当某个Key失效时，标记该Key正在被更新。
- 只有第一个请求可以去回源数据库，其余请求进入等待队列。
- 数据回源完成后，更新缓存，并释放等待队列中的请求。
这样一来，所有请求都从缓存中获得数据，保证了数据库的负载不会因为缓存失效而突然飙升。
Key加随机值：分布到多个实例中
当某些Key的访问量特别大时，即使采取了缓存集群的方式，依然会出现某个Key压力过大的情况。为了解决这个问题，我们可以给热点Key增加随机值，将其分散到不同的缓存节点上。
比如，假设有一个Key是product_12345，可以将这个Key改为product_12345_1、product_12345_2等不同的后缀，从而将同一个数据的请求分散到不同的实例上。通过这种方式可以有效避免单个节点的压力过大，达到均衡负载的效果。
示例：
这样做的核心在于将相同的数据复制多份，然后分散到多个节点去访问，避免单个Key成为瓶颈。
兜底逻辑：千万级流量来临的最后防线
即使我们设计了缓存集群、本地缓存和限流等措施，但在面对突发的千万级流量时，依然可能存在压力过大的情况。这时，我们必须设计一个兜底逻辑来应对极端情况。
常见的兜底策略：
- 降级处理：当流量激增，服务压力过大时，可以将某些非核心功能进行降级处理。比如，只返回部分缓存中的数据，而不回源数据库。
- 限流熔断：通过限流和熔断机制，拒绝一部分流量，保证核心服务的稳定。
- 预热机制：在大流量到来之前，提前预热缓存，减少突发流量对缓存的冲击。
这些兜底措施可以帮助我们在应对突发流量时，保证服务的稳定性。
END
面对热Key问题，最重要的是分散压力。我们可以通过Redis集群来水平扩展缓存容量，通过本地缓存来减少Redis的访问压力，通过限流来控制回源流量，通过Key加随机值来分布负载。最后，别忘了设计兜底逻辑，以防突发的流量涌入时，系统能够从容应对。
希望今天的分享能够帮助大家更好地理解和解决热Key问题。如果有任何问题，欢迎大家在评论区留言，我们一起讨论哈！
我是小米，一个喜欢分享技术的29岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
