2021最新Java面经整理 | 中间件篇（一）Redis

傷城~ 2022-12-19 13:19 181阅读 0赞

**目录**

一、Redis简介

二、五种数据类型

三、持久化（重点）

1、RDB

2、AOF

四、三种过期策略

1、定时过期

2、惰性过期

3、定期过期

4、key的过期时间和永久有效分别怎么设置

5、通过expire来设置key 的过期时间，那么对过期的数据怎么处理呢?

五、六种淘汰策略

六、事务

1、Redis事务的三个阶段

2、Redis事务和数据库ACID事务的区别

七、线程模型：单进程单线程（重点）

1、Redis线程模型（重点）

2、线程模型的组成

3、线程模型的流程及原理

4、Redis是单线程的，为什么这么快？

八、内存模型

1、Redis的内存统计

2、Redis的内存划分

3、优化内存占用

九、集群方案（重点）

1、主从模式

2、哨兵模式

3、集群模式（重点）

4、其他相关

5、分区

6、集群分片模式

十、什么是哈希槽？什么是一致性哈希？（重点）

1、哈希槽

2、一致性哈希

十一、分布式相关

1、分布式锁

2、分布式缓存

十二、其他问题

--------------------

## 一、Redis简介 ##

Redis(Remote Dictionary Server) 是一个使用 C 语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的键值对数据库。Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

## 二、五种数据类型 ##

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。各个数据类型应用场景：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70][]

## 三、持久化（重点） ##

Redis有两种持久化机制RDB（默认）和AOF。

### 1、RDB ###

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。RDB是Redis默认的持久化方式，会在对应的目录下生产一个dump.rdb文件，重启会通过加载dump.rdb文件恢复数据。

![201904281740196.jpg][]

**优点：**

*  只有一个文件dump.rdb，方便持久化；
 *  容灾性好，一个文件可以保存到安全的磁盘；
 *  性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化（使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能) ；
 *  如果数据集偏大，RDB的启动效率会比AOF更高。

**缺点：**

*  数据安全性低。（RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不是特别严格的时候）
 *  由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

### 2、AOF ###

AOF持久化是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，文件中可以看到详细的操作记录。她的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

![20190428174035957.jpg][]

**优点：**

*  数据安全性更高，AOF持久化可以配置appendfsync属性，其中always，每进行一次命令操作就记录到AOF文件中一次。
 *  通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof工具解决数据一致性问题。
 *  AOF机制的rewrite模式。(AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）)

**缺点：**

*  AOF文件比RDB文件大，且恢复速度慢；数据集大的时候，比rdb启动效率低。
 *  根据同步策略的不同，AOF在运行效率上往往会慢于RDB。

**持久化常用配置**

1）RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
    
    save 300 10            #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
    
    save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

2）AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always     #每次有数据修改发生时都会写入AOF文件。
    
    appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。
    
    appendfsync no          #从不同步。高效但是数据不会被持久化。

**RDB 优缺点**

>  *  RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，这种多个数据文件的方式，**非常适合做冷备**，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说 Amazon 的 S3 云服务上去，在国内可以是阿里云的 ODPS 分布式存储上，以预定好的备份策略来定期备份redis中的数据。
>  *  RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis **保持高性能**，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
>  *  相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
>  *  如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。一般来说，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。
>  *  RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

**AOF 优缺点**

>  *  AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次`fsync`操作，最多丢失 1 秒钟的数据。
>  *  AOF 日志文件以 `append-only` 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
>  *  AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 `rewrite` log 的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。
>  *  AOF 日志文件的命令通过非常可读的方式进行记录，这个特性非常**适合做灾难性的误删除的紧急恢复**。比如某人不小心用 `flushall` 命令清空了所有数据，只要这个时候后台 `rewrite` 还没有发生，那么就可以立即拷贝 AOF 文件，将最后一条 `flushall` 命令给删了，然后再将该 `AOF` 文件放回去，就可以通过恢复机制，自动恢复所有数据。
>  *  对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。
>  *  AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 `fsync` 一次日志文件，当然，每秒一次 `fsync`，性能也还是很高的。（如果实时写入，那么 QPS 会大降，redis 性能会大大降低）
>  *  以前 AOF 发生过 bug，就是通过 AOF 记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似 AOF 这种较为复杂的基于命令日志/merge/回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug，因此每次 rewrite 并不是基于旧的指令日志进行 merge 的，而是**基于当时内存中的数据进行指令的重新构建**，这样健壮性会好很多。

**RDB和AOF到底该如何选择**

>  *  不要仅仅使用 RDB，因为那样会导致你丢失很多数据；
>  *  也不要仅仅使用 AOF，因为那样有两个问题：第一，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug；
>  *  redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。

**Redis数据持久化之RDB-AOF混合方式**

redis4.0相对与3.X版本其中一个比较大的变化是4.0添加了新的混合持久化方式。前面已经详细介绍了AOF持久化以及RDB持久化，这里介绍的混合持久化就是同时结合RDB持久化以及AOF持久化混合写入AOF文件。这样做的好处是可以结合 rdb 和 aof 的优点, 快速加载同时避免丢失过多的数据，缺点是 aof 里面的 rdb 部分就是压缩格式不再是 aof 格式，可读性差。

4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，默认是禁用的，可通过config set修改。

**1）混合持久化过程**

了解了AOF持久化过程和RDB持久化过程以后，混合持久化过程就相对简单了。

混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，如下图：

![20201109054847407.png][]

**2）数据恢复**

当我们开启了混合持久化时，启动redis依然优先加载aof文件，aof文件加载可能有两种情况如下：

aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。

aof文件开头不是rdb的格式，直接以aof格式加载整个文件。

**3）混合持久化优缺点**

优点：

混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。

缺点：

兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差

## 四、三种过期策略 ##

Redis是key-value数据库，可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。过期策略通常有以下三种：

### 1、定时过期 ###

每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

### 2、惰性过期 ###

只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

### 3、定期过期 ###

每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

**Redis中同时使用了惰性过期和定期过期两种过期策略。**

### 4、key的过期时间和永久有效分别怎么设置 ###

EXPIRE和PERSIST命令。

### 5、通过expire来设置key 的过期时间，那么对过期的数据怎么处理呢? ###

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

1.  定时去清理过期的缓存；
2.  当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

## 五、六种淘汰策略 ##

Redis可以看作是一个内存数据库，可以通过Maxmemory指令配置Redis的数据集使用指定量的内存。设置maxmemory为0，则表示无限制。当内存使用达到maxmemory极限时，需要使用某种淘汰算法来决定清理掉哪些数据，以保证新数据的存入。

**常用的淘汰算法**：

*  FIFO：First In First Out，先进先出。判断被存储的时间，离目前最远的数据优先被淘汰。
 *  LRU：Least Recently Used，最近最少使用。判断最近被使用的时间，目前最远的数据优先被淘汰。
 *  LFU：Least Frequently Used，最不经常使用。在一段时间内，数据被使用次数最少的，优先被淘汰。

**Redis提供的淘汰策略**：

1.  noeviction：达到内存限额后返回错误，客户尝试可以导致更多内存使用的命令（大部分写命令，但DEL和一些例外）
2.  allkeys-lru：为了给新增加的数据腾出空间，驱逐键先试图移除一部分最近使用较少的（LRC）。
3.  volatile-lru：为了给新增加的数据腾出空间，驱逐键先试图移除一部分最近使用较少的（LRC），但只限于过期设置键。
4.  allkeys-random: 为了给新增加的数据腾出空间，驱逐任意键。
5.  volatile-random: 为了给新增加的数据腾出空间，驱逐任意键，但只限于有过期设置的驱逐键。
6.  volatile-ttl: 为了给新增加的数据腾出空间，驱逐键只有秘钥过期设置，并且首先尝试缩短存活时间的驱逐键。

了解了Redis的淘汰策略之后，在平时使用时应尽量主动设置/更新key的expire时间，主动剔除不活跃的旧数据，有助于提升查询性能。Redis过期数据淘汰是指将键值对都删除掉，请了解！

## 六、事务 ##

Redis 事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。Redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

### 1、Redis事务的三个阶段 ###

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的。Redis会将一个事务中的所有命令序列化，然后按顺序执行。

1.  事务开始 MULTI
2.  命令入队
3.  事务执行 EXEC

事务执行过程中，如果服务端收到有EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排队。

*  WATCH命令：是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。
 *  MULTI命令：用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
 *  EXEC命令：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil 。
 *  通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
 *  UNWATCH命令：可以取消watch对所有key的监控。

### 2、Redis事务和数据库ACID事务的区别 ###

1）**Redis 不支持回滚**，“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。**如果在一个事务中的命令出现错误，那么所有的命令都不会执行**；**如果在一个事务中出现运行错误，那么正确的命令会被执行。**

2）**Redis的事务总是具有ACID中的一致性和隔离性**，其他特性是不支持的。当服务器运行在*AOF*持久化模式下，并且appendfsync选项的值为always时，事务也具有耐久性。

3) Redis事务支持隔离性吗? Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，**Redis 的事务是总是带有隔离性的**。

4) Redis事务保证原子性吗，支持回滚吗? Redis中，单条命令是原子性执行的，但**事务不保证原子性，且没有回滚**。事务中任意命令执行失败，其余的命令仍会被执行。

### 七、线程模型：单进程单线程（重点） ###

### 1、Redis线程模型（重点） ###

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器（file event handler）。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

*  文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
 *  当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行， 但通过使用 I/O 多路复用程序来监听多个套接字， 文件事件处理器既实现了高性能的网络通信模型， 又可以很好地与 redis 服务器中其他同样以单线程方式运行的模块进行对接， 这保持了 Redis 内部单线程设计的简单性。

### 2、线程模型的组成 ###

*  Redis的线程模型组成，
 *  *多个socket　　*
 *  *IO多路复用程序*
 *  *scocket队列*
 *  *文件事件分配器*
 *  *事件处理器（连接应答处理器，命令请求处理器，命令回复处理器）　*

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 1][]

### 3、线程模型的流程及原理 ###

如下图客户端和redis的一次通信：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 2][]

> 1.  客户端socket01请求redis的server scoket建立连接，此时server socket生成AE\_READABLE事件，IO多路复用程序监听到server socket产生的事件，并将该事件压入队列。文件事件分派器从队列中拉取事件交给连接应答处理器，处理器同时生成一个与客户端通信的socket01,并将该scoket01的AE\_READABLE事件与命令请求处理器关联。
> 2.  此时客户端scoket01发送一个set key value的请求，redis的scoket01接收到AE\_READABLE事件，IO多路复用程序监听到事件，将事件压入队列，文件分派器取到事件，由于scoket01已经和命令请求处理器关联，所以命令请求处理器开始set key value,完毕后会将redis的scoket01的AE\_WAITABLE事件关联到命令回复处理器。
> 3.  如果此时客户端准备好接收返回结果了，向redis中的socket01发起询问请求，那么 redis 中的 socket01 会产生一个 `AE_WRITABLE` 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 `ok`，之后解除 socket01 的 `AE_WRITABLE` 事件与命令回复处理器的关联。
> 
> 这样便完成了redis的一次通信。

通过上述线程模型讲述，进一步了解redis中的事务，之前说事务和命令都是一组最小的执行单元，事务应该是该客户端将一组命令发送给redis,redis将一组命令压入队列，命令请求处理器一起处理，不会中断。

在redis实现分布式锁时说过，会发生并发问题，当客户端A执行1,2操作，客户端B执行3,4操作，并发执行时，在redis中的队列状况可能是  1,3,4,2  / 3,4,1,2 等多种情况，所以会引起并发问题。

### 4、**Redis是单线程的，为什么这么快？** ###

Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。采用单线程反而减少了多线程间线程的切换。

1.  完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
2.  数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
3.  采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4.  使用多路I/O复用模型，非阻塞IO；**这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程**
5.  使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

## 八、内存模型 ##

### 1、Redis的内存统计 ###

工欲善其事必先利其器，在说明Redis内存之前首先说明如何统计Redis使用内存的情况。在客户端通过redis-cli连接服务器后（后面如无特殊说明，客户端一律使用redis-cli），通过info命令可以查看内存使用情况：

info memory

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 3][]

>  *  **used\_memory****：**Redis分配器分配的内存总量（单位是字节），包括使用的虚拟内存（即swap）；Redis分配器后面会介绍。used\_memory\_human只是显示更友好。
>  *  **used\_memory\_rss****：**Redis进程占据操作系统的内存（单位是字节），与top及ps命令看到的值是一致的；除了分配器分配的内存之外，used\_memory\_rss还包括进程运行本身需要的内存、内存碎片等，但是不包括虚拟内存。
>  *  **mem\_fragmentation\_ratio****：**内存碎片比率，该值是used\_memory\_rss / used\_memory的比值。
>  *  **mem\_allocator****：**Redis使用的内存分配器，在编译时指定；可以是 libc 、jemalloc或者tcmalloc，默认是jemalloc；截图中使用的便是默认的jemalloc。

### 2、Redis的内存划分 ###

Redis作为内存数据库，在内存中存储的内容主要是数据（键值对）；通过前面的叙述可以知道，除了数据以外，Redis的其他部分也会占用内存。Redis的内存占用主要可以划分为以下几个部分：

**1、数据**

作为数据库，数据是最主要的部分；这部分占用的内存会统计在used\_memory中。

Redis使用键值对存储数据，其中的值（对象）包括5种类型，即字符串、哈希、列表、集合、有序集合。这5种类型是Redis对外提供的，实际上，在Redis内部，每种类型可能有2种或更多的内部编码实现；此外，Redis在存储对象时，并不是直接将数据扔进内存，而是会对对象进行各种包装：如redisObject、SDS等；这篇文章后面将重点介绍Redis中数据存储的细节。

**2、进程本身运行需要的内存**

Redis主进程本身运行肯定需要占用内存，如代码、常量池等等；这部分内存大约几兆，在大多数生产环境中与Redis数据占用的内存相比可以忽略。这部分内存不是由jemalloc分配，因此不会统计在used\_memory中。

补充说明：除了主进程外，Redis创建的子进程运行也会占用内存，如Redis执行AOF、RDB重写时创建的子进程。当然，这部分内存不属于Redis进程，也不会统计在used\_memory和used\_memory\_rss中。

**3、缓冲内存**

缓冲内存包括客户端缓冲区、复制积压缓冲区、AOF缓冲区等；其中，客户端缓冲存储客户端连接的输入输出缓冲；复制积压缓冲用于部分复制功能；AOF缓冲区用于在进行AOF重写时，保存最近的写入命令。在了解相应功能之前，不需要知道这些缓冲的细节；这部分内存由jemalloc分配，因此会统计在used\_memory中。

**4、内存碎片**

内存碎片是Redis在分配、回收物理内存过程中产生的。例如，如果对数据的更改频繁，而且数据之间的大小相差很大，可能导致redis释放的空间在物理内存中并没有释放，但redis又无法有效利用，这就形成了内存碎片。内存碎片不会统计在used\_memory中。

内存碎片的产生与对数据进行的操作、数据的特点等都有关；此外，与使用的内存分配器也有关系：如果内存分配器设计合理，可以尽可能的减少内存碎片的产生。后面将要说到的jemalloc便在控制内存碎片方面做的很好。如果Redis服务器中的内存碎片已经很大，可以通过安全重启的方式减小内存碎片：因为重启之后，Redis重新从备份文件中读取数据，在内存中进行重排，为每个数据重新选择合适的内存单元，减小内存碎片。

## 3、优化内存占用 ##

了解redis的内存模型，对优化redis内存占用有很大帮助。下面介绍几种优化场景。

**1）利用jemalloc特性进行优化**

由于jemalloc分配内存时数值是不连续的，因此key/value字符串变化一个字节，可能会引起占用内存很大的变动；在设计时可以利用这一点。

**2）使用整型/长整型**

如果是整型/长整型，Redis会使用int类型（8字节）存储来代替字符串，可以节省更多空间。因此在可以使用长整型/整型代替字符串的场景下，尽量使用长整型/整型。

**3）共享对象**

利用共享对象，可以减少对象的创建（同时减少了redisObject的创建），节省内存空间。

4）避免过度设计

然而需要注意的是，不论是哪种优化场景，都要考虑内存空间与设计复杂度的权衡；而设计复杂度会影响到代码的复杂度、可维护性。

详细参考: [https://www.cnblogs.com/kismetv/p/8654978.html][https_www.cnblogs.com_kismetv_p_8654978.html]

## 九、集群方案（重点） ##

Redis有三种集群模式，分别是：主从模式、哨兵模式和集群模式。其中集群模式最为常用。

### 1、主从模式 ###

主从模式是三种模式中最简单的，在主从复制中，数据库分为两类：主数据库(master)和从数据库(slave)。

其中主从复制有如下特点：

> \* 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
> 
> \* 从数据库一般都是只读的，并且接收主数据库同步过来的数据
> 
> \* 一个master可以拥有多个slave，但是一个slave只能对应一个master
> 
> \* slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来
> 
> \* master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务
> 
> \* master挂了以后，不会在slave节点中重新选一个master

工作机制：

> 当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。
> 
> 复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

### 2、哨兵模式 ###

主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。

sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况，特点如下：

> \* sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义
> 
> \* 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master
> 
> \* 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据
> 
> \* sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群
> 
> \* 多sentinel配置的时候，sentinel之间也会自动监控
> 
> \* 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心
> 
> \* 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis
> 
> \* sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了

工作机制：

> \* 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令 
> 
> \* 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。 
> 
> \* 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态
> 
> \* 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线 
> 
> \* 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令 
> 
> \* 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次 
> 
> \* 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除

当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。

### 3、集群模式（重点） ###

**1）简介**

cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。使用集群，只需要将redis配置文件中的`cluster-enable`配置打开即可。每个集群中至少需要三个主数据库才能正常运行，新增节点非常方便。

特点：

> \* 多个redis节点网络互联，数据共享
> 
> \* 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用
> 
> \* 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为  
> \* 支持在线增加、删除节点
> 
> \* 客户端可以连接任何一个主节点进行读写

Redis Cluster是一种服务端Sharding技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。

**2）方案说明**

1.  通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位
2.  每份数据分片会存储在多个互为主从的多节点上
3.  数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
4.  同一分片多个节点间的数据不保持一致性
5.  读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
6.  扩容时时需要需要把旧节点的数据迁移一部分到新节点

在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379。16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，`gossip` 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

**3）节点间的内部通信机制（重点）**

基本通信原理：集群元数据的维护有两种方式：集中式、Gossip 协议。**redis cluster 节点间采用 gossip 协议进行通信。**

**gossip协议：**

gossip 协议包含多种消息，包含 ping、pong、meet、fail等等。

meet：某个节点在内部发送了一个gossip meet 消息给新加入的节点，通知那个节点去加入我们的集群。然后新节点就会加入到集群的通信中。

redis-trib.rb add-node

*  ping：每个节点都会频繁给其它节点发送 ping，其中包含自己的状态还有自己维护的集群元数据，互相通过 ping 交换元数据。
 *  pong：ping 和 meet消息的返回响应，包含自己的状态和其它信息，也用于信息广播和更新。
 *  fail：某个节点判断另一个节点 fail 之后，就发送 fail 给其它节点，通知其它节点说这个节点已宕机。

**注意：**

> resp 是redis客户端和服务端之前使用的一种通讯协议；resp 的特点：实现简单、快速解析、可读性好。
> 
> **redis cluster 节点间采用 gossip 协议进行通信，重点是用来同步非强一致系统中各节点的状态。**

**4）分布式寻址算法**

*  hash 算法（大量缓存重建）
 *  一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
 *  redis cluster 的 hash slot 算法

**5）优点**

*  无中心架构，支持动态扩容，对业务透明
 *  具备Sentinel的监控和自动Failover(故障转移)能力
 *  客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
 *  高性能，客户端直连redis服务，免去了proxy代理的损耗

**6）缺点**

*  运维也很复杂，数据迁移需要人工干预
 *  只能使用0号数据库
 *  不支持批量操作(pipeline管道操作)
 *  分布式逻辑和存储模块耦合等

**7）gossip协议**

**gossip 是一种被用在分布式的非强一致性系统中用来同步各节点状态的方法**。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 4][]

因为在去中心化的集群环境里，各节点“实时”地洞察其他节点的重要信息是非常重要的。这消息包括：

- 节点的心跳

- 节点的状态（失效检查／live/dead）

- 节点当前负载

Gossip被设计成低 CPU开销和低网络带宽占用。因此非常适合大型的P2P　网络。Gossip周期地随机地选择一个节点并发起一轮Gossip会话，一个 Gossip包括３个消息。比如 NodeA向 Node B发起一个Gossip：

- A → B GossipRequestMessage

- B → A GossipAckMessage

- A → B GossipResponseMessage

并且，基于以上来来回回的消息传送来探测失效与否。

**8）resp协议**

**resp 是redis客户端和服务端之前使用的一种通讯协议；resp 的特点：实现简单、快速解析、可读性好**。它基于TCP的应用层协议 RESP(REdis Serialization Protocol)；RESP底层采用的是TCP的连接方式，通过tcp进行数据传输，然后根据解析规则解析相应信息。

Redis 的客户端和服务端之间采取了一种独立名为 RESP(REdis Serialization Protocol) 的协议，作者主要考虑了以下几个点：

*  容易实现
 *  解析快
 *  人类可读  
    RESP可以序列化不同的数据类型，如整数，字符串，数组。还有一种特定的错误类型。请求从客户端发送到Redis服务器，作为表示要执行的命令的参数的字符串数组。Redis使用特定于命令的数据类型进行回复。  
    RESP是二进制安全的，不需要处理从一个进程传输到另一个进程的批量数据，因为它使用前缀长度来传输批量数据。  
    注意：RESP 虽然是为 Redis 设计的，但是同样也可以用于其他 C/S 的软件。Redis Cluster使用不同的二进制协议(gossip)，以便在节点之间交换消息。

### 4、其他相关 ###

1）Redis集群的主从复制模型是怎样的？

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

2）说说Redis哈希槽的概念？

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

3）Redis集群会有写操作丢失吗？为什么？

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

4）Redis集群之间是如何复制的？

**异步复制**

5）Redis集群最大节点个数是多少？

16384个

### 5、分区 ###

1）Redis是单线程的，如何提高多核CPU的利用率？

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

2）为什么要做Redis分区？

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

3）你知道有哪些Redis分区实现方案？

>  *  客户端分区就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。大多数客户端已经实现了客户端分区。
>  *  代理分区 意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy
>  *  查询路由(Query routing) 的意思是客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点。Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接redirected到正确的redis节点。

4）Redis分区有什么缺点？

>  *  涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。
>  *  同时操作多个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）
>  *  当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件。
>  *  分区时动态扩容或缩容可能非常复杂。Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。然而，有一种预分片的技术也可以较好的解决这个问题。

### 6、集群分片模式 ###

如果 redis 只用复制功能做主从，那么当数据量巨大的情况下，单机情况下可能已经承受不下一份数据，更不用说是主从都要各自保存一份完整的数据。在这种情况下，数据分片是一个非常好的解决办法。redis 的 custer 正是用于解决该问题。它主要提供两个功能：

*  自动对数据分片，落到各个节点上
 *  即使集群部分节点失效或者连接不上，依然可以继续处理命令

对于第二点，它的功能有点类似于 sentienl 的故障转移，在这里不细说。这就涉及 redis 的槽位分片原理，一致性哈希和哈希槽的概念，具体参看下节。

## 十、什么是哈希槽？什么是一致性哈希？（重点） ##

哈希槽和一致性哈希都是针对**数据分片**来说的，其实就是一种数据分片的解决方案。Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念，Redis 集群有16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽。

### 1、哈希槽 ###

Redis集群（Cluster）并没有选用上面一致性哈希，而是采用了**哈希槽**（SLOT）的这种概念。**主要的原因就是，一致性哈希算法对于数据分布、节点位置的控制并不是很友好。**

1）**哈希槽**其实是两个概念，

*  第一个是**哈希算法**。Redis Cluster的hash算法不是简单的hash()，而是crc16算法，一种校验算法。
 *  另外一个就是**槽位**的概念，空间分配的规则。其实哈希槽的本质和一致性哈希算法非常相似，不同点就是对于哈希空间的定义。一致性哈希的空间是一个圆环，节点分布是基于圆环的，无法很好的控制数据分布。而Redis Cluster的槽位空间是自定义分配的，类似于Windows盘分区的概念。这种分区是可以自定义大小，自定义位置的。

2）Redis Cluster包含了16384个哈希槽，每个Key通过计算后都会落在具体一个槽位上，而这个槽位是属于哪个存储节点的，则由用户自己定义分配。例如机器硬盘小的，可以分配少一点槽位，硬盘大的可以分配多一点。如果节点硬盘都差不多则可以平均分配。所以哈希槽这种概念很好地解决了一致性哈希的弊端。

3）另外在**容错性**和**扩展性**上，表象与一致性哈希一样，都是对受影响的数据进行转移。而哈希槽本质上是对槽位的转移，把故障节点负责的槽位转移到其他正常的节点上。扩展节点也是一样，把其他节点上的槽位转移到新的节点上。

**但一定要注意的是，对于槽位的转移和分派，Redis集群是不会自动进行的，而是需要人工配置的。所以Redis集群的高可用是依赖于节点的主从复制与主从间的自动故障转移。**

![20201108191503599.png][]

### 2、一致性哈希 ###

在1997年，麻省理工学院的 Karger 等人提出了一致性哈希算法，为的就是解决分布式缓存的问题。在一致性哈希算法中，整个哈希空间是一个虚拟圆环。

![20201108192105697.png][]

**一致性哈希算法对于容错性和扩展性有非常好的支持。但一致性哈希算法也有一个严重的问题，就是数据倾斜**。如果在分片的集群中，节点太少，并且分布不均，一致性哈希算法就会出现部分节点数据太多，部分节点数据太少。也就是说无法控制节点存储数据的分配。如下图，大部分数据都在 A 上了，B 的数据比较少。

![20201108192237107.png][]

## 十一、分布式相关 ##

### 1、分布式锁 ###

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用SETNX命令实现分布式锁。

当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则 SETNX 不做任何动作。SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。返回值：设置成功，返回 1 。设置失败，返回 0 。

![2020110820032817.png][]

使用SETNX完成同步锁的流程及事项如下：

*  使用SETNX命令获取锁，若返回0（key已存在，锁已存在）则获取失败，反之获取成功
 *  为了防止获取锁后程序出现异常，导致其他线程/进程调用SETNX命令总是返回0而进入死锁状态，需要为该key设置一个“合理”的过期时间
 *  释放锁，使用DEL命令将锁数据删除

详情请查看，分布式锁篇：[https://blog.csdn.net/shipfei\_csdn/article/details/109502713][https_blog.csdn.net_shipfei_csdn_article_details_109502713]

### 2、分布式缓存 ###

缓存击穿、缓存穿透、缓存雪崩。请查看分布式缓存篇：[https://blog.csdn.net/shipfei\_csdn/article/details/109502592][https_blog.csdn.net_shipfei_csdn_article_details_109502592]

## 十二、其他问题 ##

**1、Redis常用管理命令**

> dbsize 返回当前数据库 key 的数量。  
> info 返回当前 redis 服务器状态和一些统计信息。  
> monitor 实时监听并返回redis服务器接收到的所有请求信息。  
> shutdown 把数据同步保存到磁盘上，并关闭redis服务。  
> config get parameter 获取一个 redis 配置参数信息。（个别参数可能无法获取）  
> config set parameter value 设置一个 redis 配置参数信息。（个别参数可能无法获取）  
> config resetstat 重置 info 命令的统计信息。（重置包括：keyspace 命中数、  
> keyspace 错误数、 处理命令数，接收连接数、过期 key 数）  
> debug object key 获取一个 key 的调试信息。  
> debug segfault 制造一次服务器当机。  
> flushdb 删除当前数据库中所有 key,此方法不会失败。小心慎用  
> flushall 删除全部数据库中所有 key，此方法不会失败。小心慎用

**2、Reids工具命令**

> redis-server：Redis 服务器的 daemon 启动程序  
> redis-cli：Redis 命令行操作工具。当然，你也可以用 telnet 根据其纯文本协议来操作  
> redis-benchmark：Redis 性能测试工具，测试 Redis 在你的系统及你的配置下的读写性能  
> $redis-benchmark -n 100000 –c 50  
> 模拟同时由 50 个客户端发送 100000 个 SETs/GETs 查询  
> redis-check-aof：更新日志检查  
> redis-check-dump：本地数据库检查

**3、判断key是否存在**

exists key +key名字

**4、删除key**

del key1 key2 ...

**5、SCAN系列命令注意事项**

*  SCAN的参数没有key，因为其迭代对象是DB内数据；
 *  返回值都是数组，第一个值都是下一次迭代游标；
 *  时间复杂度：每次请求都是O(1)，完成所有迭代需要O(N)，N是元素数量；
 *  可用版本：version >= 2.8.0；

**6、Redis 是一个基于内存的高性能key-value数据库。**

**7、Redis相比memcached有哪些优势：**

*  memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
 *  redis的速度比memcached快很多
 *  redis可以持久化其数据

**8、Redis是单线程**

redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销

**9、Reids常用5种数据类型**

*  string，list，set，sorted set，hash

**10、Reids6种淘汰策略**

*  **noeviction**: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。大多数写命令都会导致占用更多的内存(有极少数会例外。
 *  \*\*allkeys-lru:\*\*所有key通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。
 *  \*\*volatile-lru:\*\*只限于设置了 expire 的部分; 优先删除最近最少使用(less recently used ,LRU) 的 key。
 *  \*\*allkeys-random:\*\*所有key通用; 随机删除一部分 key。
 *  **volatile-random**: 只限于设置了 **expire** 的部分; 随机删除一部分 key。
 *  **volatile-ttl**: 只限于设置了 **expire** 的部分; 优先删除剩余时间(time to live,TTL) 短的key。

**11、Redis的并发竞争问题如何解决?**

单进程单线程模式，采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念，Redis对于多个客户端连接并不存在竞争，利用setnx实现锁。

**12、Redis是使用c语言开发的。**

**13、Redis前端启动命令**

./redis-server

**14、Reids支持的语言**

java、C、C\#、C++、php、Node.js、Go等。

**15、Redis 持久化方案**

RDB 和 AOF

**16、Redis 的主从复制**

持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能会导致数据丢失，如果通过redis的主从复制机制就可以避免这种单点故障，

**17、Redis是单线程的，但Redis为什么这么快？**

*  完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
 *  数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
 *  采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
 *  使用多路I/O复用模型，非阻塞IO；**这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程**
 *  使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

**18、为什么Redis是单线程的？**

Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）。

**19、Redis info查看命令：info memory**

**20、Redis内存模型**

*  **used\_memory**：Redis分配器分配的内存总量（单位是字节），包括使用的虚拟内存（即swap）；Redis分配器后面会介绍。used\_memory\_human只是显示更友好。
 *  **used\_memory\_rss**\*\*：\*\*Redis进程占据操作系统的内存（单位是字节），与top及ps命令看到的值是一致的；除了分配器分配的内存之外，used\_memory\_rss还包括进程运行本身需要的内存、内存碎片等，但是不包括虚拟内存。
 *  **mem\_fragmentation\_ratio**\*\*：\*\*内存碎片比率，该值是used\_memory\_rss / used\_memory的比值。
 *  **mem\_allocator**\*\*：\*\*Redis使用的内存分配器，在编译时指定；可以是 libc 、jemalloc或者tcmalloc，默认是jemalloc；截图中使用的便是默认的jemalloc。

**21、Redis内存划分**

**1）数据**

作为数据库，数据是最主要的部分；这部分占用的内存会统计在used\_memory中。

**2）进程本身运行需要的内存**

**3）缓冲内存**

**4）内存碎片**

**22、Redis对象有5种类型**

无论是哪种类型，Redis都不会直接存储，而是通过redisObject对象进行存储。

**23、Redis没有直接使用C字符串**

(即以空字符’\\0’结尾的字符数组)作为默认的字符串表示，而是使用了SDS。SDS是简单动态字符串(Simple Dynamic String)的缩写。

**24、Reidis的SDS在C字符串的基础上加入了free和len字段**

**25、Reids主从复制**

复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

**26、Redis哨兵**

在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。

**27、Reids持久化触发条件**

RDB持久化的触发分为手动触发和自动触发两种。

**28、Redis 开启AOF**

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置：appendonly yes

**29、AOF常用配置总结**

下面是AOF常用的配置项，以及默认值；前面介绍过的这里不再详细介绍。

*  appendonly no：是否开启AOF
 *  appendfilename "appendonly.aof"：AOF文件名
 *  dir ./：RDB文件和AOF文件所在目录
 *  appendfsync everysec：fsync持久化策略
 *  no-appendfsync-on-rewrite no：AOF重写期间是否禁止fsync；如果开启该选项，可以减轻文件重写时CPU和硬盘的负载（尤其是硬盘），但是可能会丢失AOF重写期间的数据；需要在负载和安全性之间进行平衡
 *  auto-aof-rewrite-percentage 100：文件重写触发条件之一
 *  auto-aof-rewrite-min-size 64mb：文件重写触发提交之一
 *  aof-load-truncated yes：如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件

**30、RDB和AOF的优缺点**

**RDB持久化**

优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。

缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

**AOF持久化**

与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。

**31、持久化策略选择**

（1）如果Redis中的数据完全丢弃也没有关系（如Redis完全用作DB层数据的cache），那么无论是单机，还是主从架构，都可以不进行任何持久化。

（2）在单机环境下（对于个人开发者，这种情况可能比较常见），如果可以接受十几分钟或更多的数据丢失，选择RDB对Redis的性能更加有利；如果只能接受秒级别的数据丢失，应该选择AOF。

（3）但在多数情况下，我们都会配置主从环境，slave的存在既可以实现数据的热备，也可以进行读写分离分担Redis读请求，以及在master宕掉后继续提供服务。

**32、redis缓存被击穿处理机制**

使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法

**33、Redis还提供的高级工具**

像慢查询分析、性能测试、Pipeline、事务、Lua自定义命令、Bitmaps、HyperLogLog、发布/订阅、Geo等个性化功能。

**34、为什么需要持久化？**

由于Redis是一种内存型数据库，即服务器在运行时，系统为其分配了一部分内存存储数据，一旦服务器挂了，或者突然宕机了，那么数据库里面的数据将会丢失，为了使服务器即使突然关机也能保存数据，必须通过持久化的方式将数据从内存保存到磁盘中。

**35.缓存和数据库间数据一致性问题**

分布式环境下（单机就不用说了）非常容易出现缓存和数据库间的数据一致性问题，针对这一点的话，只能说，如果你的项目对缓存的要求是强一致性的，那么请不要使用缓存。我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。合适的策略包括 合适的缓存更新策略，更新数据库后要及时更新缓存、缓存失败时增加重试机制，例如MQ模式的消息队列。

**36.布隆过滤器**

bloomfilter就类似于一个hash set，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。布隆过滤器的关键就在于hash算法和容器大小

**37.缓存雪崩问题**

存在同一时间内大量键过期（失效），接着来的一大波请求瞬间都落在了数据库中导致连接异常。解决方案：

*  也是像解决缓存穿透一样加锁排队。
 *  建立备份缓存，缓存A和缓存B，A设置超时时间，B不设值超时时间，先从A读缓存，A没有读B，并且更新A缓存和B缓存;

**38.缓存并发问题**

这里的并发指的是多个redis的client同时set key引起的并发问题。比较有效的解决方案就是把redis.set操作放在队列中使其串行化，必须的一个一个执行，具体的代码就不上了，当然加锁也是可以的，至于为什么不用redis中的事务，留给各位看官自己思考探究。

**39.Redis分布式**

redis支持主从的模式。原则：Master会将数据同步到slave，而slave不会将数据同步到master。Slave启动时会连接master来同步数据。

这是一个典型的分布式读写分离模型。我们可以利用master来插入数据，slave提供检索服务。这样可以有效减少单个机器的并发访问数量

**40.读写分离模型**

通过增加Slave DB的数量，读的性能可以线性增长。为了避免Master DB的单点故障，集群一般都会采用两台Master DB做双机热备，所以整个集群的读和写的可用性都非常高。读写分离架构的缺陷在于，不管是Master还是Slave，每个节点都必须保存完整的数据，如果在数据量很大的情况下，集群的扩展能力还是受限于单个节点的存储能力，而且对于Write-intensive类型的应用，读写分离架构并不适合。

**41.数据分片模型**

为了解决读写分离模型的缺陷，可以将数据分片模型应用进来。

可以将每个节点看成都是独立的master，然后通过业务实现数据分片。

结合上面两种模型，可以将每个master设计成由一个master和多个slave组成的模型。

**42. redis常见性能问题和解决方案：**

Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内

尽量避免在压力很大的主库上增加从库

**43.redis通讯协议**

RESP 是redis客户端和服务端之前使用的一种通讯协议；RESP 的特点：实现简单、快速解析、可读性好。

**44.Redis分布式锁实现**

先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。\*\*如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？\*\*set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！

**45.Redis做异步队列**

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。缺点：在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。\*\*能不能生产一次消费多次呢？\*\*使用pub/sub主题订阅者模式，可以实现1:N的消息队列。

**46.Redis中海量数据的正确操作方式**

利用SCAN系列命令（SCAN、SSCAN、HSCAN、ZSCAN）完成数据迭代。

**48.Redis 管道 Pipeline**

在某些场景下我们在**一次操作中可能需要执行多个命令**，而如果我们只是一个命令一个命令去执行则会浪费很多网络消耗时间，如果将命令一次性传输到 `Redis`中去再执行，则会减少很多开销时间。但是需要注意的是 `pipeline`中的命令并不是原子性执行的，也就是说管道中的命令到达 `Redis`服务器的时候可能会被其他的命令穿插

**49.事务不支持回滚**

**51.多节点 Redis 分布式锁：Redlock 算法**

获取当前时间（start）。

依次向 N 个 `Redis`节点请求锁。请求锁的方式与从单节点 `Redis`获取锁的方式一致。为了保证在某个 `Redis`节点不可用时该算法能够继续运行，获取锁的操作都需要设置超时时间，需要保证该超时时间远小于锁的有效时间。这样才能保证客户端在向某个 `Redis`节点获取锁失败之后，可以立刻尝试下一个节点。

计算获取锁的过程总共消耗多长时间（consumeTime = end - start）。如果客户端从大多数 `Redis`节点（>= N/2 + 1) 成功获取锁，并且获取锁总时长没有超过锁的有效时间，这种情况下，客户端会认为获取锁成功，否则，获取锁失败。

如果最终获取锁成功，锁的有效时间应该重新设置为锁最初的有效时间减去 `consumeTime`。

如果最终获取锁失败，客户端应该立刻向所有 `Redis`节点发起释放锁的请求。

**52.Redis 中设置过期时间主要通过以下四种方式**

*  expire key seconds：设置 key 在 n 秒后过期；
 *  pexpire key milliseconds：设置 key 在 n 毫秒后过期；
 *  expireat key timestamp：设置 key 在某个时间戳（精确到秒）之后过期；
 *  pexpireat key millisecondsTimestamp：设置 key 在某个时间戳（精确到毫秒）之后过期；

**53.Reids三种不同删除策略**

**定时删除**：在设置键的过期时间的同时，创建一个定时任务，当键达到过期时间时，立即执行对键的删除操作

**惰性删除**：放任键过期不管，但在每次从键空间获取键时，都检查取得的键是否过期，如果过期的话，就删除该键，如果没有过期，就返回该键

**定期删除**：每隔一点时间，程序就对数据库进行一次检查，删除里面的过期键，至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。

**54.定时删除**

*  \*\*优点：\*\*对内存友好，定时删除策略可以保证过期键会尽可能快地被删除，并释放国期间所占用的内存
 *  \*\*缺点：\*\*对cpu时间不友好，在过期键比较多时，删除任务会占用很大一部分cpu时间，在内存不紧张但cpu时间紧张的情况下，将cpu时间用在删除和当前任务无关的过期键上，影响服务器的响应时间和吞吐量

**55.定期删除**

由于定时删除会占用太多cpu时间，影响服务器的响应时间和吞吐量以及惰性删除浪费太多内存，有内存泄露的危险，所以出现一种整合和折中这两种策略的定期删除策略。

1.  定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。
2.  定时删除策略有效地减少了因为过期键带来的内存浪费。

**56.惰性删除**

*  \*\*优点：\*\*对cpu时间友好，在每次从键空间获取键时进行过期键检查并是否删除，删除目标也仅限当前处理的键，这个策略不会在其他无关的删除任务上花费任何cpu时间。
 *  \*\*缺点：\*\*对内存不友好，过期键过期也可能不会被删除，导致所占的内存也不会释放。甚至可能会出现内存泄露的现象，当存在很多过期键，而这些过期键又没有被访问到，这会可能导致它们会一直保存在内存中，造成内存泄露。

**57.Reids 管理工具：Redis Manager 2.0**

**58.Redis常见的几种缓存策略**

*  Cache-Aside
 *  Read-Through
 *  Write-Through
 *  Write-Behind

**59.Redis Module 实现布隆过滤器**

Redis module 是Redis 4.0 以后支持的新的特性，这里很多国外牛逼的大学和机构提供了很多牛逼的Module 只要编译引入到Redis 中就能轻松的实现我们某些需求的功能。在Redis 官方Module 中有一些我们常见的一些模块，我们在这里就做一个简单的使用。

*  neural-redis 主要是神经网络的机器学，集成到redis 可以做一些机器训练感兴趣的可以尝试
 *  RedisSearch 主要支持一些富文本的的搜索
 *  RedisBloom 支持分布式环境下的Bloom 过滤器

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70]: /images/20221120/67ed8543c0b349a59b232771f3d35e37.png
[201904281740196.jpg]: https://img-blog.csdnimg.cn/201904281740196.jpg
[20190428174035957.jpg]: https://img-blog.csdnimg.cn/20190428174035957.jpg
[20201109054847407.png]: https://img-blog.csdnimg.cn/20201109054847407.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20201108183651767.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/2020110818381042.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20201108185443842.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[https_www.cnblogs.com_kismetv_p_8654978.html]: https://www.cnblogs.com/kismetv/p/8654978.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20201109054218403.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[20201108191503599.png]: https://img-blog.csdnimg.cn/20201108191503599.png
[20201108192105697.png]: https://img-blog.csdnimg.cn/20201108192105697.png
[20201108192237107.png]: https://img-blog.csdnimg.cn/20201108192237107.png
[2020110820032817.png]: https://img-blog.csdnimg.cn/2020110820032817.png
[https_blog.csdn.net_shipfei_csdn_article_details_109502713]: https://blog.csdn.net/shipfei_csdn/article/details/109502713
[https_blog.csdn.net_shipfei_csdn_article_details_109502592]: https://blog.csdn.net/shipfei_csdn/article/details/109502592