本文重点在聊聊解决问题的思路，欢迎讨论指正！
1.缓存穿透
概念
大量查询不存在的key，短时间内对DB造成巨大的查询压力。
解决方案：
1）布隆过滤：将存在的key置于bitmap中，访问db之前过滤请求；
2）将不存在的key，以空值的形式存储在cache中，减少对底层db的压力。
3）数据库限流
2.缓存击穿
概念：
热点key过期，在短时间内对db造成的巨大压力。
解决思路
1）针对热点数据，临近过期前，提前加载数据到缓存。
2）过期后，加锁访问；
3）过期后，队列缓冲，请求落到db前，再次前置访问cache
4）数据库限流
3.缓存雪崩
概念
大量key采用相同的过期时间，短时间内key同时过期失效。流量对数据库造成的巨大压力。
解决思路
1）降低同时过期的可能，对key做随机延长expires time;
2）控制db访问的qps，miss后，队列缓冲请求db，控制db消费速度；
3）数据库限流
4.大VALUE，造成的网络堵塞
解决思路
1）写操作时，限制单个value的大小，大value拆分；
2）value 压缩
3）限流控制redis集群的qps，避免大流量造成网络阻塞；限流后的流量要么拒绝访问，要么引流到db，但同时也应评估引流到db的流量对数据库的影响。
4）网络上扩大带宽。
5.热点KEY
问题描述
基于hash slot分片之后，某些热点key的流量非常大。这些热点流量落到redis的某个节点上，造成单个节点的负载高于集群中其他节点。
解决思路
1）理解问题：热点key问题，对应到现实世界中的2/8法则，少量的资源吸引占据了大量的焦点，导致资源在分配时产生“倾斜”。解决这个问题的核心在于解决倾斜的问题。
2）发现热点：解决发现热点这个问题，本质是一个监控的问题。既然是监控，那么被监控的对象不外乎本文一开始图中的那几个角色。
a.从缓存本身去监控；
b.从server端的流量出口位置监控
c.从server到缓存之间的网络流量监控
以上3中不同的思路，目的在于发现热点，但这个过程并没有结束，发现是为了解决问题。
3）平衡热点：在这一步，已经解决热点发现的问题，明确热点资源在哪里。接下来是资源在分配的过程，这个过程包含两种情况：
a.资源初始化时，就知道它会变成热点资源，那么该如何去分配它？
b.一开始并不知道它是热点资源，如何迁移去平衡它？
当然a是b的一种特殊情况，可以不为a做特殊处理，直接走迁移的过程。
迁移是一个具体的执行方案，我们的目标是平衡缓存集群的负载。
就像本文开始提到的，这次不写具体的执行方案和实践过程了，只是聊一聊思路罢了。
