Redis经典问题之雪崩击穿穿透
Redis经典问题
什么是Redis缓存雪崩？
举个最简单的例子：一个网购平台，如果所有页面的Key失效时间都是12个小时，中午12点刷新的，我零点有个秒杀活动大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是缓存当时所有的Key都失效了。这时候1秒6000个请求全部打到数据库，数据库肯定瞬间宕机了。DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。这就是我理解的缓存雪崩。
又或者是，redis重启，大量访问数据库，也会导致数据库崩溃。
也就是说，一般流程是用户下单—>下单系统—>Redis(缓存，有数据即返回)—>没数据则到数据库查
现在第三步没了，同一时间大面积失效，那一瞬间Redis跟没有一样，那这个数量级别的请求直接打到数据库几乎是灾难性的。
那我们应该怎么应对缓存雪崩呢
处理缓存雪崩简单，在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效，我相信，Redis这点流量还是顶得住的。
setRedis(Key，value，time + Math.random() * 10000);
如果是怕Redis宕机了，也可以设置高可用，主从+哨兵的模式。或者设置热点数据永远不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。
那什么是缓存穿透呢
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如数据库）。而缓存穿透是指在高并发下查询key不存在的数据，会穿过缓存查询数据库。导致数据库压力过大而宕机。比如说：用户不断发起请求，我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。像这种你如果不对参数做校验，数据库id都是大于0的，我一直用小于0的参数去请求你，每次都能绕开Redis直接打到数据库，数据库也查不到，每次都这样，并发高点就容易崩掉了。
解决方案
针对这个问题，其实我们的办法有很多
- 比如我会在接口层增加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id <=0的直接拦截等。
- 对查询结果为空的情况也进行缓存，缓存时间（ttl）设置短一点，或者该key对应的数据insert了之后清理缓存。(但是缓存太多空值也会造成空间的浪费)
- 如果还存在缓存穿透，我们也可以在缓存之前
- 在加一层布隆过滤器，在查询的时候先去布隆过滤器查询 key 是否存在，如果不存在就直接返回，存在再查缓存和DB。
什么是缓存击穿？
这个嘛，跟缓存雪崩有点像。，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。
解决方案
- 使用redis的setnx互斥锁先进行判断，这样其他线程就处于等待状态，保证不会有大并发操作去操作数据库。
- 设置热点数据永远不过期。
一般避免以上情况发生我们从三个时间段去分析下：
- 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
- 事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免MySQL被打死。
- 事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降级！可以返回一些默认的值，或者友情提示，或者空白的值。
好处：
数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。只要数据库不死，就是说，对用户来说，3/5 的请求都是可以被处理的。只要有 3/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次。
这个在目前主流的互联网大厂里面是最常见的，你是不是好奇，某明星爆出什么事情，你发现你去微博怎么刷都空白界面，但是有的人又直接进了，你多刷几次也出来了，现在知道了吧，那是做了降级，牺牲部分用户的体验换来服务器的安全，可还行？
数据一致性问题
对于缓存和数据库的操作，主要有这两种方式：
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
为什么是删除，而不是更新缓存
我们以先更新数据库，再删除缓存来举例。
如果是更新的话，那就是先更新数据库，再更新缓存。
举个例子：如果数据库1小时内更新了1000次，那么缓存也要更新1000次，但是这个缓存可能在1小时内只被读取了1次，那么这1000次的更新有必要吗？
反过来，如果是删除的话，就算数据库更新了1000次，那么也只是做了1次缓存删除，只有当缓存真正被读取的时候才去数据库加载。
好，我们来说说第一种情况
先删缓存，再更新数据库
先删除缓存，数据库还没有更新成功，此时如果读取缓存，缓存不存在，去数据库中读取到的是旧值，缓存不一致发生。
解决方案
延时双删：延时双删的方案思路是，为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再sleep一段时间，然后再次删除缓存。
流程如下：
- 线程1删除缓存，然后去更新数据库
- 线程2来读缓存，发现缓存已经被删除，所以直接从数据库中读取，这时候由于线程1还没有更新完成，所以读到的是旧值，然后把旧值写入缓存
- 线程1，根据估算的时间，sleep，由于sleep的时间大于线程2读数据+写缓存的时间，所以缓存被再次删除
- 如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值
sleep的时间要对业务读写缓存的时间做出评估，sleep时间大于读写缓存的时间即可。
也就是说：当你删除缓存，在还没有更新数据库，这时从数据库重新读取到的是旧值，然后这时再删除一次缓存，这时，如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值。
先更新数据库，再删除缓存
如果反过来操作，先更新数据库，再删除缓存呢？
这个就更明显的问题了，更新数据库成功，如果删除缓存失败或者还没有来得及删除，那么，其他线程从缓存中读取到的就是旧值，还是会发生不一致。
可以引入一个消息队列，利用消息的ACK机制来保证数据的一致性。
可是，为了解决缓存一致性的问题单独引入一个消息队列，太复杂了。
其实，一般大公司本身都会有监听binlog消息的消息队列存在，主要是为了做一些核对的工作。
这样，我们可以借助监听binlog的消息队列来做删除缓存的操作。这样做的好处是，不用你自己引入，侵入到你的业务代码中，中间件帮你做了解耦，同时，中间件的这个东西本身就保证了高可用。
当然，这样消息延迟的问题依然存在，但是相比单纯引入消息队列的做法更好一点。
而且，如果并发不是特别高的话，这种做法的实时性和一致性都还算可以接受的。但其实并不推荐直接使用。
Big Key
什么是Big Key？
大key指的是存储的值（Value）非常大，常见场景：
- 热门话题下的讨论
- 大V的粉丝列表
- 序列化后的图片
- 没有及时处理的垃圾数据
大key的影响：
- 大key会大量占用内存，在集群中无法均衡
- Redis的性能下降，主从复制异常
- 在主动删除或过期删除时会操作时间过长而引起服务阻塞
优化big key的原则就是string减少字符串长度，list、hash、set、zset等减少成员数。
-
string类型的big key，尽量不要存入Redis中，可以使用文档型数据库MongoDB或缓存到CDN上。如果必须用Redis存储，最好单独存储，不要和其他的key一起存储。采用一主一从或多从。
-
单个简单的key存储的value很大，可以尝试将对象分拆成几个key-value， 使用mget获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多次操作中，降低对redis的IO影响。
-
hash， set，zset，list 中存储过多的元素，可以将这些元素分拆。（常见）
以hash类型举例来说，对于field过多的场景，可以根据field进行hash取模，生成一个新的key，例如原来的
hash_key:{filed1:value, filed2:value, filed3:value …}可以hash取模后形成如下
key:value形式hash_key:1:{filed1:value}
hash_key:2:{filed2:value}
hash_key:3:{filed3:value}
…
取模后，将原先单个key分成多个key，每个key filed个数为原先的1/N。删除大key时不要使用del,因为del是阻塞命令，删除时会影响性能。
使用 lazy delete (unlink命令):删除指定的key(s),若key不存在则该key被跳过。但是，相比DEL会产生阻塞，该命令会在另一个线程中回收内存，因此它是非阻塞的。 这也是该命令名字的由来：仅将keys从key空间中删除，真正的数据删除会在后续异步操作。