备注：很久很久以前，刚刚开始写代码，有人嘲笑后端工程师只懂得CURD。多年以后我要大声的告诉嘲笑我的这个人，我不光会CURD，我还会cache。你的嘲笑我并不在意，它并没有进入我的五脏六腑，我只是把它缓存起来，介绍完今天这篇文章，cache即将到期，所有的记忆也将随风而去。现在的年轻人，做什么事情总是迫不及待，狂点刷新，如果我们不引入cache这个概念，那我们的DB早晚得崩，redis也应运而生：
一、redis穿透的原因以及解决方案
1、什么是redis穿透？
常见的缓存系统，都是按照key值先去缓存查询，如果不存在对应的value，就去DB中查找 。这个时候，如果缓存中不存在的key的请求量很大，就会对后端的DB系统造成很大的压力，这就叫做缓存穿透。（可能有坏人去故意遍历你的缓存key，导致你不断的请求DB，给DB造成巨大压力。）
2、解决方案？
1）避免用自增id来查询数据，比如获取用户基本信息的接口，id一旦自增，别人就可以写个循环伪造id不断的获取用户数据。可以使用token来代替自增id，先去redis中查下token是否有效，无效的token直接返回error。
2）中间件中做基础的过滤，屏蔽可疑参数和可疑请求。
二、redis雪崩的原因以及解决方案
1、什么是redis雪崩？
因为redis承载了大量的请求，有效的保护了DB，但是如果redis由于某些原因，没有及时的阻止大量的请求，于是所有的请求，就会到达DB，DB的调用量就会暴增，造成DB也会宕机。
案例：程序员小哥开发一个新闻系统，所以的缓存过期日期都是三小时，三小时后如果系统访问量比较集中，恰巧缓存大量过期，这样就会导致大量数据会去直接访问DB，此时给DB很大的压力，甚至有宕机的风险。
2、解决方案？
1）不同类型的缓存key，可以设置不同的过期时间，让缓存失效的时间点不一致，尽量达到平均分布。
2）DB配置主从，即时大量的查询堆积，对主服务器也没什么影响（MySQL的主从配置我在前面的文章有介绍）
三、redis的命中率
用户在访问缓存中的数据时，并不是100%会返回的，可能有不返回的情况，这种情况下就得去DB查询数据，为了提高系统的性能，我们需要提高缓存的命中率。redis中info命令可以查询到基本信息。
命中率 = keyspace_hits / (keyspace_misses + keyspace_hits)
合理的redis配置可以提高命中率哦。
