一次性理解内存穿透、内存雪崩、内存击穿
本文参考：https://segmentfault.com/a/1190000014262882
https://baijiahao.baidu.com/s?id=1619572269435584821&wfr=spider&for=pc
Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API；它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Hash), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。
Redis功能太强大了，单线程、采用网络IO多路复用技术来保证在多连接的时候， 系统的高吞吐量。可用于分布式锁，分布式缓存等。。。关于它的好处就不做阐述了，这里主要讲一下，使用过程中需要预防的一些风险。
一.阻塞问题
redis是单线程，如果某个命令执行时间过长，那么就必然造成其他命令的阻塞，这将是致命的；
产生阻塞的场景：
1. API或数据类型使用不合理
1.1. 避免使用一些易造成阻塞的命令，例如：keys sort hgetall smembers。执行showlog get [n] 可以获取最近n条执行慢的记录，对于执行超过一定时间(默认10ms，线上建议设置为1ms)的命令都会记录到一个定长队列(默认128，可调整)中。
1.2. 防止一次操作获取过多数据：缩减大对象或者把大对象拆分为多个小对象发现大对象的命令：redis-cli -h{ip} -p{port} bigkeys。
内部原理：采用分段进行scan操作，把历史扫描过的大对象统计出来
1.3. 防止大量key同时过期：如果有很多key在同一秒内过期，超过了所有key的25%，redis主线程就会阻塞直到过期key比例下降到25%以内，因此要避免同一时间过期大量key，过期时间可做散列处理。redis4.0引入的lazyfree机制可以避免del、flushdb、flushall、rename等命令引起的redis-server阻塞，提高服务稳定性。
- CPU饱和
2.1 单线程的redis处理命令时只能使用一个CPU，CPU饱和是指redis把单核的CPU使用率跑到接近100%。首先要确定redis的并发量是否达到极限，通过redis-cli-h{ip} -p{port}--stat 获取redis当前使用情况。如果达到每秒6w+左右的qps，说明单台已跑到极限，需要水平扩展。如果qps只有几百或者几千CPU就已经饱和，可能使用了高算法复杂度的命令或者是对内存的过度优化(如放宽了ziplist的使用条件，虽然使用的内存会变少，但是更耗CPU)。 - 持久化操作
持久化引起主线程的阻塞操作主要有：fork阻塞、AOF刷盘阻塞、HugePage写操作阻塞
3.1. fork阻塞：发生在RDB和AOF重写时，redis主线程调用fork操作产生共享内存的子线程，由子线程完成持久化文件的重写工作，若fork操作耗时过长会引起阻塞。避免使用内存过大的实例。
3.2. AOF刷盘阻塞：开启AOF持久化功能时，一般会采用1次/s的刷盘方式，后台线程每秒对AOF文件做fsync操作，当硬盘压力过大时fsync操作需要等待直到写入完成。如果主线程距离上一次的fsync成功超过2s，为了数据安全会阻塞直到后台线程执行完fsync完成。这种阻塞是由于磁盘压力引起。尽量独立部署。
3.3. HugePage写操作阻塞：子进程在执行重写期间利用linux的copyonwrite机制，会拖慢写操作的执行时间，导致大量写操作慢查询。优化linux配置。
二.缓存穿透
是指查询一个不存在的数据，缓存层和存储层都不能命中，且不把空结果写入缓存中。一旦缓存穿透，会导致后端存储负载变大，造成后端存储宕机等问题。可以在程序中分别统计总调用数、缓存命中数、存储命中数，若有大量存储层空命中，可能是出现了缓存穿透。
产生原因：
1. 自身代码或数据出现问题
2. 恶意攻击，爬虫造成空命中
解决方案：
1.缓存空对象，存储层不命中，扔将空对象保存到缓存层。
1.1适用场景：数据频繁变化、实时性高
1.2带来问题：a缓存了空值，会占用内存空间；可以设置较短过期时间，自动剔除；b数据不一致，若存储层添加了此数据，有短暂不一致；可主动清除掉缓存的空对象。
2.布隆过滤器
2.1在访问缓存层和数据层之前将存在的key用布隆过滤器提前保存起来，做第一层拦截。
2.1.1适用场景：大用户集，实时性要求较低的场景，如有几亿的数据集，每隔一段时间会新增用户进去，在更新之前新用户的访问会存在缓存穿透问题。
缺点：代码维护复杂
三. 缓存雪崩
由于缓存层承载着大量请求，有效的保护了存储层，但如果缓存层由于某些原因不能提供服务，所有请求都会压到存储层，存储层流量暴增，导致存储层也会级联宕机。
还有一种场景（阻塞问题1.3），比如双十一凌晨，会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。
1.解决方案：
1.1. 保证缓存层服务高可用性
Redis Sentinel或者Redis Cluster都实现了高可用
1.2.隔离限流降级
对重要的资源Redis、Mysql、外部接口调用都进行隔离，机器、进程、线程等层面都可做隔离。
可使用漏桶、令牌桶等方式进行限流操作，将流量挡在应用上层。对出现问题的数据或功能做降级处理，友好的展示给用户。提前演练测试。
四.缓存击穿
缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
其实，大多数情况下这种爆款很难对数据库服务器造成压垮性的压力。达到这个级别的公司没有几家的。所以，务实主义的小编，对主打商品都是早早的做好了准备，让缓存永不过期。即便某些商品自己发酵成了爆款，也是直接设为永不过期就好了。
大道至简，mutex key互斥锁真心用不上。
