热点key重建？问题？解决？
热点key重建？问题？解决？
在开发过程中，通常会采用"缓存+过期时间"的策略，以加快数据的读写速度，并保证数据的定期更新。这种模式通常能够满足大多数需求。然而，当以下两个问题同时出现时，可能会引发一些较大的问题：
- 当前缓存的key是一个热点key，即高并发访问的热门数据，导致并发量非常大。
- 重建缓存的过程需要较长的时间，可能涉及复杂的计算，如复杂的SQL查询、多次IO操作、依赖其他资源等。在缓存失效的瞬间，大量线程同时发起重建缓存的请求，导致后端负载加大，甚至可能导致应用崩溃。
那么如何处理这个问题呢？主要从以下几个方面入手：
- 使用互斥锁（mutex key）：采用互斥锁的方式，确保只有一个线程可以进行缓存的重建操作，其他线程等待重建完成后再从缓存中获取数据，以避免多个线程同时重建缓存导致的问题。
- 永不过期策略："永不过期"有两个含义：
- 从缓存层面来看，确实没有设置过期时间，即物理上不过期。
- 从功能层面来看，为每个value设置一个逻辑过期时间，在超过逻辑过期时间后，使用单独的线程去异步构建缓存，以保证数据的及时更新。
通过采用互斥锁和永不过期策略，可以减少重建缓存的频率，尽可能保持数据的一致性，并降低潜在的风险。这样能够有效处理热点key和缓存重建的问题，提高系统的稳定性和性能。
