redis

简单介绍一下 Redis?

Redis 就是一个使用 C 语言开发的数据库，与传统数据库不同的是 Redis 的数据是存在内存中的 ，也就是它是内存数据库，所以读写速度非常快，因此 Redis 被广泛应用于缓存方向。

另外，Redis 除了做缓存之外，也经常用来做分布式锁，甚至是消息队列。

Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支持事务 、持久化、Lua 脚本、多种集群方案。

Redis 可以做消息队列么？

• Redis 5.0 新增加的一个数据结构 Stream 可以用来做消息队列，Stream 支持：

• 发布 / 订阅模式

• 按照消费者组进行消费

• 消息持久化（ RDB 和 AOF）

不过，和专业的消息队列相比，还是有很多欠缺的地方比如消息丢失和堆积问题不好解决。

• 还可以使用redis自带的发布订阅模式实现广播消息，即使用 pub / sub 主题订阅者模式，可以实现 1:N 的消息队列。

• 还可以使用 list 结构作为队列，rpush生产消息，lpop消费消息。也可以使用BLPOP、BRPOP命令进行阻塞。

• 还可以使用sortedset ，拿时间戳作为 score ，消息内容作为 key 调用 zadd 来生产消息，消费者用 zrangebyscore 指令获取 N 秒之前的数据轮询进行处理。

Redis 单线程模型了解吗？

Redis 基于 Reactor 模式来设计开发了自己的一套高效的事件处理模型 ，这套事件处理模型对应的是 Redis 中的文件事件处理器。由于文件事件处理器是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。

既然是单线程，那怎么监听大量的客户端连接呢？

IO多路复用

简单理解就是：一个服务端进程可以同时处理多个套接字描述符。

• 多路：多个客户端连接（连接就是套接字描述符）
• 复用：使用单进程就能够实现同时处理多个客户端的连接

以上是通过增加进程和线程的数量来并发处理多个套接字，免不了上下文切换的开销，而 IO 多路复用只需要一个进程就能够处理多个套接字，从而解决了上下文切换的问题。

其发展可以分 select->poll→epoll 三个阶段来描述。

如何简单理解 select/poll/epoll 呢？

举栗说明：

领导分配员工开发任务，有些员工还没完成。如果领导要每个员工的工作都要验收 check，那在未完成的员工那里，只能阻塞等待，等待他完成之后，再去 check 下一位员工的任务，造成性能问题。

那如何解决这个问题呢？

1、select

领导找个 Team Leader（后文简称 TL），负责代自己 check 每位员工的开发任务。

TL 的做法是：遍历问各个员工“完成了么？”，完成的待 CR check 无误后合并到 Git 分支，对于其他未完成的，休息一会儿后再去遍历....

这样存在什么问题呢？

• 这个 TL 存在能力短板问题，最多只能管理 1024 个员工
• 很多员工的任务没有完成，而且短时间内也完不成的话，TL 还是会不停的去遍历问询，影响效率。

select 函数：

int select(int maxfdp1,fd_set *readset,fd_set *writeset,fd_set *exceptset,const struct timeval *timeout);

select 函数监视的文件描述符分 3 类，分别是 writefds、readfds、和 exceptfds。调用后 select 函数会阻塞，直到有描述符就绪（有数据可读、可写、或者有 except），或者超时（timeout 指定等待时间，如果立即返回设为 null 即可），函数返回。当 select 函数返回后，可以通过遍历 fdset，来找到就绪的描述符。

select 具有良好的跨平台支持，其缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在 Linux 上一般为 1024。

2、poll

换一个能力更强的 New Team Leader（后文简称 NTL），可以管理更多的员工，这个 NTL 可以理解为 poll。

poll 函数：

intpoll(structpollfd*fds, nfds_t nfds,int timeout);
typedef struct pollfd{ 
int fd; // 需要被检测或选择的文件描述符 
short events; // 对文件描述符fd上感兴趣的事件 
short revents; // 文件描述符fd上当前实际发生的事件
} pollfd_t;

poll 改变了文件描述符集合的描述方式，使用了 pollfd 结构而不是 select 的 fd_set 结构，使得 poll 支持的文件描述符集合限制远大于 select 的 1024。

3、epoll

在上一步 poll 方式的 NTL 基础上，改进一下 NTL 的办事方法：遍历一次所有员工，如果任务没有完成，告诉员工待完成之后，其应该做 xx 操作（制定一些列的流程规范）。这样 NTL 只需要定期 check 指定的关键节点就好了。这就是 epoll。

Linux 中提供的 epoll 相关函数如下：

intepoll_create(int size);intepoll_ctl(int epfd,int op,int fd,struct epoll_event *event);intepoll_wait(int epfd,struct epoll_event * events,int maxevents,int timeout);

epoll 是 Linux 内核为处理大批量文件描述符而作了改进的 poll，是 Linux 下多路复用 IO 接口 select/poll 的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统 CPU 利用率。

4、小结

• select 就是轮询，在 Linux 上限制个数一般为 1024 个
• poll 解决了 select 的个数限制，但是依然是轮询
• epoll 解决了个数的限制，同时解决了轮询的方式

IO 多路复用在 Redis 中的应用

Redis 服务器是一个事件驱动程序， 服务器处理的事件分为时间事件和文件事件两类。

• 文件事件：Redis 主进程中，主要处理客户端的连接请求与相应。
• 时间事件：fork 出的子进程中，处理如 AOF 持久化任务等。

文件事件是对套接字操作的抽象，每当一个套接字准备好执行连接应答、写入、读取、关闭等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现。

IO 多路复用程序负责监听多个套接字并向文件事件分派器传送那些产生了事件的套接字。文件事件分派器接收 IO 多路复用程序传来的套接字，并根据套接字产生的事件的类型，调用相应的事件处理器。示例如图所示：

img

Redis 的 IO 多路复用程序的所有功能都是通过包装常见的 select、poll、evport 和 kqueue 这些 IO 多路复用函数库来实现的，每个 IO 多路复用函数库在 Redis 源码中都有对应的一个单独的文件。

Redis 为每个 IO 多路复用函数库都实现了相同的 API，所以 IO 多路复用程序的底层实现是可以互换的。如图：

img

Redis 把所有连接与读写事件、还有我们没提到的时间事件一起集中管理，并对底层 IO 多路复用机制进行了封装，最终实现了单进程能够处理多个连接以及读写事件。这就是 IO 多路复用在 redis 中的应用。

Redis6.0 之前为什么不使用多线程？

虽然说 Redis 是单线程模型，但是，实际上，Redis 在 4.0 之后的版本中就已经加入了对多线程的支持

不过，Redis 4.0 增加的多线程主要是针对一些大键值对的删除操作的命令，使用这些命令就会使用主处理之外的其他线程来“异步处理”。

大体上来说，Redis 6.0 之前主要还是单线程处理。

那，Redis6.0 之前为什么不使用多线程？

我觉得主要原因有下面 3 个：

1. 单线程编程容易并且更容易维护；
2. Redis 的性能瓶颈不在 CPU ，主要在内存和网络；
3. 多线程就会存在死锁、线程上下文切换等问题，甚至会影响性能。

Redis6.0 之后为何引入了多线程？

Redis6.0 引入多线程主要是为了提高网络 IO 读写性能，因为这个算是 Redis 中的一个性能瓶颈（Redis 的瓶颈主要受限于内存和网络）。

虽然，Redis6.0 引入了多线程，但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了，执行命令仍然是单线程顺序执行。

Redis 是如何判断数据是否过期的呢？

Redis 通过一个叫做过期字典（可以看作是 hash 表）来保存数据过期的时间。过期字典的键指向 Redis 数据库中的某个 key(键)，过期字典的值是一个 long long 类型的整数，这个整数保存了 key 所指向的数据库键的过期时间（毫秒精度的 UNIX 时间戳）。

过期的数据的删除策略了解么？

如果假设你设置了一批 key 只能存活 1 分钟，那么 1 分钟后，Redis 是怎么对这批 key 进行删除的呢？

常用的过期数据的删除策略就两个：

1. 惰性删除 ：只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。

2. 定期删除 ： 每隔一段时间抽取一批 key 执行删除过期 key 操作。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。

   具体就是Redis每秒10次做的事情：

   1. 测试随机的20个keys进行相关过期检测。
   2. 删除所有已经过期的keys。
   3. 如果有多于25%的keys过期，重复步奏1.

定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，所以 Redis 采用的是 定期删除+惰性/懒汉式删除 。

但是，仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里，然后就 Out of memory 了。

怎么解决这个问题呢？答案就是：Redis 内存淘汰机制。

Redis 内存淘汰机制了解么？

Redis 提供 6 种数据淘汰策略：

1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0 版本后增加以下两种：

1. volatile-lfu（least frequently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰
2. allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key

redis持久化

redis持久化

怎么保证 Redis 挂掉之后再重启数据可以进行恢复？

将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据），或者是为了防止系统故障而将数据备份到一个远程位置。

Redis 支持持久化，而且支持两种不同的持久化操作。

redis持久化的几种方式？

RDB、AOF、混合持久化。

RDB

什么是 RDB 持久化？

通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。

RDB的优点？

rdb是一个紧凑的二进制文件，代表Redis在某个时间点上的数据快照。 适合于备份，全量复制的场景，对于灾难恢复非常有用。

Redis加载RDB恢复数据的速度远快于AOF方式。

RDB的缺点？

RDB没法做到实时的持久化。中途意外终止，会丢失一段时间内的数据。

RDB需要fork()创建子进程，属于重量级操作，可能导致Redis卡顿若干秒。

AOF

什么是AOF持久化？

AOF(append only file)为了解决rdb不能实时持久化的问题，aof来搞定。以独立的日志方式记录把每次命令记录到aof文件中。

可以通过 appendonly 参数开启：

appendonly yes

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入到内存缓存 server.aof_buf 中，然后再根据 appendfsync 配置来决定何时将其同步到硬盘中的 AOF 文件。

AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的，默认的文件名是 appendonly.aof。

在 Redis 的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：

appendfsync always    #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec  #每秒钟同步一次，显式地将多个写命令同步到硬盘
appendfsync no        #让操作系统决定何时进行同步

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec 选项 ，让 Redis 每秒同步一次 AOF 文件，Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

AOF工作流程？

1.所有写入命令追加到aof_buf缓冲区。

2.AOF缓冲区根据对应的策略向硬盘做同步操作。

3.随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

4.当redis服务器重启时，可以加载AOF文件进行数据恢复。

为什么AOF要先把命令追加到缓存区(aof_buf)中？

Redis使用单线程响应命令，如果每次写入文件命令都直接追加到硬盘，性能就会取决于硬盘的负载。如果使用缓冲区，redis提供多种缓冲区策略，在性能和安全性方面做出平衡。

AOF优点？

AOF提供了3种保存策略：每秒保存、跟系统策略、每次操作保存。

实时性比较高，一般来说会选 择每秒保存，因此意外发生时顶多失去一秒的数据。 文件追加写形式，所以文件很少有损坏问题，如最后意外发生少写数据，可通过redis-check-aof工 具修复。 AOF由于是文本形式，直接采用协议格式，避免二次处理开销，另外对于修改也比较灵活。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF缺点？

AOF文件要比RDB文件大。 AOF冷备没RDB迅速。 由于执行频率比较高，所以负载高时，性能没有RDB好。

AOF 重写了解吗？

AOF 重写可以产生一个新的 AOF 文件，这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。

AOF 重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。

在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。

混合持久化？优缺点？

一般来说我们的线上都会采取混合持久化。redis4.0以后添加了新的混合持久化方式。如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。

优点：

在快速加载的同时，避免了丢失过更多的数据。

缺点：

由于混合了两种格式，所以可读性差。 兼容性，需要4.0以后才支持。

Redis 事务？

Redis 可以通过 MULTI，EXEC，DISCARD 和 WATCH 等命令来实现事务(transaction)功能。

使用 MULTI 命令后可以输入多个命令。Redis 不会立即执行这些命令，而是将它们放到队列，当调用了 EXEC命令将执行所有命令。

这个过程是这样的：

1. 开始事务（MULTI）。
2. 命令入队(批量操作 Redis 的命令，先进先出（FIFO）的顺序执行)。
3. 执行事务(EXEC)。

你也可以通过 DISCARD 命令取消一个事务，它会清空事务队列中保存的所有命令。

WATCH 命令用于监听指定的键，当调用 EXEC 命令执行事务时，如果一个被 WATCH 命令监视的键被修改的话，整个事务都不会执行，直接返回失败。

Redis 事务支持原子性吗？

Redis 事务在运行错误的情况下，除了执行过程中出现错误的命令外，其他命令都能正常执行。并且，Redis 是不支持回滚（roll back）操作的。因此，Redis 事务其实是不满足原子性的（而且不满足持久性）。

你可以将 Redis 中的事务就理解为 ：Redis 事务提供了一种将多个命令请求打包的功能。然后，再按顺序执行打包的所有命令，并且不会被中途打断。

如何解决 Redis 事务的缺陷？

Redis 从 2.6 版本开始支持执行 Lua 脚本，它的功能和事务非常类似。我们可以利用 Lua 脚本来批量执行多条 Redis 命令，这些 Redis 命令会被提交到 Redis 服务器一次性执行完成，大幅减小了网络开销。

一段 Lua 脚本可以视作一条命令执行，一段 Lua 脚本执行过程中不会有其他脚本或 Redis 命令同时执行，保证了操作不会被其他指令插入或打扰。

如果 Lua 脚本运行时出错并中途结束，出错之后的命令是不会被执行的。并且，出错之前执行的命令是无法被撤销的。因此，严格来说，通过 Lua 脚本来批量执行 Redis 命令也是不满足原子性的。

redis bigkey？

redis处理大key

简单来说，如果一个 key 对应的 value 所占用的内存比较大，那这个 key 就可以看作是 bigkey。

具体多大才算大呢？有一个不是特别精确的参考标准：string 类型的 value 超过 10 kb，复合类型的 value 包含的元素超过 5000 个。

bigkey 有什么危害？

bigkey 是指键值占用内存空间非常大的 key。例如一个字符串 a 存储了 200M 的数据。

bigkey 的主要影响有：

网络阻塞；获取 bigkey 时，传输的数据量比较大，会增加带宽的压力。

超时阻塞；因为 bigkey 占用的空间比较大，所以操作起来效率会比较低，导致出现阻塞的可能性增加。

导致内存空间不平衡；一个 bigkey 存储数据量比较大，同一个 key 在同一个节点或服务器中存储，会造成一定影响。

大量 key 集中过期问题？

对于过期 key，Redis 采用的是 定期删除+惰性/懒汉式删除 策略。

定期删除执行过程中，如果突然遇到大量过期 key 的话，客户端请求必须等待定期清理过期 key 任务线程执行完成，因为这个这个定期任务线程是在 Redis 主线程中执行的。这就导致客户端请求没办法被及时处理，响应速度会比较慢。

如何解决呢？下面是两种常见的方法：

1. 给 key 设置随机过期时间。
2. 开启 lazy-free（惰性删除/延迟释放） 。lazy-free 特性是 Redis 4.0 开始引入的，指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。

什么是缓存穿透？

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。

举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。

有哪些解决办法？

最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。

1）缓存无效 key

如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间，这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。

2）布隆过滤器

布隆过滤器是一个非常神奇的数据结构，通过它我们判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法。

具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。

加入布隆过滤器之后的缓存处理流程图如下

但是，需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是： 布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

我们先来看一下，当一个元素加入布隆过滤器中的时候，会进行哪些操作：

1. 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
2. 根据得到的哈希值，在位数组中把对应下标的值置为 1。

我们再来看一下，当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：

1. 对给定元素再次进行相同的哈希计算；
2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

然后，一定会出现这样一种情况：不同的字符串可能哈希出来的位置相同。

什么是缓存雪崩？

缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。 这就好比雪崩一样，摧枯拉朽之势，数据库的压力可想而知，可能直接就被这么多请求弄宕机了。

举个例子：系统的缓存模块出了问题比如宕机导致不可用。造成系统的所有访问，都要走数据库。

还有一种缓存雪崩的场景是：有一些被大量访问数据（热点缓存）在某一时刻大面积失效，导致对应的请求直接落到了数据库上。 这样的情况，有下面几种解决办法：

举个例子 ：秒杀开始 12 个小时之前，我们统一存放了一批商品到 Redis 中，设置的缓存过期时间也是 12 个小时，那么秒杀开始的时候，这些秒杀的商品的访问直接就失效了。导致的情况就是，相应的请求直接就落到了数据库上，就像雪崩一样可怕。

有哪些解决办法？

针对 Redis 服务不可用的情况：

1. 采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。
2. 限流，避免同时处理大量的请求。

针对热点缓存失效的情况：

1. 设置不同的失效时间比如随机设置缓存的失效时间。
2. 缓存永不失效。

什么是缓存击穿?

如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是缓存击穿的问题。

图片

可以发现缓存击穿跟缓存雪崩很相似，你可以认为缓存击穿是缓存雪崩的一个子集。

应对缓存击穿可以采取前面说到两种方案：

• 设置热点数据永不过期：对于一些热点数据，可以考虑设置永不过期，或者采用懒加载的策略，在缓存失效时异步更新缓存数据，而不是立即删除数据。
• 使用互斥锁：在缓存失效时，只允许一个线程去查询数据库并更新缓存，其他线程需要等待这个线程完成后再获取数据。
• 预先加载：在系统启动时或者定时任务中预先加载热点数据到缓存中，避免在缓存失效时出现大量请求同时访问。
• 使用分布式缓存：采用分布式缓存集群，将热点数据均匀分布在不同节点上，减少单点压力。

3种常用的缓存读写策略？

• Cache Aside Pattern（旁路缓存模式）

  Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式，比较适合读请求比较多的场景。

  Cache Aside Pattern 中服务端需要同时维系 DB 和 cache，并且是以 DB 的结果为准。

  写 ：

  1.先更新 DB

  2.然后直接删除 cache 。

  读 :

  1.从 cache 中读取数据，读取到就直接返回

  2.cache中读取不到的话，就从 DB 中读取数据返回

  3.再把数据放到 cache 中。

  在写数据的过程中，可以先删除 cache ，后更新 DB 么？

  答案： 不行！因为这样可能会造成数据库（DB）和缓存（Cache）数据不一致的问题。

请求1先把cache中的A数据删除 -> 请求2从DB中读取数据->请求1再把DB中的A数据更新。

在写数据的过程中，先更新DB，后删除cache就没有问题了么？

答案： 可能会出现数据不一致性的问题，不过概率非常小，因为缓存的写入速度是比数据库的写入速度快很多！

Cache Aside Pattern 的缺陷。

缺陷1：首次请求数据一定不在 cache 的问题

解决办法：可以将热点数据可以提前放入cache 中。

缺陷2：写操作比较频繁的话导致cache中的数据会被频繁被删除，这样会影响缓存命中率 。

解决办法：

1.数据库和缓存数据强一致场景 ：更新DB的时候同样更新cache，不过我们需要加一个锁/分布式锁来保证更新cache的时候不存在线程安全问题。

2.可以短暂地允许数据库和缓存数据不一致的场景 ：更新DB的时候同样更新cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致的话影响也比较小。

• Read/Write Through Pattern（读写穿透）

  Read/Write Through Pattern 中服务端把 cache 视为主要数据存储，从中读取数据并将数据写入DB中。cache 服务负责将此数据读取和写入 DB，从而减轻了应用程序的职责。

  写（Write Through）：

  1.先查 cache，cache 中不存在，直接更新 DB。

  2.cache 中存在，则先更新 cache，然后 cache 服务自己更新 DB（同步更新 cache 和 DB）。

  读(Read Through)：

  1.从 cache 中读取数据，读取到就直接返回 。

  2.读取不到的话，先从 DB 加载，写入到 cache 后返回响应。

• Write Behind Pattern（异步缓存写入）

  Write Behind Pattern 和 Read/Write Through Pattern 很相似，两者都是由 cache 服务来负责 cache 和 DB 的读写。

  但是，两个又有很大的不同：Read/Write Through 是同步更新 cache 和 DB，而 Write Behind Caching 则是只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB。

redis内存碎片?

你可以将内存碎片简单地理解为那些不可用的空闲内存。

举个例子：操作系统为你分配了 32 字节的连续内存空间，而你存储数据实际只需要使用 24 字节内存空间，那这多余出来的 8 字节内存空间如果后续没办法再被分配存储其他数据的话，就可以被称为内存碎片。

为什么会有 Redis 内存碎片?

Redis 内存碎片产生比较常见的 2 个原因：

1、Redis 存储存储数据的时候向操作系统申请的内存空间可能会大于数据实际需要的存储空间。

**2、频繁修改 Redis 中的数据也会产生内存碎片。**当 Redis 中的某个数据删除时，Redis 通常不会轻易释放内存给操作系统。

怎么解决：

1. 重启Redis：一种简单粗暴的方法是通过重启Redis来清理内存碎片。重启后内存会被重新整理，碎片问题可能会得到缓解。
2. 使用内存碎片整理工具：Redis 4.0 版本引入了 MEMORY PURGE 命令，可以用于整理内存碎片。该命令会尝试重新分配已使用内存的页面，以便更好地利用内存空间。
3. 使用 REWRITE 命令：REWRITE 命令可以对数据库进行重写，将现有的数据重新写入新的 RDB 文件中，再重新载入这个 RDB 文件，可以达到一定程度的内存整理效果。
4. 使用 MIGRATE 命令：MIGRATE 命令可以将 key 从一个 Redis 实例迁移到另一个实例，通过这种方式也可以间接实现内存整理。
5. 避免频繁增删数据：尽量避免频繁对数据进行增删操作，可以减少内存碎片的产生。如果需要频繁更新数据，可以考虑使用 HASH 数据结构代替 STRING 数据结构，减少碎片化的可能性。
6. 使用合适的过期策略：设置合理的过期时间，及时删除不再需要的数据，释放被占用的内存空间，减少碎片。

Redis的有几种数据类型？

redis常见数据类型

基础：字符串（String）、哈希（hash)、列表（list)、集合(set)、有序集合(zset)。

还有HyperLogLog、流、地理坐标等

redis为什么快？

redis使用了单线程架构和I/O多路复用模型模型。

纯内存访问。

由于是单线程避免了线程上下文切换带来的资源消耗。

优秀的数据结构支持：Redis 内置了丰富的数据结构，如字符串、哈希、列表、集合、有序集合等，这些数据结构的实现经过优化，可以高效地满足各种数据操作需求。

redis默认分多少个数据库？

16

什么是缓存预热？

就是系统上线后，提前将相关数据加载到缓存系统，避免用户先查库，然后在缓存。

Redis 的同步机制了解是什么？

Redis 支持主从同步、从从同步。如果是第一次进行主从同步，主节点需要使用 bgsave 命令，再将后续修改操作记录到内存的缓冲区， RDB 文件全部同步到复制节点，复制节点接受完成后将 RDB 镜像记载到内存中。等加载完成后，复制节点通知主节点将复制期间修改的操作记录同步到复制节点，即可完成同步过程。

Redis Cluster槽范围？

0~16383

是否使用过Redis Cluster集群，集群的原理是什么？

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号 在 0~16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

Redis 集群架构模式有哪几种？

Redis 集群架构是支持单节点单机模式的，也支持一主多从的主从结构，还支持带有哨兵的集群部署模式。

说说 Redis 哈希槽的概念？

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

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

我们可以使用 keys 命令和 scan 命令，但是会发现使用 scan 更好。

1. 使用 keys 命令（不用，会阻塞！）

直接使用 keys 命令查询，但是如果是在生产环境下使用会出现一个问题，keys 命令是遍历查询的，查询的时间复杂度为 O(n)，数据量越大查询时间越长。

而且 Redis 是单线程，keys 指令会导 致线程阻塞一段时间，会导致线上 Redis 停顿一段时间，直到 keys 执行完毕才能恢复。这在生产 环境是不允许的。

除此之外，需要注意的是，这个命令没有分页功能，会一次性查询出所有符合条 件的 key 值，会发现查询结果非常大，输出的信息非常多。所以不推荐使用这个命令。

2. 使用 scan 命令

scan 指令可以无阻塞的提取出指定模式的 key 列表， 但 是会有一定的重复概率， 在客户端做一次去重就可以了， 但是整体所花费的时间 会比直接用 keys 指令长。

Redis 主从复制的核⼼原理

通过执⾏slaveof命令或设置slaveof选项，让⼀个服务器去复制另⼀个服务器的数据。主数据库可以进⾏读写操作，当写操作导致数据变化时会⾃动将数据同步给从数据库。⽽从数据库⼀般是只读的，并接 受主数据库同步过来的数据。⼀个主数据库可以拥有多个从数据库，⽽⼀个从数据库只能拥有⼀个主数 据库。

全量复制：

1. 主节点通过bgsave命令fork⼦进程进⾏RDB持久化，该过程是⾮常消耗CPU、内存(⻚表复制)、硬盘IO的

2. 主节点通过⽹络将RDB⽂件发送给从节点，对主从节点的带宽都会带来很⼤的消耗

3. 从节点清空⽼数据、载⼊新RDB⽂件的过程是阻塞的，⽆法响应客户端的命令；如果从节点执⾏ bgrewriteaof，也会带来额外的消耗

部分复制：

1. 复制偏移量：执⾏复制的双⽅，主从节点，分别会维护⼀个复制偏移量offset

2. 复制积压缓冲区：主节点内部维护了⼀个固定⻓度的、先进先出(FIFO)队列 作为复制积压缓冲区，当主从节点offset的差距过⼤超过缓冲区⻓度时，将⽆法执⾏部分复制，只能执⾏全量复制。

3. 服务器运⾏ID(runid)：每个Redis节点，都有其运⾏ID，运⾏ID由节点在启动时⾃动⽣成，主节点会将⾃⼰的运⾏ID发送给从节点，从节点会将主节点的运⾏ID存起来。 从节点Redis断开重连的时候，就是根据运⾏ID来判断同步的进度：

○ 如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使⽤部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况)；

○ 如果从节点保存的runid与主节点现在的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进⾏全量复制。

Redis阻塞

命令阻塞

使用不当的命令造成客户端阻塞：

• keys ：获取所有的 key 操作；
• Hgetall：返回哈希表中所有的字段和；
• smembers：返回集合中的所有成员；

这些命令时间复杂度是O(n)，有时候也会全表扫描，随着n的增大耗时也会越大从而导致客户端阻塞。

SAVE 阻塞

大家都知道 Redis 在进行 RDB 快照的时候，会调用系统函数 fork() ，创建一个子线程来完成临时文件的写入，而触发条件正是配置文件中的 save 配置。

当达到我们的配置时，就会触发 bgsave 命令创建快照，这种方式是不会阻塞主线程的，而手动执行 save 命令会在主线程中执行，阻塞主线程。

同步持久化

当 Redis 直接记录 AOF 日志时，如果有大量的写操作，并且配置为同步持久化

appendfsync always

即每次发生数据变更会被立即记录到磁盘，因为写磁盘比较耗时，性能较差，所以有时会阻塞主线程。

AOF 重写

1. fork 出一条子线程来将文件重写，在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子线程创建新 AOF 文件期间，记录服务器执行的所有写命令。
2. 当子线程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。
3. 最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。

阻塞就是出现在第2步的过程中，将缓冲区中新数据写到新文件的过程中会产生阻塞。

AOF 日志

AOF 的日志记录不像关系型数据库那样在执行命令之前记录日志（方便故障恢复），而是采用先执行命令后记录日志的方式。

原因就是 AOF 记录日志是不会对命令进行语法检查的，这样就能减少额外的检查开销，不会对当前命令的执行产生阻塞，但可能会给下一个操作带来阻塞风险。

这是因为 AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。

大 Key 问题

大 key 并不是指 key 的值很大，而是 key 对应的 value 很大。

大 key 造成的阻塞问题如下：

• 客户端超时阻塞：由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。
• 引发网络阻塞：每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。
• 阻塞工作线程：如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。

查找大 key

当我们在使用 Redis 自带的 --bigkeys 参数查找大 key 时，最好选择在从节点上执行该命令，因为主节点上执行时，会阻塞主节点。

• 我们还可以使用 SCAN 命令来查找大 key；

• 通过分析 RDB 文件来找出 big key，这种方案的前提是 Redis 采用的是 RDB 持久化。网上有现成的工具：

• • redis-rdb-tools：Python 语言写的用来分析 Redis 的 RDB 快照文件用的工具
  • rdb_bigkeys：Go 语言写的用来分析 Redis 的 RDB 快照文件用的工具，性能更好。

删除大 key

删除操作的本质是要释放键值对占用的内存空间。

释放内存只是第一步，为了更加高效地管理内存空间，在应用程序释放内存时，操作系统需要把释放掉的内存块插入一个空闲内存块的链表，以便后续进行管理和再分配。这个过程本身需要一定时间，而且会阻塞当前释放内存的应用程序。

所以，如果一下子释放了大量内存，空闲内存块链表操作时间就会增加，相应地就会造成 Redis 主线程的阻塞，如果主线程发生了阻塞，其他所有请求可能都会超时，超时越来越多，会造成 Redis 连接耗尽，产生各种异常。

删除大 key 时建议采用分批次删除和异步删除的方式进行。

清空数据库

清空数据库和上面 bigkey 删除也是同样道理，flushdb、flushall 也涉及到删除和释放所有的键值对，也是 Redis 的阻塞点。

集群扩容

Redis 集群可以进行节点的动态扩容缩容，这一过程目前还处于半自动状态，需要人工介入。

在扩缩容的时候，需要进行数据迁移。而 Redis 为了保证迁移的一致性，迁移所有操作都是同步操作。

执行迁移时，两端的 Redis 均会进入时长不等的阻塞状态，对于小Key，该时间可以忽略不计，但如果一旦 Key 的内存使用过大，严重的时候会触发集群内的故障转移，造成不必要的切换。

Redis分布式锁实现Redisson

redisson如何加锁并保证加锁的原子性？

1: 判断key是否存在

2: 不存在的话：

• 设置hash结构字段自增，表示重入的次数。
• 设置key的过期时间。

3: 存在的话：

• 通过hash结构判断是否是当前线程，是否话重入加锁。

<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
    return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
            "if (redis.call('exists', KEYS[1]) == 0) then " +
                    "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                    "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                    "return nil; " +
                    "end; " +
                    "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                    "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                    "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                    "return nil; " +
                    "end; " +
                    "return redis.call('pttl', KEYS[1]);",
            Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
}

通过tryLockInnerAsync方法的实现可以看出，最终加锁是通过lua脚本来实现加锁的，redis在执行lua脚本的时候是可以保证加锁的原子性的，所以Redisson实现加锁的原子性是依赖lua脚本来实现的。

为什么需要设置加锁key的过期时间

为了避免死锁。

redisson提供了看门狗的逻辑，如果不设置过期时间的话，redisson会把key的过期时间设置为30s，然后定时任务轮训去续期key。

这会导致一个问题，只要客户端不宕机或者释放key的话，key会一直存在，导致死锁。

通过上面可以看到，如果不设置过期时间的话，会通过scheduleExpirationRenewal进行续约，也就是看门狗的逻辑。

如何实现可重入加锁

通过上述hash结构，维护一个计数器即可。

<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
    return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
            "if (redis.call('exists', KEYS[1]) == 0) then " +
                    "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                    "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                    "return nil; " +
                    "end; " +
                    "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                    "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                    "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                    "return nil; " +
                    "end; " +
                    "return redis.call('pttl', KEYS[1]);",
            Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
}

如何主动释放锁和避免其它线程释放了自己加的锁

unLock方法。

可以看到，他会判断hash结构中，锁是否由当前线程持有，然后判断重入次数，次数为0的时候释放掉锁。

protected RFuture<Boolean> unlockInnerAsync(long threadId) {
    return evalWriteAsync(getRawName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
            "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
                    "return nil;" +
                    "end; " +
                    "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
                    "if (counter > 0) then " +
                    "redis.call('pexpire', KEYS[1], ARGV[2]); " +
                    "return 0; " +
                    "else " +
                    "redis.call('del', KEYS[1]); " +
                    "redis.call('publish', KEYS[2], ARGV[1]); " +
                    "return 1; " +
                    "end; " +
                    "return nil;",
            Arrays.asList(getRawName(), getChannelName()), LockPubSub.UNLOCK_MESSAGE, internalLockLeaseTime, getLockName(threadId));
}

如何实现超时自动释放锁

综上，设置锁的过期时间，redisson就不会采用看门狗的方式续期，key到期自动释放了。

如何实现不同线程加锁的互斥

lua脚本的原子性保证了多个线程只会加锁成功一次，同时存了线程id信息，保证线程间加锁

互斥。

加锁失败之后如何实现阻塞等待加锁

执行死循环（自旋）的方式来不停地通过tryAcquire方法来尝试加锁，直到加锁成功之后才会跳出死循环，如果一直没有成功加锁，那么就会一直旋转下去，所谓的阻塞，实际上就是自旋加锁的方式。

但是这种阻塞可能会产生问题，因为如果其它线程释放锁失败，那么这个阻塞加锁的线程会一直阻塞加锁，这肯定会出问题的。所以有没有能够可以指定阻塞的时间，如果超过一定时间还未加锁成功的话，那么就放弃加锁的方法。即推荐使用tryLock。

private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
        long threadId = Thread.currentThread().getId();
        Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
        // lock acquired
        if (ttl == null) {
            return;
        }

        CompletableFuture<RedissonLockEntry> future = subscribe(threadId);
        RedissonLockEntry entry;
        if (interruptibly) {
            entry = commandExecutor.getInterrupted(future);
        } else {
            entry = commandExecutor.get(future);
        }

        try {
            while (true) {
                ttl = tryAcquire(-1, leaseTime, unit, threadId);
                // lock acquired
                if (ttl == null) {
                    break;
                }

                // waiting for message
                if (ttl >= 0) {
                    try {
                        entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                    } catch (InterruptedException e) {
                        if (interruptibly) {
                            throw e;
                        }
                        entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                    }
                } else {
                    if (interruptibly) {
                        entry.getLatch().acquire();
                    } else {
                        entry.getLatch().acquireUninterruptibly();
                    }
                }
            }
        } finally {
            unsubscribe(entry, threadId);
        }
//        get(lockAsync(leaseTime, unit));
    }

如何实现阻塞等待一定时间还未加锁成功就放弃加

tryLock方法。

如何实现公平锁

先到先得。

线程来加锁的时候，如果加锁失败了，那么会将线程扔到一个集合中，这样就按照加锁的顺序给线程排队，set集合的头部的线程就代表了接下来能够加锁成功的线程。

当有线程释放了锁之后，其它加锁失败的线程就会来继续加锁，加锁之前会先判断一下set集合的头部的线程跟当前要加锁的线程是不是同一个，如果是的话，那就加锁成功，如果不是的话，那么就加锁失败，这样就实现了加锁的顺序性。

"while true do " +
    "local firstThreadId2 = redis.call('lindex', KEYS[2], 0);" +
    "if firstThreadId2 == false then " +
        "break;" +
    "end;" +
    "local timeout = tonumber(redis.call('zscore', KEYS[3], firstThreadId2));" +
    "if timeout <= tonumber(ARGV[3]) then " +
        // remove the item from the queue and timeout set
        // NOTE we do not alter any other timeout
        "redis.call('zrem', KEYS[3], firstThreadId2);" +
        "redis.call('lpop', KEYS[2]);" +
    "else " +
        "break;" +
    "end;" +
"end;" +

"if (redis.call('exists', KEYS[1]) == 0) " +
    "and ((redis.call('exists', KEYS[2]) == 0) " +
        "or (redis.call('lindex', KEYS[2], 0) == ARGV[2])) then " +
    "redis.call('lpop', KEYS[2]);" +
    "redis.call('zrem', KEYS[3], ARGV[2]);" +

    // decrease timeouts for all waiting in the queue
    "local keys = redis.call('zrange', KEYS[3], 0, -1);" +
    "for i = 1, #keys, 1 do " +
        "redis.call('zincrby', KEYS[3], -tonumber(ARGV[4]), keys[i]);" +
    "end;" +

    "redis.call('hset', KEYS[1], ARGV[2], 1);" +
    "redis.call('pexpire', KEYS[1], ARGV[1]);" +
    "return nil;" +
"end;" +
"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
    "redis.call('hincrby', KEYS[1], ARGV[2], 1);" +
    "redis.call('pexpire', KEYS[1], ARGV[1]);" +
    "return nil;" +
"end;" +
"return 1;",

如何实现读写锁

Redisson通过RedissonReadWriteLock类来实现读写锁的功能，通过这个类可以获取到读锁或者写锁，所以真正的加锁的逻辑是由读锁和写锁实现的。

在读写锁的实现中，会往hash数据结构中多维护一个mode的字段，来表示当前加锁的模式。

所以能够实现读写锁，最主要是因为维护了一个加锁模式的字段mode，这样有线程来加锁的时候，就能根据当前加锁的模式结合读写的特性来判断要不要让当前来加锁的线程加锁成功。

如果没有加锁，那么不论是读锁还是写锁都能加成功，成功之后根据锁的类型维护mode字段。 如果模式是读锁，那么加锁线程是来加读锁的，就让它加锁成功。 如果模式是读锁，那么加锁线程是来加写锁的，就让它加锁失败。 如果模式是写锁，那么加锁线程是来加写锁的，就让它加锁失败（加锁线程自己除外）。 如果模式是写锁，那么加锁线程是来加读锁的，就让它加锁失败（加锁线程自己除外）。

如何实现批量加锁(联锁)

批量加锁的意思就是同时加几个锁，只有这些锁都算加成功了，才是真正的加锁成功。

redisson遍历这些锁进行加锁。

红锁为了解决什么问题

集群情况下，那就是客户端对原先的主节点加锁，成功之后还没有来得及同步给从节点，主节点宕机了，从节点变成了主节点，此时从节点是没有加锁信息的，如果有其它的客户端来加锁，是能够加锁成功的。

红锁算法的基本思想如下：

1. 获取当前时间戳、唯一标识符和锁的过期时间。
2. 尝试在多个独立的Redis实例（节点）上获取锁，每个实例对应一个资源。
3. 如果在大多数实例上成功获取到锁，并且总共花费的时间没有超过锁的过期时间，则认为获取锁成功。
4. 如果获取锁成功，执行相关业务逻辑；否则，释放已获取的锁。