redis缓存雪崩、缓存穿透、缓存击穿

1.redis适合的场景？

（1）会话缓存（session cache）：redis持久化，session共享，主要用于单点登录，缓存token、短信验证码、查询频次高数据。

（2）全页面缓存（FPC）：redis提供磁盘持久化，重启redis实例，加载速度不会改变。

（3）队列：提供内存存储引擎list和set操作。

（4）排行榜/计数器：redis支持集合（set）和有序集合（sorted set），对递增或递减支持非常友好。

（5）发布/订阅：适合在线聊天、消息推送。发布端: publish +频道名称 + 发布内容。订阅端: subscribe + 频道名称。

例如：publish news 'this is a test'，subscribe news。订阅所有人：psubscribe ne*。

 

2.redis默认数据库

（1）redis是一个字典结构的存储服务器。

（2）默认共16个数据库。查看配置文件：/usr/local/redis-5.0.4/redis.conf

（3）客户端和redis建立连接，数据库默认0库。若切换库名，用命令：SELECT 1

（4）一个空redis实例占用内存1M左右。

（5）使用命令：FLUSH ALL，清空所有库中的数据。FLUSH db0，清空0库中的数据。

（6）无权限访问或者全部访问数据库的每个库。

（7）以编号命名，不支持自定义数据库命名。命名以dbX命名。

（8）一个应用程序对应一个Redis实例。

 

3.集群下redis

（1）不支持多个数据库切换，只存在一个db0库。

（2）key批量操作有限：mset、mget必须在一个slot槽。

（3）复制只支持一层，不支持树形复制结构。

（4）key事务和Lua支持有限：操作key必须在一个节点上

（5）key是数据分区的最小粒度，不支持bigkey分区。

（6）redis集群预先分好16384个桶(哈希槽)。

 

4.redis支持的数据类型。

（1）string：最基本数据类型，二进制安全字符串，最大大小512M。

（2）list：按添加顺序保持顺序的字符串列表。

（3）set：无序字符串集合，不存在重复的元素。

（4）sorted set：已排序的字符串集合。

（5）hash：key-value对的一种集合。

 

5.redis线程

（1）Redis是单进程单线程的，Redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销。

（2）多线程处理会涉及到锁，而且多线程处理会涉及到线程切换而消耗CPU。因为CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存或者网络带宽。单线程无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来解决。

 

6.redis优势

（1）速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)

（2）支持丰富数据类型，支持string，list，set，sorted set，hash

（3）支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行

（4）丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除

 

7.缓存雪崩

现象：

（1）缓存失效，大量请求访问redis服务

（2）redis集群大面积故障

（3）redis失效，大量请求转向mysql数据库

（4）mysql请求急剧增加，导致服务器宕机

（5）大量服务依赖于mysql和redis服务，各服务器集群雪崩，直至网站彻底崩溃

解决：

（1）缓存降级：运用ehcache等本地缓存；对源服务访问进行限流、资源隔离（熔断）、设置开关进行自动或者人工降级。如，个性化需求不能提供服务，可以降级补充热点数据，不至于造成前端页面是空白。哪些业务是核心(必须保证)，哪些业务可以容许暂时不提供服务(利用静态页面替换)等，以及配合服务器核心指标，来后设置整体预案。

（1.1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级

（1.2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警

（1.3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级

（1.4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级

（2）缓存高可用性：缓存层设计高可用，Redis Sentinel 和 Redis Cluster 实现高可用。

（3）redis备份和快速预热：redis数据备份和恢复，快速缓存预热

（4）提前演练：在项目上线前，进行缓存层宕掉演练，应用及后端的负载情况及可能出现的问题。

 

8.缓存穿透

现象：

缓存穿透是查询一个不存在数据。缓存redis没有查询到数据，需要从mysql数据库中查询，查不到数据不写入缓存，导致不存在数据每次请求都到数据库查询，造成缓存穿透。

解决：

若查询数据库为空，设置默认值存放到缓存中，之后访问可以直接到缓存中获取值，不继续访问数据库。设置一个过期时间或有值时更新缓存中的值。在缓存中查询值时，可给key设置

一些格式规则，在查询时候将不符合规则的key过滤。

 

9.缓存并发

现象：多个redis的client同时set key引起的并发问题

解决：

redis自身是单线程操作，多个客户端并发操作，按照先到先执行原则，后来的会阻塞。redis在set key操作时，将其放在队列中使其串行话，一个一个执行。

 

10.缓存预热

现象：系统上线后，将相关缓存数据加载到缓存系统。

解决：

直接写缓存刷新页面，上线时可手工操作；若数据量小，可在项目启动时自行加载。最终目的是系统上线前，将数据存放到缓存中，待用户发送请求时，直接查询缓存，不必先查询数据库，然后将数据缓存。

 

11.缓存击穿

现象：

某一个key为热点数据，访问频率高，处于集中式高并发访问情况。当该key失效瞬间，大量请求击穿缓存，直接请求数据库，好似屏风上开了一个小洞。

解决：

（1）热点数据设置永不过期

（2）基于 redis or zookeeper 实现互斥锁，等待第一个请求构建完缓存后，再释放锁，从而其它请求方可通过该 key 访问数据。