Day12_12_Redis教程之Redis面试题

约定不等于承诺〃 2024-02-19 20:15 47阅读 0赞

## 12\_Redis教程之Redis面试题 ##

#### 1. 什么是Redis?简述它的优缺点? ####

Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存.

因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过 10万次读写操作,是已知性能最快的Key-Value DB.

Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存多种数据结构,此外单个value的最大限制是1GB,不像 memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能.

比方说用他的List来做FIFO双向链表,实现一个轻量级的高性能消息队列服务,用他的Set可以做高性能的tag系统等等.

另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memcached来用. Redis的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上.

#### 2. Redis有哪几种数据淘汰策略? ####

1️⃣.**noeviction:**  
返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令(大部分的写入指令,但DEL和几个例外).

2️⃣.**allkeys-lru:**  
尝试回收最少使用的键(LRU),使得新添加的数据有空间存放.

3️⃣.**volatile-lru:**  
尝试回收最少使用的键(LRU),但仅限于在过期集合的键,使得新添加的数据有空间存放.

4️⃣.**allkeys-random:**  
回收随机的键使得新添加的数据有空间存放.

5️⃣.**volatile-random:**  
回收随机的键使得新添加的数据有空间存放,但仅限于在过期集合的键.

6️⃣.**volatile-ttl:**  
回收在过期集合的键,并且优先回收存活时间(TTL)较短的键,使得新添加的数据有空间存放.

#### 3. 一个字符串类型的值能存储最大容量是多少? ####

512M

#### 4. 为什么Redis需要把所有数据放到内存中？ ####

Redis为了达到最快的读写速度将数据都读到内存中,并通过异步的方式将数据写入磁盘.

所以redis具有快速和数据持久化的特征.如果不将数据放在内存中,磁盘I/O速度为严重影响redis的性能.

在内存越来越便宜的今天,redis将会越来越受欢迎.如果设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值.

#### 5. Redis集群方案应该怎么做?都有哪些方案? ####

1️⃣.**codis**:  
目前用的最多的集群方案,基本和twemproxy一致的效果,但它支持在节点数量改变情况下,旧节点数据可恢复到新hash节点.

2️⃣.**redis cluster3.0自带的集群**:特点在于他的分布式算法不是一致性hash,而是hash槽的概念,以及自身支持节点设置从节点,具体看官方文档介绍.

3️⃣.**在业务代码层实现**:开启几个毫无关联的redis实例,在代码层,对key 进行hash计算,然后去对应的redis实例操作数据.这种方式对hash层代码要求比较高,考虑部分包括,节点失效后的替代算法方案,数据震荡后的自动脚本恢复,实例的监控.

#### 6. Redis集群方案什么情况下会导致整个集群不可用? ####

有A/B/C三个节点的集群,在没有复制模型的情况下,如果节点B失败了,那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.

#### 7. MySQL里有2000w数据,redis中只存20w的数据,如何保证redis中的数据都是热点数据? ####

redis内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略.

#### 8. 说说Redis哈希槽的概念? ####

Redis集群没有使用一致性hash,而是引入了哈希槽的概念,Redis集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽,集群的每个节点负责一部分hash槽.

#### 9. Redis集群的主从复制模型是怎样的? ####

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用,所以集群使用了主从复制模型,每个节点都会有N-1个复制品.

#### 10. Redis集群会有写操作丢失吗?为什么? ####

Redis并不能保证数据的强一致,这意味这在实际中集群在特定的条件下可能会丢失写操作.

#### 11. Redis集群之间是如何复制的？ ####

异步复制

#### 12. Redis集群最大节点个数是多少？ ####

16384个

#### 13. Redis集群如何选择数据库? ####

Redis集群目前无法做数据库选择,默认在0数据库.

#### 14. 怎么理解Redis事务？ ####

事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行.事务在执行的过程中,不会被其他客户端发送来的命令请求所打断.

事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行.

#### 15. Redis事务相关的命令有哪几个？ ####

MULTI、EXEC、DISCARD、WATCH

#### 16. Redis如何做内存优化? ####

尽可能使用散列表(hashes),散列表(是说散列表里面存储的数少)使用的内存非常小,所以你应该尽可能的将你的数据模型抽象到一个散列表里面.

比如你的web系统中有一个用户对象,不要为这个用户的名称,姓氏,邮箱,密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面.

#### 17. 聊聊 Redis 使用场景== ####

*  缓存
 *  会话缓存
 *  时效性
 *  访问频率
 *  计数器
 *  社交列表
 *  记录用户判定信息
 *  交集、并集和差集
 *  热门列表与排行榜
 *  最新动态
 *  消息队列

#### 18. Redis支持哪几种数据类型? ####

String、List、Set、Sorted Set、hash.

如果你是Redis中高级用户,还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub.

如果你说还用过Redis Module,像BloomFilter,RedisSearch,Redis-ML等类型,会更好.

#### 19. Redis主要消耗什么物理资源? ####

内存.

#### 20. Redis集群的主从复制模型是怎样的？ ####

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用,所以集群使用了主从复制模型,每个节点都会有N-1个复制品.

#### 21. Redis集群会有写操作丢失吗?为什么? ####

Redis并不能保证数据的强一致性,这意味这在实际中集群在特定的条件下可能会丢失写操作.

#### 22. Redis中的管道有什么用? ####

一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应.这样就可以将多个命令发送到服务器,而不用等待回复,最后在一个步骤中读取该答复.

这就是管道(pipelining),是一种几十年来广泛使用的技术,例如许多POP3协议已经实现支持这个功能,大大加快了从服务器下载新邮件的过程.

#### 23. Redis回收进程如何工作的? ####

一个客户端运行了新的命令,添加了新的数据.

Redi检查内存使用情况,如果大于maxmemory的限制,则根据设定好的策略进行回收.

一个新的命令被执行.

所以我们不断地穿越内存限制的边界,通过不断达到边界然后不断地回收回到边界以下.

如果一个命令的结果导致大量内存被使用(例如很大的集合的交集保存到一个新的键),不用多久内存限制就会被这个内存使用量超越.

#### 24. 使用过 Redis 分布式锁么?它是怎么实现的? ####

先拿 setnx 来争抢锁,抢到之后,再用 expire 给锁加一个过期时间防止锁忘记了释放.

如果在 setnx 之后执行 expire 之前进程意外 crash 或者要重启维护了,那会怎么样?

set 指令有非常复杂的参数,这个应该是可以同时把 setnx 和 expire 合成一条指令来用的.

#### 25. 使用过 Redis 做异步队列么,你是怎么用的？有什么缺点？ ####

般使用 list 结构作为队列,rpush 生产消息,lpop 消费消息.当 lpop 没有消息的时候,要适当 sleep一会再重试.

**缺点:**

在消费者下线的情况下,生产的消息会丢失,得使用专业的消息队列如 rabbitmq 等.

**能不能一次生产多次消费呢?**

使用 pub/sub 主题订阅者模式,可以实现 1:N 的消息队列.

#### 26. 什么是缓存穿透？如何避免？什么是缓存雪崩？何如避免？ ####

缓存穿透

一般的缓存系统,都是按照 key 去缓存查询,如果不存在对应的 value,就应该去后端系统查找(比如DB).一些恶意的请求会故意查询不存在的 key,请求量很大,就会对后端系统造成很大的压力,这就叫做缓存穿透.

如何避免？

*  对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该 key 对应的数据 insert 了之后清理缓存;
 *  对一定不存在的 key 进行过滤,可以把所有的可能存在的 key 放到一个大的 Bitmap 中,查询时通过该 bitmap 过滤.

缓存雪崩

当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,会给后端系统带来很大压力,导致系统崩溃.

如何避免？

*  1️⃣.在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量,比如对某个 key 只允许一个线程查询数据和写缓存,其他线程等待;
 *  2️⃣.做二级缓存,A1 为原始缓存,A2 为拷贝缓存,A1 失效时,可以访问 A2,A1 缓存失效时间设置为短期,A2 设置为长期;
 *  3️⃣.不同的 key,设置不同的过期时间,让缓存失效的时间点尽量均匀.

#### 27. Redis 有哪些架构模式？讲讲各自的特点 ####

#### <1>. 单机版 ####

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70][]

特点:

简单.

问题:

*  1️⃣.内存容量有限;
 *  2️⃣.处理能力有限;
 *  3️⃣.无法高可用.

#### <2>. 主从复制 ####

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 1][]

*  1️⃣.Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品,其中被复制的服务器为主服务器(master),而通过复制创建出来的服务器复制品则为从服务器(slave).只要主从服务器之间的网络连接正常,主从服务器两者会具有相同的数据,主服务器就会一直将发生在自己身上的数据更新同步给从服务器,从而一直保证主从服务器的数据相同.特点:master/slave 角色;
 *  2️⃣.master/slave 数据相同;
 *  3️⃣.降低 master 读压力在转交从库.

问题:

*  无法保证高可用;
 *  没有解决 master 写的压力.

#### <3>. 哨兵 ####

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 2][]

Redis sentinel 是一个分布式系统中监控 redis 主从服务器,并在主服务器下线时自动进行故障转移.

其中三个特性:

*  监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常;
 *  提醒(Notification): 当被监控的某个 Redis 服务器出现问题时,Sentinel 可以通过 API 向管理员或者其他应用程序发送通知;
 *  自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时,Sentinel 会开始一次自动故障迁移操作.

特点:

*  1️⃣.保证高可用;
 *  2️⃣.监控各个节点;
 *  3️⃣.自动故障迁移.

缺点:

*  1️⃣.主从模式,切换需要时间丢数据;
 *  2️⃣.没有解决 master 写的压力.

#### <4>. 集群(proxy 型): ####

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 3][]

Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器. Twemproxy 是一个快速的单线程代理程序,支持 Memcached ASCII 协议和 redis 协议.

特点:

*  1️⃣.多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins;
 *  2️⃣.支持失败节点自动删除;
 *  3️⃣.后端 Sharding 分片逻辑对业务透明,业务方的读写方式和操作单个 Redis 一致.

缺点:

*  1️⃣.增加了新的 proxy,需要维护其高可用;
 *  2️⃣.failover 逻辑需要自己实现,其本身不能支持故障的自动转移可扩展性差,进行扩缩容都需要手动干预.

#### <5>. 集群(直连型): ####

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 4][]

从redis 3.0之后版本支持redis-cluster集群,Redis-Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接.

特点:

*  无中心架构(不存在哪个节点影响性能瓶颈),少了 proxy 层;
 *  数据按照 slot 存储分布在多个节点,节点间数据共享,可动态调整数据分布;
 *  可扩展性,可线性扩展到 1000 个节点,节点可动态添加或删除;
 *  高可用性,部分节点不可用时,集群仍可用,通过增加 Slave 做备份数据副本;
 *  实现故障自动 failover,节点之间通过 gossip 协议交换状态信息,用投票机制完成 Slave到 Master的角色提升.

缺点:

*  1️⃣.资源隔离性较差,容易出现相互影响的情况;
 *  2️⃣.数据通过异步复制,不保证数据的强一致性.

#### 28. 什么是Redis持久化？Redis有哪几种持久化方式？优缺点是什么？ ####

持久化就是把内存的数据写到磁盘中去,防止服务宕机了内存数据丢失. Redis 提供了两种持久化方式:RDB(默认)和AOF.

#### RDB持久化方案: ####

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 5][]

rdb是Redis DataBase缩写,核心函数rdbSave(生成RDB文件)和rdbLoad(从文件加载内存)两个函数.

#### AOF持久化方案: ####

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 6][]

Aof是Append-only file缩写,每当执行服务器(定时)任务或者函数时,flushAppendOnlyFile 函数都会被调用,这个函数执行以下两个工作aof写入保存;  
WRITE:根据条件,将 aof\_buf 中的缓存写入到 AOF 文件;  
SAVE:根据条件,调用 fsync 或 fdatasync 函数,将 AOF 文件保存到磁盘中.

存储结构:

内容是redis通讯协议(RESP )格式的命令文本存储.

比较:

*  aof文件比rdb更新频率高,优先使用aof还原数据;
 *  aof比rdb更安全也更大;
 *  rdb性能比aof好;
 *  如果两个都配了优先加载AOF.

#### 29. redis 如何高并发和高可用？哨兵原理能介绍一下么？ ####

这个问题主要是考查 redis 单机能承载多高并发? 如果单机扛不住如何进行扩容,以便承载更多的并发? redis 会不会挂? 既然 redis 会挂那怎么保证 redis 是高可用的?

如果你用 redis 缓存技术的话,肯定要考虑如何用 redis 来加多台机器,保证 redis 是高并发的,还有就是如何让 redis 保证自己不是挂掉以后就直接死掉了,即 redis 高可用.

*  1️⃣.redis 主从架构;
 *  2️⃣.redis 基于哨兵实现高可用;
 *  3️⃣.redis 集群.

redis 实现高并发主要依靠主从架构,一主多从.一般来说,主从架构应对很多项目其实就足够了.一主用来写入数据,单机几万 QPS;多从用来查询数据,多个从实例可以提供每秒 10w 的 QPS.

如果想要在实现高并发的同时,容纳大量的数据,那么就需要 redis 集群,使用 redis 集群之后,可以提供每秒几十万的读写并发.

redis 高可用,如果是做主从架构部署,那么加上哨兵就可以了,任何一个实例宕机,可以进行主备切换.

#### 30. 如何解决缓存雪崩? ####

#### 1.1 什么是缓存雪崩？ ####

回顾一下我们为什么要用缓存(Redis):  
![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 7][]

现在有个问题,如果我们的缓存挂掉了,这意味着我们的全部请求都跑去数据库了.  
![Image 1][]

在前面学习我们都知道Redis不可能把所有的数据都缓存起来(内存昂贵且有限),所以**Redis需要对数据设置过期时间,并采用的是惰性删除+定期删除两种策略对过期键删除.**

如果缓存数据设置的过期时间是相同的,并且Redis恰好将这部分数据全部删光了.这就会导致在这段时间内,这些缓存同时失效,全部请求到数据库中,这就是缓存雪崩:

*  Redis挂掉了,请求全部走数据库;
 *  对缓存数据设置相同的过期时间,导致某段时间内缓存失效,请求全部走数据库.

缓存雪崩如果发生了,很可能就把我们的数据库搞垮,导致整个服务瘫痪!

#### 1.2 如何解决缓存雪崩? ####

情况一:

对于“对缓存数据设置相同的过期时间,导致某段时间内缓存失效,请求全部走数据库”这种情况,非常好解决.

解决方法:

在缓存的时候给过期时间加上一个随机值,这样就会大幅度的减少缓存在同一时间过期.

情况二:

对于“Redis挂掉了,请求全部走数据库”这种情况,我们可以有以下的思路:

**事发前:**  
实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster),尽量避免Redis挂掉这种情况发生;

**事发中:**  
万一Redis真的挂了,我们可以设置本地缓存(ehcache)+限流(hystrix),尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的);

**事发后:**  
redis持久化,重启后自动从磁盘上加载数据,快速恢复缓存数据.

#### 31. 如何解决缓存穿透? ####

#### 1.1 什么是缓存穿透 ####

比如,我们有一张数据库表,ID都是从1开始的(正数):  
![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 8][]

但是可能有黑客想把我们的数据库搞垮,每次请求的ID都是负数.这会导致我们的缓存就没用了,请求全部都找数据库去了,但数据库也没有这个值啊,所以每次都返回空出去.

缓存穿透是指查询一个一定不存在的数据,由于缓存无法命中,并且出于容错考虑,如果从数据库查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,失去了缓存的意义.  
![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 9][]  
这就是缓存穿透.

请求的数据在缓存中大量的无法命中,导致请求走数据库.

缓存穿透如果发生了,也可能把我们的数据库搞垮,导致整个服务瘫痪!

#### 1.2 如何解决缓存穿透？ ####

解决缓存穿透也有两种方案:

*  由于请求的参数是不合法的(每次都请求不存在的参数),于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截,不合法就不让这个请求到数据库层.
 *  当我们从数据库找不到的时候,我们也将这个空对象设置到缓存里边去.下次再请求的时候,就可以从缓存里边获取了.这种情况我们一般会将空对象设置一个较短的过期时间.

#### 32. 如何保证缓存与数据库双写时一致的问题? ####

#### 1. 对于读操作,流程是这样的 ####

上面讲缓存穿透的时候也提到了:  
如果从数据库查不到数据则不写入缓存.

一般我们对读操作的时候有这么一个固定的套路:

*  如果我们的数据在缓存里边有,那么就直接取缓存的;
 *  如果缓存里没有我们想要的数据,我们会先去查询数据库,然后将数据库查出来的数据写到缓存中;
 *  最后将数据返回给请求.

#### 2. 什么是缓存与数据库双写一致问题? ####

如果仅仅查询的话,缓存的数据和数据库的数据是没问题的.但是,当我们要更新时候呢?各种情况很可能就造成数据库和缓存的数据不一致了.

这里不一致指的是:数据库的数据跟缓存的数据不一致.

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 10][]

从理论上说,只要我们设置了键的过期时间,我们就能保证缓存和数据库的数据最终是一致的.因为只要缓存数据过期了,就会被删除.随后读的时候,因为缓存里没有,就可以查数据库的数据,然后将数据库查出来的数据写入到缓存中.

除了设置过期时间,我们还需要做更多的措施来尽量避免数据库与缓存处于不一致的情况发生.

#### 1.3 对于更新操作 ####

一般来说,执行更新操作时,我们会有两种选择:

*  先操作数据库,再操作缓存;
 *  先操作缓存,再操作数据库.

首先要明确的是,无论我们选择哪个,我们都希望这两个操作要么同时成功,要么同时失败.所以这会演变成一个分布式事务的问题.

如果原子性被破坏了,可能会有以下的情况:

*  操作数据库成功了,操作缓存失败了;
 *  操作缓存成功了,操作数据库失败了.

如果第一步已经失败了,我们直接返回Exception出去就好了,第二步根本不会执行.

下面我们具体来分析一下吧.

#### 1.3.1 操作缓存 ####

操作缓存也有两种方案:

*  更新缓存;
 *  删除缓存.

一般我们都是采取删除缓存缓存策略的,原因如下:

*  高并发环境下,无论是先操作数据库还是后操作数据库而言,如果加上更新缓存,那就更加容易导致数据库与缓存数据不一致问题(删除缓存直接和简单很多);
 *  如果每次更新了数据库,都要更新缓存【这里指的是频繁更新的场景，这会耗费一定的性能】,倒不如直接删除掉.等再次读取时,缓存里没有,那我到数据库找,在数据库找到再写到缓存里边(体现懒加载).

基于这两点,对于缓存在更新时而言,都是建议执行删除操作.

#### 1.3.2 先更新数据库,再删除缓存 ####

正常的情况是这样的:

*  先操作数据库,成功;
 *  再删除缓存,也成功.

如果原子性被破坏了:

*  第一步成功(操作数据库),第二步失败(删除缓存),会导致数据库里是新数据,而缓存里是旧数据;
 *  如果第一步(操作数据库)就失败了,我们可以直接返回错误(Exception),不会出现数据不一致.

如果在高并发的场景下,出现数据库与缓存数据不一致的概率特别低,也不是没有:

*  缓存刚好失效;
 *  线程A查询数据库,得一个旧值;
 *  线程B将新值写入数据库;
 *  线程B删除缓存;
 *  线程A将查到的旧值写入缓存.

要达成上述情况,还是说一句概率特别低:

因为这个条件需要发生在读缓存时缓存失效,而且并发着有一个写操作.而实际上数据库的写操作会比读操作慢得多,而且还要锁表,而读操作必需在写操作前进入数据库操作,而又要晚于写操作更新缓存,所有的这些条件都具备的概率基本并不大.

对于这种策略,其实是一种设计模式:Cache Aside Pattern.

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 11][]

删除缓存失败的解决思路:

将需要删除的key发送到消息队列中  
自己消费消息,获得需要删除的key  
不断重试删除操作,直到成功.

#### 1.3.3 先删除缓存,再更新数据库 ####

正常情况是这样的:

*  先删除缓存,成功;
 *  再更新数据库,也成功.

如果原子性被破坏了:

*  第一步成功(删除缓存),第二步失败(更新数据库),数据库和缓存的数据还是一致的;
 *  如果第一步(删除缓存)就失败了,我们可以直接返回错误(Exception),数据库和缓存的数据还是一致的.

看起来是很美好,但是我们在并发场景下分析一下,就知道还是有问题的:

*  线程A删除了缓存;
 *  线程B查询,发现缓存已不存在;
 *  线程B去数据库查询得到旧值;
 *  线程B将旧值写入缓存;
 *  线程A将新值写入数据库.

所以也会导致数据库和缓存不一致的问题.

并发下解决数据库与缓存不一致的思路:

*  将删除缓存、修改数据库、读取缓存等的操作积压到队列里边,实现串行化.

![Image 1][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 12][]

#### 1.4 两种策略对比 ####

我们可以发现,两种策略各自有优缺点:

*  先删除缓存,再更新数据库;
 *  在高并发下表现不如意,在原子性被破坏时表现优异;
 *  先更新数据库,再删除缓存(Cache Aside Pattern设计模式);
 *  在高并发下表现优异,在原子性被破坏时表现不如意.

#### 1.5 其他保障数据一致的方案与资料 ####

可以用databus或者阿里的canal监听binlog进行更新.

#### 33. 假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的前缀开头的,如果将它们全部找出来？ ####

使用keys指令可以扫出指定模式的key列表.

对方接着追问: 如果这个redis正在给线上的业务提供服务,那使用keys指令会有什么问题?

这个时候你要回答redis关键的一个特性: redis的单线程的. keys指令会导致线程阻塞一段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复.这个时候可以使用scan指令,scan指令可以无阻塞的提取出指定模式的key列表,但是会有一定的重复概率,在客户端做一次去重就可以了,但是整体所花费的时间会比直接用keys指令长.

#### 34. 如果有大量的key需要设置同一时间过期,一般需要注意什么？ ####

如果大量的key过期时间设置的过于集中,到过期的那个时间点,redis可能会出现短暂的卡顿现象.一般需要在时间上加一个随机值,使得过期时间分散一些.

#### 35. 使用过Redis分布式锁么,它是什么回事？ ####

先拿setnx来争抢锁,抢到之后,再用expire给锁加一个过期时间防止锁忘记了释放.

然后面试官可能接着问如果在setnx之后执行expire之前进程意外crash或者要重启维护了,那会怎么样?

可以说set指令有非常复杂的参数,可以同时把setnx和expire合成一条指令来用.

#### 36. 使用过Redis做异步队列么,你是怎么用的？ ####

一般使用list结构作为队列,rpush生产消息,lpop消费消息.当lpop没有消息的时候,要适当sleep一会再重试.

如果对方追问可不可以不用sleep呢?list还有个指令叫blpop,在没有消息的时候,它会阻塞住直到消息到来.

如果对方追问能不能一次生产多次消费呢?

使用pub/sub主题订阅者模式,可以实现1:N的消息队列.

如果对方追问pub/sub有什么缺点?  
在消费者下线的情况下,生产的消息会丢失,得使用专业的消息队列如rabbitmq等.

如果对方追问redis如何实现延时队列?  
可以使用sortedset,拿时间戳作为score,消息内容作为key调用zadd来生产消息,消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理.

#### 37. Redis的同步机制了解么？ ####

Redis可以使用主从同步,从从同步.第一次同步时,主节点做一次bgsave,并同时将后续修改操作记录到内存buffer,待完成后将rdb文件全量同步到复制节点,复制节点接受完成后将rdb镜像加载到内存.加载完成后,再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程.

#### 38. Redis的管道Pipeline有什么好处,为什么要用pipeline? ####

一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应,这样就可以将多个命令发送到服务器,而不用等待回复,最后在一个步骤中读取该答复.

#### 39. Redis集群之间是如何复制的？ ####

异步复制.

#### 40. Redis key的过期时间和永久有效分别怎么设置？ ####

EXPIRE和PERSIST命令.

#### 41. Redis如何做内存优化？ ####

尽可能使用散列表(hashes),散列表使用的内存非常小,所以你应该尽可能的将你的数据模型抽象到一个散列表里面.比如你的web系统中有一个用户对象,不要为这个用户的名称/姓氏/邮箱/密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面.

#### 42. Redis如何做大量数据插入？ ####

Redis2.6开始redis-cli支持一种新的被称之为pipe mode的新模式用于执行大量数据插入工作.

#### 43. 为什么要做Redis分区？ ####

分区可以让Redis管理更大的内存,Redis将可以使用所有机器的内存.如果没有分区,你最多只能使用一台机器的内存.分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长.

#### 44. 你知道有哪些Redis分区实现方案？ ####

**客户端分区:**  
就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取,大多数客户端已经实现了客户端分区.

**代理分区:**  
意味着客户端将请求发送给代理,然后代理决定去哪个节点写数据或者读数据.代理根据分区规则决定请求哪些Redis实例,然后根据Redis的响应结果返回给客户端,redis和memcached的一种代理实现就是Twemproxy.

**查询路由(Query routing)分区:**  
意思是客户端随机地请求任意一个redis实例,然后由Redis将请求转发给正确的Redis节点.Redis Cluster实现了一种混合形式的查询路由,但并不是直接将请求从一个redis节点转发到另一个redis节点,而是在客户端的帮助下直接redirected到正确的redis节点.

#### 45. Redis分区有什么缺点？ ####

1️⃣.涉及多个key的操作通常不会被支持.例如你不能对两个集合求交集,因为他们可能被存储到不同的Redis实例(实际上这种情况也有办法,但是不能直接使用交集指令).

2️⃣.同时操作多个key,则不能使用Redis事务.  
分区使用的粒度是key,不能使用一个非常长的排序key存储一个数据集(The partitioning granularity is the key, so it is not possible to shard a dataset with a single huge key like a very big sorted set).

3️⃣.当使用分区的时候,数据处理会非常复杂.例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件.

4️⃣.分区时动态扩容或缩容可能非常复杂.Redis集群在运行时增加或者删除Redis节点,能做到最大程度对用户透明地数据再平衡,但其他一些客户端分区或者代理分区方法则不支持这种特性.然而,有一种预分片的技术也可以较好的解决这个问题.

#### 46. 分布式Redis是前期做还是后期规模上来了再做好？为什么？ ####

既然Redis是如此的轻量(单实例只使用1M内存),为防止以后的扩容,最好的办法就是一开始就启动较多实例.即便你只有一台服务器,你也可以一开始就让Redis以分布式的方式运行,使用分区,在同一台服务器上启动多个实例.

一开始就多设置几个Redis实例,例如32或者64个实例,对大多数用户来说这操作起来可能比较麻烦,但是从长久来看做这点牺牲是值得的.

这样的话,当你的数据不断增长,需要更多的Redis服务器时,你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已(而不用考虑重新分区的问题).一旦你添加了另一台服务器,你需要将你一半的Redis实例从第一台机器迁移到第二台机器.

#### 47. 支持一致性哈希的客户端有哪些？ ####

Redis-rb、Predis等.

#### 48. 都有哪些办法可以降低Redis的内存使用情况呢？ ####

如果你使用的是32位的Redis实例,可以好好利用Hash,list,sorted set,set等集合类型数据,因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起.

#### 49. Redis是单线程的,如何提高多核CPU的利用率？ ####

可以在同一个服务器部署多个Redis的实例,并把他们当作不同的服务器来使用.在某些时候,无论如何一个服务器是不够的,所以如果你想使用多个CPU,你可以考虑一下分片(shard).

#### 50. Redis常见性能问题和解决方案? ####

1️⃣.Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件;

2️⃣.如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次;

3️⃣.为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内;

4️⃣.尽量避免在压力很大的主库上增加从库;

5️⃣.主从复制不要用图状结构,用单向链表结构更为稳定,即Master <- Slave1 <- Slave2 <- Slave3...

这样的结构方便解决单点故障问题,实现Slave对Master的替换.如果Master挂了,可以立刻启用Slave1做Master,其他不变.

#### 51. 修改配置不重启Redis会实时生效吗？ ####

针对运行实例,有许多配置选项可以通过 CONFIG SET 命令进行修改,而无需执行任何形式的重启.从 Redis 2.2 开始,可以从 AOF 切换到 RDB 的快照持久性或其他方式而不需要重启 Redis.检索 ‘CONFIG GET \*’ 命令获取更多信息.

但偶尔重新启动是必须的,如为升级 Redis 程序到新的版本,或者当你需要修改某些目前 CONFIG 命令还不支持的配置参数的时候.

[Image 1]: 
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/4fa9ef3b1dc5482f90d71bfae4215e10.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/d6a842fd3ef547949e3e28970735f259.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/fa3ca8f60c5f41d9adde90904d7194ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/fda908a34ea8401ebfd568f4ffe1b5c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/6640ccb8d1aa4e3ab4179a5a8a0b2737.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/5c4ad429ecdd4b279fad3e7ddcb4e937.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/f054265ca35d4b0390e1b4ee9a391ac9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/4811febcc97d4197be4100a01e433334.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/fa784d83ba0f499689df15bc999b9a6a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/8bb7cefa1fd846b3926602e8e5632d3d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/869d7a9ce71648acbb0727c16ac0caec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/5e0edcd3e2ad4c7791468be4cc574100.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N5YzAwMDY2Ng_size_16_color_FFFFFF_t_70 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/82c81a2c0fc340f4a3529c52fa7f4848.png