● 是指：客户端请求的数据在缓存中和数据库中都不存在，所有的请求都打到了数据库上面。
● 解决方案：
○ 缓存空对象
■ 优点：实现简单，维护方便
■ 缺点：额外的内存消耗；可能造成短期的数据不一致
○ 布隆过滤器
■ 优点：内存占用较少
■ 缺点：实现复杂；存在误判的可能
○ 增强id的复杂度，避免被猜测id规律
○ 做好数据的基础格式校验
○ 加强用户的权限校验
○ 做好热点参数的限流
● 是指：一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。
● 解决方案：
○ 互斥锁
■ 优点：
● 没有额外的内存消耗
● 保证数据的一致性
● 实现简单
■ 缺点：
● 线程需要等待，性能受影响
● 可能有死锁的风险
○ 逻辑过期
■ 优点：线程不需要等待，性能较好
■ 缺点：
● 不保证数据的一致性
● 有额外的内存消耗，多存expire字段
● 实现复杂
● 是指：在同一时段，大量的缓存key同时过期，或者redis服务宕机。导致大量的请求打到数据库，带来巨大的压力。
● 解决方案：
○ 给不同的key的TTL添加随机值
○ 利用redis集群提供服务的可用性
○ 给缓存业务添加降级限流策略
○ 给业务添加多级缓存
● 小公司，缓存击穿，缓存击穿，我击穿你妹啊！吹什么牛逼！
● 永不过期啊
● 构建缓存之前先加锁，只让一个线程去查询数据库重新构建缓存
● 开启一个异步线程，去重新构建缓存
● 这些答案都只是纸上谈兵而已啊
● MySQL 也没有网上说的那么容易崩溃，小公司，你崩溃你妹啊。
○ 服务器配置2核4G内存下，MySQL的 QPS 峰值是4300, TPS 为215, RT 为300ms
● 缓存击穿导致数据库被打崩了，本质上是一个高并发的架构问题，不是Redis本身的问题
● 第一，需要正确评估系统的容量，和业务中的慢查询，应该要做到什么呢？
● 你所有用缓存的场景，哪怕有一刻缓存是失效的，你也要保证数据库能扛得下来。查询走缓存是多少耗时，不走是多少耗时，你自己心里要有个数
● 特别是做 TO C 场景的，单个查询呢，排除网络因素在外呢，要保证耗时呢，要在200ms以内。复杂的 sql 需要做优化
● 第二，你的缓存监控在哪里？在即将过期的时候，要有报警，进行缓存的续期
● 第三，系统的降级熔断策略在哪里？当你最近的 100 次请求，平均 rt 都超过 5 s 了，系统报错率也在飙升，你不应该熔断对数据库的查询操作吗？难道等到全链路上面，依赖数据库的请求都挂了，然后引发一个 s 级别的事故吗？
● 当你做完这些准备之后呢，你再去谈怎么单纯解决缓存击穿的问题，你可以完全忽略，永不过期这种方案，因为一个要去考虑缓存击穿的系统，绝对是高并发和海量数据的？你怎么可能把海量数据全部存到 Redis 中，还永不过期？你可能说，哎呀，我只存热点数据麻。你能预测未来啊？你无法确定哪些数据是热点数据