- 缓存击穿问题
- 概念：当某个热点key设置了过期时间，恰好在过期时刻有大量并发请求，这些请求发现redis中无数据便直接请求数据库，可能瞬间压垮数据库。例如根据id查询文章数据时，若key过期，会直接走数据库查询，即便查询时会将数据同步到redis，但如果缓存重建花费时间过长（如分组统计导致），大量请求过来数据库仍可能承受不住，这种现象就是缓存击穿。
- 解决方案
- 互斥锁方案
- 流程：线程一查询缓存无数据后添加互斥锁（分布式锁），接着查询数据库进行缓存重建，将新数据写入缓存后释放锁。在此期间，线程二查询缓存无数据且获取锁失败，便休眠一会儿再试，直到线程一完成数据写入缓存，线程二可直接从缓存获取数据。
- 特点：能保证数据强一致性，但性能相对较低，多个线程需等待获取锁进行缓存重建。
- 逻辑过期方案
- 流程：热点key在redis中不设置过期时间，存储数据时新增过期时间字段。线程一查询缓存发现数据逻辑过期后，获取互斥锁，然后新开线程重建缓存数据（从数据库查询并写入缓存，更新逻辑过期时间，最后释放锁），线程一无需等待线程二重建缓存成功，直接返回过期数据。线程三查询过期数据获取锁失败后也直接返回过期数据，线程四获取缓存时若重建已完成则可拿到最新数据。
- 特点：优先保证高可用性，性能较好，但不能保证数据绝对一致，先返回数据，之后再进行缓存重建。
- 方案对比与总结
- 对比：互斥锁方案保证数据强一致但性能差，逻辑过期方案保证高可用性能好但数据一致性稍弱。
- 总结：缓存击穿是热点key过期时有大量并发请求压向数据库的问题，解决方案有互斥锁（保证数据强一致但性能低）和逻辑过期（保证高可用性能好但数据不完全一致），需根据业务需求选择合适方案，如涉及金钱相关业务常选互斥锁保证强一致，互联网行业注重用户体验常选高可用性的逻辑过期方案。
