2024年Redis原理详解，手握5家大厂offer

最新推荐文章于 2024-10-13 10:28:46 发布

2401_84910888

最新推荐文章于 2024-10-13 10:28:46 发布

阅读量252

点赞数 5

分类专栏：程序员文章标签： go 学习面试

本文链接：https://blog.csdn.net/2401_84910888/article/details/138847588

版权

程序员专栏收录该内容

60 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

appendonly yes

开启后，每当 Redis 执行一个改变数据集的命令时（比如SET），这个命令就会被追加到 AOF 文件的末尾。
这样的话，当 Redis 重新启时，程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。
你可以配置 Redis 多久才将数据fsync到磁盘一次。

有三个选项：

每次有新命令追加到 AOF 文件时就执行一次fsync：非常慢，也非常安全。
每秒fsync一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
从不fsync：将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒fsync一次，这种fsync策略可以兼顾速度和安全性。

RDB 和 AOF ，我应该用哪一个？

如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化，但我们并不推荐这种方式：因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

3、RDB-AOF 混合模式

混合模式是先使用 bgsave 以 RDB 形式将内存中的全部数据写入磁盘，之后当有新的数据时，再使用 AOF 的形式追加到文件中。

aof-use-rdb-preamble yes

****五、Redis 应用

1、模糊查询

Redis 中有 1 亿个 key，其中有 10 万个 key 是已知的某个固定前缀，如何将找出这些 key。

当问题是：如何找出某一前缀的 key。这里需要注意数据规模是多大，再结合实际场景去解决。

如果数据量小，可以使用 keys 命令来查询。

但是，如果数据量大，而 Redis 正在线上运行，使用 keys 命令很可能会阻塞 Redis，使其不能提供服务。
这时可以使用 SCAN cursor [MATCH pattern] [COUNT count] 命令。需要注意的是条命令返回的数量是不可控的，只能大概符合 count。

cursor 从 0 开始，这里第一个返回值为 cursor 用于下一次迭代，当 cursor 再次为 0 时，说明迭代完成。

2、如何通过 Redis 实现分布式锁

首先想到的方法是使用 SETNX key value，如果 key 不存在，则创建并赋值，返回 1；若 key 已存在，则创建失败，返回 0。

当某一个线程通过 SETNX key value 设置成功后占用该资源，其他线程执行该命令就会设置失败，说明已经有线程占用该资源，通过这种方式来实现分布式锁。

同时，为了防止死锁，还需要设置 key 的过期时间 EXPIRE key second，设置 key 的过期时间，经过 second 秒后 key 会被删除。

虽然 Redis 中每个命令都满足原子性，但两个命令组合起来不满足了，例如若设置锁后，程序挂了，来不及设置过期时间，那么这个锁就无法释放了。

所以我们需要把上面两个命令结合起来的命令 SET key value [EX seconds] [PX milliseconds] [NX|XX]，其中 NX 是 key 不存在时设置成功，XX 是 key 存在时设置成功。例如：

这里还需要注意，不要让大量的 key 在同一时间过期，因为删除大量的 key 很耗时，会出现卡顿现象。所以我们可以在设置 key 的过期时间时，加上一个随机值来避免。

3、使用 Redis 实现消息队列

使用 List 作为队列，RPUSH 生产消息，LPOP 消费消息。

但是这样有个缺点，就是只能一对一的消息通信，所以还可以使用 pub/sub 主题订阅者模式，发送者(pub)使用 PUBLISH channel message 发送消息，订阅者(sub)使用 SUBSCRIBE channel 接受消息，并且订阅者可以接收任意数量的 channel。

但是消息的发布是无状态的，无法保证可达性。

4、redis string与hash的数据差别

网路传输时候，必须要进行进行序列化，才可以进行网路传输，那么在使用string类型的类型的时候需要进行相关序列化，hash也是要进行相关的系列化，所以会存在很多序列化，在存储的时候hash是可以存储的更加丰富，但是在反序列化的时候，string的反序列化相对较低，而hash的序列化和返序列化是相对hash类更加复杂，所以看业务场景，如果是数据经常修改的那种，为了性能可以使用string，如果是数据不是经常改的那种就可以使用hash，由于hash，存储数据时比较丰富，可以存储多种数据类型

5、Redis主挂了怎么操作

redis提供了哨兵模式，当主挂了，可以选举其他的进行代替，哨兵模式的实现原理，就是三个定时任务监控，

1 每隔10s，每个S节点（哨兵节点）会向主节点和从节点发送info命令获取最新的拓扑结构

2 每隔2s，每个S节点会向某频道上发送该S节点对于主节点的判断以及当前Sl节点的信息，

同时每个Sentinel节点也会订阅该频道，来了解其他S节点以及它们对主节点的判断（做客观下线依据）

3 每隔1s，每个S节点会向主节点、从节点、其余S节点发送一条ping命令做一次心跳检测(心跳检测机制)，来确认这些节点当前是否可达

当三次心跳检测之后，就会进行投票，当超过半数以上的时候就会将该节点当做主

6、Redis集群

redis集群在3.0以后提供了ruby脚本进行搭建，引入了糙的概念，

Redis集群内节点通过ping/pong消息实现节点通信，消息不但可以传播节点槽信息，还可以传播其他状态如：主从状态、节点故障等。因此故障发现也是通过消息传播机制实现的，主要环节包括：主观下线（pfail）和客观下线（fail）

主观下线：集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应。如果通信一直失败，则发送节点会把接收节点标记为主观下线（pfail）状态。

客观下线：超过半数，对该主节点做客观下线

主节点选举出某一主节点作为领导者，来进行故障转移。

故障转移（选举从节点作为新主节点）

7、内存淘汰策略

Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。

allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。

allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。

volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。

volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

8、缓存穿透（DB的key为空）****

业务系统要查询的数据根本就不存在！当业务系统发起查询时，按照上述流程，首先会前往缓存中查询，由于缓存中不存在，然后再前往数据库中查询。由于该数据压根就不存在，因此数据库也返回空。这就是缓存穿透。

综上所述：业务系统访问压根就不存在的数据，就称为缓存穿透。

危害：如果存在海量请求查询压根就不存在的数据，那么这些海量请求都会落到数据库中，数据库压力剧增，可能会导致系统崩溃

解决方案：

空值缓存

将数据库查询结果为空的key也存储在缓存中。当后续又出现该key的查询请求时，缓存直接返回null，而无需查询数据库，针对这类数据设置一个较短的过期时间，让其自动剔除。

缺点：空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )

BloomFilter（布隆过滤器）

它需要在缓存之前再加一道屏障，里面存储目前数据库中存在的所有key。当业务系统有查询请求的时候，首先去BloomFilter中查询该key是否存在。若不存在，则说明数据库中也不存在该数据，因此缓存都不要查了，直接返回null。若存在，则继续执行后续的流程，先前往缓存中查询，缓存中没有的话再前往数据库中的查询。

缺点：这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。

9、缓存雪崩（服务宕机）

如果缓存因某种原因发生了宕机，那么原本被缓存抵挡的海量查询请求就会像疯狗一样涌向数据库。此时数据库如果抵挡不了这巨大的压力，它就会崩溃。

解决方法：

1 使用缓存集群，保证缓存高可用，redis集群，通过集群方式将数据放置

2 后端服务降级和限流****，专业工具使用Hystrix****，Hystrix是一款开源的“防雪崩工具”，它通过熔断、降级、限流三个手段来降低雪崩发生后的损失。

Hystrix就是一个Java类库，它采用命令模式，每一项服务处理请求都有各自的处理器。所有的请求都要经过各自的处理器。处理器会记录当前服务的请求失败率。一旦发现当前服务的请求失败率达到预设的值，Hystrix将会拒绝随后该服务的所有请求，直接返回一个预设的结果。这就是所谓的“熔断”。当经过一段时间后，Hystrix会放行该服务的一部分请求，再次统计它的请求失败率。如果此时请求失败率符合预设值，则完全打开限流开关；如果请求失败率仍然很高，那么继续拒绝该服务的所有请求。这就是所谓的“限流”。而Hystrix向那些被拒绝的请求直接返回一个预设结果，被称为“降级”。

后端服务降级和限流：当一个接口请求次数过多，那么就会添加过多数据，可以对服务进行限流，限制访问的数量，这样就可以减少问题的出现

10、缓存击穿（热点数据集中失效）

热点数据集中失效，我们一般都会给缓存设定一个失效时间，过了失效时间后，该数据库会被缓存直接删除，从而一定程度上保证数据的实时性。

但是，对于一些请求量极高的热点数据而言，一旦过了有效时间，此刻将会有大量请求落在数据库上，从而可能会导致数据库崩溃。

解决方案：

互斥锁：此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。

永远不过期：

此方法有效杜绝了热点 key 产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不一致。

11、ZSET跳跃表

跳跃表是一种有序数据结构，它实现了同二分查找一样的平均 O(logN)、最坏 O(N) 复杂度的节点查找。由于它的效率可以和平衡树相媲美，而实现又比平衡树简单，因此很多情况下可以用来代替平衡树。
跳跃表在 Redis 中不如链表和字典等数据结构的应用广泛，只有两个地方用到。一是实现有序集合键，另一个是在集群节点中用作内部数据结构。

12、Redis跳表为何不用树

跳表是一种随机化的数据结构，目前开源软件 Redis 和 LevelDB 都有用到它，它的效率和红黑树以及 AVL 树不相上下，但跳表的原理相当简单

redis使用跳表不用B+数的原因是：redis是内存数据库，而B+树纯粹是为了mysql这种IO数据库准备的。B+树的每个节点的数量都是一个mysql分区页的大小

因为B+树的原理是叶子节点存储数据，非叶子节点存储索引，B+树的每个节点可以存储多个关键字，它将节点大小设置为磁盘页的大小，充分利用了磁盘预读的功能。每次读取磁盘页时就会读取一整个节点,每个叶子节点还有指向前后节点的指针，为的是最大限度的降低磁盘的IO;因为数据在内存中读取耗费的时间是从磁盘的IO读取的百万分之一

而Redis是内存中读取数据，不涉及IO，因此使用了跳表

下面的结构是就是跳表：
其中 -1 表示 INT_MIN，链表的最小值，1 表示 INT_MAX，链表的最大值。

跳表具有如下性质：
(1) 由很多层结构组成
(2) 每一层都是一个有序的链表
(3) 最底层(Level 1)的链表包含所有元素
(4) 如果一个元素出现在 Level i 的链表中，则它在 Level i 之下的链表也都会出现。
(5) 每个节点包含两个指针，一个指向同一链表中的下一个元素，一个指向下面一层的元素。

跳表的搜索

例子：查找元素 117
(1) 比较 21，比 21 大，往后面找
(2) 比较 37, 比 37大，比链表最大值小，从 37 的下面一层开始找
(3) 比较 71, 比 71 大，比链表最大值小，从 71 的下面一层开始找
(4) 比较 85，比 85 大，从后面找
(5) 比较 117，等于 117，找到了节点。

跳表的插入

先确定该元素要占据的层数 K（采用丢硬币的方式，这完全是随机的）
然后在 Level 1 … Level K 各个层的链表都插入元素。
例子：插入 119， K = 2

如果 K 大于链表的层数，则要添加新的层。
例子：插入 119， K = 4

丢硬币决定 K
插入元素的时候，元素所占有的层数完全是随机的，通过一下随机算法产生：

相当与做一次丢硬币的实验，如果遇到正面，继续丢，遇到反面，则停止，
用实验中丢硬币的次数 K 作为元素占有的层数。显然随机变量 K 满足参数为 p = 1/2 的几何分布，
K 的期望值 E[K] = 1/p = 2. 就是说，各个元素的层数，期望值是 2 层。

跳表的删除

在各个层中找到包含 x 的节点，使用标准的 delete from list 方法删除该节点。

例子：删除 71

跳表的高度

n 个元素的跳表，每个元素插入的时候都要做一次实验，用来决定元素占据的层数 K，
跳表的高度等于这 n 次实验中产生的最大 K

跳表的空间复杂度分析

根据上面的分析，每个元素的期望高度为 2，一个大小为 n 的跳表，其节点数目的
期望值是 2n

13、Redis的哨兵机制

什么是哨兵机制?

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议

来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"

哨兵(sentinel) 的一些设计思路和zookeeper非常类似。