Redis高可用，Redis性能管理

一，Redis高可用，Redis性能管理

高可用性（High Availability，HA） 是指系统、服务或应用程序在较长时间内持续可用、无重大中断的能力。高可用性通常意味着即使在发生故障、灾难或维护的情况下，系统仍能保证一定的正常运行时间和服务质量，减少服务的宕机时间。Redis高可用，还需要考虑数据容量的扩展、数据安全不会丢失等。

Redis中，实现高可用的技术主要包括持久化、主从复制、哨兵和 Cluster集群，作用是：

（1）持久化

持久化是指将 Redis 中的数据存储到硬盘上，避免因系统或进程退出导致数据丢失。它通常不被视为高可用方案，因为它只是确保数据不丢失，但无法在故障情况下保持服务的可用性。

优点是简单易实现，确保数据不会因进程崩溃或系统重启而丢失。

缺点是并不能防止因硬件故障或其他问题引发的 Redis 服务不可用。

（2） 主从复制

主从复制是 Redis 的基础高可用功能，它通过将主节点的数据复制到一个或多个从节点上，实现数据的冗余备份。可以通过从节点分担读操作，从而实现读操作的负载均衡。

优点：提供了多机数据备份，并通过从节点分担读操作，提高读性能；可以手动进行故障转移。

缺点：无法自动恢复故障，尤其是主节点发生故障时需要手动干预；写操作无法负载均衡，因为所有写操作只能在主节点进行；受限于单个主节点，系统的总存储能力有限。

（3） 哨兵模式

Redis 哨兵（Sentinel）是在主从复制的基础上增加的一种监控机制，哨兵能够自动监控主从节点的状态，并在主节点故障时自动执行故障转移，将从节点提升为主节点，确保系统的高可用性。

优点:自动化故障恢复，无需人工干预；当主节点宕机时，能够自动将一个从节点提升为主节点并重新分配连接。

缺点: 写操作依然无法负载均衡；存储能力依然受限于单个主节点。

（4）Cluster 集群

Redis 集群是 Redis 提供的一种分布式方案，解决了单节点存储容量和写操作无法负载均衡的问题。它通过将数据分片存储在多个节点上，使得集群可以水平扩展，既支持读写操作的负载均衡，也能大幅提高存储能力。

优点 :支持写操作的负载均衡，解决了主从模式下写操作的单点瓶颈；通过数据分片，集群可以横向扩展，突破了单机的存储限制。

缺点：架构更加复杂，配置和运维难度增加；可能会遇到数据不一致或分片失败等问题，需要更细致的管理和监控。

二，Redis持久化

持久化的功能是为了解决Redis作为内存数据库时数据丢失的问题。因为Redis的数据存储在内存中，一旦服务器出现问题（比如断电或Redis崩溃），所有数据都会丢失。为了防止这种情况，Redis会定期把数据从内存保存到硬盘上，这样即使系统出现故障，数据也可以恢复。

当Redis重新启动时，它会读取硬盘上的持久化文件，把数据恢复到内存里。除此之外，你还可以把这些文件备份到远程服务器，以防止本地硬盘故障导致数据永久丢失。

RDB 和 AOF 是 Redis 提供的两种持久化方式

---

RDB 持久化

Redis 会定期将内存中的数据快照保存到磁盘上。这意味着在特定的时间间隔内，Redis 会将所有数据写入一个文件，从而生成一个数据快照。即使 Redis 崩溃或重启，系统也可以通过加载这些快照文件来恢复数据。

优点:生成的文件较小，适合用于备份，数据恢复较快。

缺点：由于是定期保存，如果系统突然崩溃，可能会丢失最近一次快照后写入的数据。

---

AOF 持久化（append only file）

AOF 持久化会记录 Redis 每次执行的写操作（比如插入、删除等），并将这些操作以追加的方式写入日志文件。类似于 MySQL 的 binlog 日志，AOF 能够逐条记录每个操作。

优点:数据恢复更加完整，因为每一次写操作都被记录；在崩溃时，丢失的数据量极少。

缺点:AOF 文件比 RDB 更大，恢复速度可能较慢，尤其是在大量操作时，日志文件可能变得很大。

1.RDB持久化

RDB 持久化就是 Redis 在指定时间间隔内，将内存中所有数据拍成快照，保存到硬盘上的一种方式。这些快照被存储为一个 .rdb 文件，Redis 重启时可以通过这个文件恢复数据。因为是以二进制格式压缩存储的，所以文件体积相对较小。

1.1触发条件

RDB 持久化有两种触发方式：手动触发和自动触发。

（1）手动触发

Redis 提供了两个命令用于手动生成 RDB 文件：

• save命令：save 会暂停 Redis 主进程，直到数据快照文件完全生成。这个过程中，Redis 无法处理任何其他请求，因此整个服务器会暂停服务。由于这一点，save 命令几乎不再使用。
• bgsave** 命令**：bgsave 会创建一个子进程来处理 RDB 文件的生成，而主进程继续正常处理客户端请求。虽然在创建子进程时会短暂阻塞一下，但相比 save 命令，bgsave 更加高效、对服务影响更小，所以它是生成 RDB 文件的主要方式。

（2）自动触发

Redis 也支持自动触发 RDB 持久化。常见的情况是在配置文件中使用 save m n 规则，这意味着当 Redis 在 m 秒内发生了 n 次数据更改时，会自动触发 bgsave 来保存快照文件。

例如：配置 save 60 10000，表示如果在 60 秒内有 10000 次数据变化，就自动执行 bgsave。

save 命令会导致 Redis 完全暂停服务，直到持久化完成，这在使用中会导致严重的服务不可用。因此，save 命令通常被淘汰不在使用

假设RDB三次周期性触发条件m,n都未满足时Redis崩溃了 ，会导致丢失数据

在Redis中，除了SAVE 和 BGSAVE 以外，还有一些其他情况会触发 BGSAVE 或 RDB 持久化操作。

主从复制：

当从节点执行全量复制时，主节点会自动触发 BGSAVE，以生成 RDB 文件并发送给从节点。这是为了同步数据到新加入的从节点，保证其数据一致性。

执行 SHUTDOWN 命令：

在执行 SHUTDOWN 命令时，Redis 会尝试执行一次 RDB 持久化操作（如果启用了 save 配置），保存当前的数据快照到磁盘上，然后再停止服务。这样可以避免数据在服务器关闭时丢失。

1.2 Redis 的 RDB 持久化配置

vim /etc/redis/6379.conf

在219行配置以下三个save条件满足任意一个时，都会引起bgsave的调用
save 900 1    #当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10   #当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 #当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave

在254行配置指定RDB文件名
dbfilename dump.rdb   #dump可以改名.rdb不能改

在264行配置指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379

在242行配置是否开启RDB文件压缩
rdbcompression yes

1.3 RDB执行流程

(1) 判断是否有其他持久化操作在执行

• Redis 父进程首先会检查当前是否已经有正在执行的 SAVE，或其他后台操作（例如 BGSAVE 或 BGREWRITEAOF）。
  • 如果检测到有一个子进程正在执行 BGSAVE 或 BGREWRITEAOF，那么新的 BGSAVE 命令会直接返回错误，避免两个并发的子进程同时执行大量的磁盘写操作，从而引发严重的性能问题。

(2) 父进程执行 fork 创建子进程

• 如果没有其他后台持久化操作在进行，父进程将调用 fork 系统调用来创建一个子进程。在 fork 过程中，父进程会阻塞，即暂停对来自客户端的其他命令的处理。
  • 由于 fork 需要复制当前的内存页，这个过程可能会消耗一定的时间，具体时间取决于 Redis 占用的内存大小。

(3) fork 完成后，BGSAVE 命令返回

• 当 fork 操作成功后，BGSAVE 命令立即返回，并显示 "Background saving started" 信息，表示后台保存操作已经启动。
  • 此时父进程不再阻塞，可以继续响应来自客户端的其他命令。

(4) 子进程生成 RDB 文件

• 子进程开始工作，它会基于父进程的内存快照创建一个临时的 RDB 文件。
  • 子进程会遍历父进程的内存数据结构，并将这些数据写入到 RDB 文件中。此过程不会影响父进程对内存的修改，因为 fork 的写时复制（copy-on-write）机制确保了父进程和子进程之间内存的隔离。

(5) 原子替换 RDB 文件

• 当子进程完成 RDB 文件的生成后，它会将生成的临时快照文件进行原子性替换，这意味着新的 RDB 文件会覆盖旧的文件，确保文件替换过程的完整性和一致性。

(6) 子进程向父进程发送完成信号

• 当子进程完成 BGSAVE 操作时，它会向父进程发送一个信号，告知持久化操作已完成。
  • 父进程接收到信号后，会更新相关的统计信息，例如最后一次成功保存的时间、保存操作的耗时等。

RDB流程图

1.4 启动时加载

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入 AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

2 . AOF持久化

RDB持久化是将进程数据写入文件，AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录； 当Redis重启时再次执行AOF文件中的命令来恢复数据。和RDB相比，AOF的实时性更好，已成为主流的持久化方案。

RDB 与 AOF 的对比

特性	RDB	AOF
数据丢失情况	丢失最后几分钟的数据（取决于快照频率）	最多丢失1秒的数据（视配置而定）
文件大小	文件较小，适合备份	文件较大，需要定期重写
性能	性能较好（适合大规模恢复）	性能稍差，特别是同步写入时
恢复速度	恢复速度快（从快照中恢复）	恢复速度慢（需要重放所有命令）
适用场景	适合数据备份、灾难恢复	适合数据丢失不能容忍的场景，保证数据安全性
文件可读性	二进制文件，不可读	文本文件，可读可编辑

2.1AOF持久化配置

vim /etc/redis/6379.conf

在700行配置修改，开启AOF
appendonly yes

在704行配置指定AOF文件名称
appendfilename "appendonly.aof"

在796行配置是否忽略最后一条可能存在问题的指令
aof-load-truncated yes

在730行配置
appendfsync everysec

2.2 执行流程

因为需要记录Redis的每条写命令，因此AOF没有触发

（1） 命令追加 (append)

在 Redis 执行写命令时，这些命令并不会直接写入硬盘，而是首先被追加到一个内存缓冲区 aof_buf 中。这种方式的好处是可以有效地减少对硬盘 I/O 的频繁访问，从而避免硬盘 I/O 成为系统瓶颈。

命令的格式： Redis 写入 AOF 文件中的命令是基于 Redis 命令请求协议格式，这是一种纯文本格式。纯文本格式的优点是兼容性好、可读性强，便于运维人员进行分析和修复。

在这个过程中，所有的客户端写命令都会被追加到 aof_buf 中。唯一的例外是 Redis 会自动插入 select 命令来指定数据库。例如，如果操作的是 Redis 的 0 号数据库，那么 Redis 会在 AOF 文件中自动插入一条 SELECT 0 命令，确保后续的命令操作是在正确的数据库上进行。

（2）文件写入 (write) 和文件同步 (sync)

写入和同步的过程是 AOF 持久化的核心步骤。在这一步中，缓冲区 aof_buf 中的数据被写入到 AOF 文件（即 appendonly.aof）中。Redis 提供了多种文件同步策略，来决定数据何时从内存同步到硬盘。

a. 写入 (write)：

写入是通过操作系统的 write 函数来实现的，但 write 函数只是将数据写入内存中的缓冲区，并不会立即写入到硬盘。因此，如果系统崩溃，缓冲区中的数据可能丢失。

b. 同步 (sync)：

为了确保数据安全性，操作系统提供了 fsync 和 fdatasync 函数，强制将内存缓冲区中的数据同步到硬盘。Redis 提供了三种不同的同步策略，可以通过配置 **appendfsync** 参数来选择：

• appendfsync always：每次有数据写入时，都会立即调用 fsync 同步文件。安全性最高，但性能最差，因为频繁调用 fsync 会带来高昂的 I/O 开销。
• appendfsync everysec：每秒调用一次 fsync 将数据同步到硬盘。这是一个折中的方案，性能和数据安全性都有不错的平衡。如果系统崩溃，最多会丢失 1 秒的数据。
• appendfsync no：由操作系统决定何时将数据同步到硬盘，Redis 不主动调用 fsync。这种方式性能最高，但如果系统崩溃，数据丢失的风险也最大。

通常，everysec 是比较推荐的设置，因为它在性能和数据安全性之间达到了较好的平衡。

2.3 文件重写 (rewrite)

随着 Redis 的运行，AOF 文件会不断变大，因为每次写入操作都会被记录下来。如果不加控制，文件会变得非常庞大，影响 Redis 的性能。为了防止 AOF 文件过大，Redis 提供了 AOF 重写 机制，定期对 AOF 文件进行重写（压缩），从而减少文件大小。

文件重写是指定去重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作!

对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此实际情侣下，会关闭自动的文件重写，然后通过定时任务在每天的某一时刻定时执行。

(1)AOF 重写的原理：

AOF 重写并不会读取现有的 AOF 文件并重新压缩，而是通过 Redis 内存中的数据重新生成一个新的 AOF 文件：

a. Redis 会扫描当前内存中所有的数据，重新生成一个最简洁的命令序列。这可以显著减少文件的大小。例如，如果一个键先后进行了多次修改，AOF 文件可能记录了所有的修改操作，而重写后，AOF 文件只会记录最新的修改操作。无效的命令不再写入，文件多条命令可以合并为一个：如A B C1, A B C2, A B C3可以合并为A B C1 C2 C3。

---

b. 新的 AOF 文件会替换掉旧的 AOF 文件。过期的数据不再写入文件

(2)重写触发机制：

a. AOF 重写可以由两种方式触发：

• 手动触发：通过运行 BGREWRITEAOF 命令，手动启动 AOF 文件重写。在fork时阻塞。
• 自动触发：通过配置 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 来自动触发重写。例如，当 AOF 文件达到一定大小或超过原始大小的某个百分比时，Redis 会自动触发 AOF 重写。

b. AOF重写自动触发配置

vim /etc/redis/6379.conf

在771行配置
auto-aof-rewrite-percentage 100	
当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作

在772行配置
auto-aof-rewrite-min-size 64mb 
当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF	

注意：

1.重写由父进程fork子进程进行

2.重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

(3) 文件重写的流程

1.Redis父进程首先判断当前是否存在正在执行bgsave/bgrewriteaof的子进程，如果存在则bgrewriteaof命令直接返回，如果存在 bgsave命令则等bgsave执行完成后再执行。

2.父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。

3.1父进程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程， 并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。

3.2由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区(aof_rewrite_buf)保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。

4.子进程根据内存快照，按照命令合并规则写入到新的AOF文件。

5.1子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。

5.2父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。

5.3使用新的AOF文件替换老文件，完成AOF重写。

AOF流程图

2.4 启动时加载

当AOF开启时，Redis启动时会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会载入RDB文件恢复数据。

当AOF开启，但AOF文件不存在时，即使RDB文件存在也不会加载。

Redis载入AOF文件时，会对AOF文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)，且aof-load-truncated参数开启，则日志中会输出警告，Redis忽略掉AOF文件的尾部，启动成功。aof-load-truncated参数默认是开启的。

3.RDB和AOF的优缺点

3.1 RDB持久化

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

简化

• 持久化速度快(因为保存的是数据结果),在写入到xx.rdb持久化文件,会进行压缩,来减小自身的体积
• 集群中,redis·主从复制时，从 服务器到主服务器进行同步,默认先使用RDB文件进行恢复,所以说·同步性能较高

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

对于RDB持久化，一方面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来IO压力。

简化

• 数据完整性不如AOF
• RDB类似快照(完备)
• 在进行备份时,会进行阻塞

3.2 AOF持久化

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

简化

1、AOF的数据完整性比RDB高

2、重写功能·会对无效语句·进行删除

目的就是为了I节省AOF文件占用磁盘空间

缺点：对于AOF持久化，向硬盘写数据的频率大大提高(everysec策略下为秒级)，IO压力更大，甚至可能造成AOF追加阻塞问题。

AOF文件的重写与RDB的bgsave类似，会有fork时的阻塞和子进程的IO压力问题。相对来说，由于AOF向硬盘中写数据的频率更高，因此对 Redis主进程性能的影响会更大。

简化

1.执行语句·的一致的情况下,AOF备份文件内容更大

RDB备份·内容比较小

RDB备份·的就是结果

AOF备份的是语句

2.AOF消耗性能更大,占用磁盘越来越大.(可以理解为mysql·增量备份)

4.Redis缓存常见问题

4.1缓存穿透

缓存穿透是指请求的数据在缓存和数据库中都不存在，导致每次请求都直接查询数据库，进而对数据库造成压力。

解决方法：

• 缓存空结果：对于不存在的数据，缓存一个空值，设置短期过期时间，避免频繁查询数据库。
• 布隆过滤器：使用布隆过滤器判断请求的数据是否存在于数据库中，拦截不存在的数据请求。
• 参数校验：对请求的参数进行基本的合法性检查，过滤掉无效请求。

4.2缓存击穿

缓存击穿是指某个热点数据的缓存失效后，大量请求同时访问这个数据，导致短时间内所有请求都直接查询数据库，造成数据库压力剧增。

解决方法：

• 设置热点数据永不过期：对热点数据设置长期缓存，避免其失效。
• 加互斥锁：当缓存失效时，只有一个线程能更新缓存，其他请求等待，防止瞬时高并发打到数据库。
• 提前缓存更新：在缓存过期之前，提前刷新热点数据，确保缓存始终有效。

4.3缓存雪崩

缓存雪崩是指大量缓存数据在同一时间失效，导致所有请求都直接访问数据库，进而导致数据库压力过大甚至崩溃。

解决方法：

• 缓存过期时间错峰：为不同的缓存数据设置随机的过期时间，避免同一时间大量缓存同时失效。
• 热点数据持久化：将热点数据提前缓存并持久化，避免缓存失效导致高并发请求数据库。
• 加锁或队列：当缓存失效时，通过锁或队列控制对数据库的访问，避免大量请求同时打到数据库。

三，Redis性能管理

查看Redis数据碎片

1.内存碎片率

操作系统分配的内存值 used_memory_rss 除以 Redis 使用的内存总量值 used_memory 计算得出。

内存值 used_memory_rss 表示该进程所占物理内存的大小，即为操作系统分配给 Redis 实例的内存大小。

除了用户定义的数据和内部开销以外，used_memory_rss 指标还包含了内存碎片的开销， 内存碎片是由操作系统低效的分配/回收物理内存导致的（不连续的物理内存分配）。

假设 Redis 进程使用了 1GB 的内存数据 (used_memory)，而操作系统为该进程分配了 1.2GB 的物理内存 (used_memory_rss)，那么内存碎片率为：

内存碎片率=1.21=1.2\text{内存碎片率} = \frac{1.2}{1} = 1.2内存碎片率=11.2=1.2

这意味着 Redis 实际使用了 1GB 的数据，但由于内存碎片或操作系统内存分配不连续性，额外占用了 0.2GB 的物理内存。

这意味着 Redis 实际使用了 1GB 的数据，但由于内存碎片或操作系统内存分配不连续性，额外占用了 0.2GB 的物理内存。

2. 内存碎片率的含义

在系统为 Redis 分配内存时，通常会有一些碎片（不连续的小块内存）。

2.1当碎片率稍大于 1 时：

说明 Redis 正常运行，没有发生内存交换，也没有严重的内存碎片问题。

无需采取行动。

2.2内存碎片率超过 1.5 时说明碎片率较高：

Redis 占用了比实际需要更多的内存。比如，碎片率为 1.5，说明 Redis 需要 1GB 内存，但操作系统分配了 1.5GB，增加的部分是内存碎片。这意味着系统资源利用效率不高。

解决办法：

建议通过 redis-cli 工具执行 shutdown save 命令保存数据，然后重启 Redis。

这样可以释放掉操作系统中的内存碎片，并让 Redis 重新分配更有效的物理内存。

redis-cli
或
redis-cli -h <Redis服务器IP> -p <端口号> -a <密码>
redis-cli -h 127.0.0.1 -p 6379 -a 123456

shutdown save

2.3 内存碎片率低于 1 是警告信号：

如果碎片率小于 1，说明 Redis 的内存使用已经超出物理内存，操作系统不得不开始使用磁盘交换（swap）。这会严重影响 Redis 性能，因为从磁盘读取数据比从内存读取慢很多。

解决办法：

增加服务器物理内存，确保 Redis 有足够的内存使用。

减少 Redis 内存占用，可以通过调整 Redis 的配置或数据结构。

Redis一般4G最多8G

3.内存使用率

当Redis内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换。

3.1避免内存交换发生的办法：

• 针对缓存数据大小选择安装 Redis 实例
• 尽可能的使用Hash数据结构存储
• 设置key的过期时间

3.2 内回收key

内存清理策略，保证合理分配redis有限的内存资源。

当达到设置的最大阀值时，需选择一种key的回收策略，默认情况下回收策略是禁止删除。

在配置文件中可以修改 maxmemory-policy 属性值

vim /etc/redis/6379.conf

第598行配置
maxmemory-policy noenviction

volatile-lru      #使用LRU算法从已设置过期时间的数据集合中淘汰数据(移除最近最少使用的key，针对设置了TTL的key)
volatile-ttl      #从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
volatile-random： #从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
allkeys-lru：     #使用LRU算法从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
allkeys-random：  #从数据集合中任意选择数据淘汰（随机移除key）
noenviction：     #禁止淘汰数据（不删除直到写满时报错）