Redis持久化，性能管理

2023-12-19 23:00:17

Redis高可用主要通过以下几种方式来实现：单机、主从复制、哨兵模式、和集群模式。这些方式都旨在提高系统的稳定性和可用性，特别是在面对服务器故障或其他问题时。

  1. 持久化：

    在数据库和缓存系统中，持久化是指将数据保存在存储介质（通常是硬盘）上，以确保在系统重启或关闭时数据不会丢失。Redis作为一个内存数据库，也提供了持久化的机制，以防止数据在内存中丢失。

    在Redis中，主要有两种持久化方式：

  2. RDB持久化：

    • RDB持久化是将Redis在内存中的数据定期保存到硬盘上的一个快照文件。

    • 这个快照是一个二进制文件，包含了某个时间点上的所有数据。可以根据配置的规则，例如每隔一段时间保存一次，或者当有一定数量的写操作发生时保存。

    • RDB持久化适用于备份和灾难恢复，但会导致在保存时的短暂停顿。

  3. AOF持久化：

    • AOF（Append-Only File）持久化是通过将写操作追加到一个文件中来记录数据库状态的变更。

    • 这个文件是一个文本文件，可以通过配置将其同步到硬盘。由于是追加操作，AOF持久化方式通常比RDB更耗时，但可以提供更好的数据安全性，因为它可以记录每一次写操作。

    • AOF持久化适用于需要快速恢复并且可以接受稍微增加存储和写操作开销的情况。

    可以根据应用的需求选择使用RDB、AOF，或者同时使用两者（即混合持久化）。混合持久化可以兼具RDB的快速恢复和AOF的数据安全性。在实际应用中，选择适当的持久化方式需要权衡数据安全、性能、存储开销等因素。

  4. 主从复制模式：

  • 主从复制是通过在多台服务器上运行Redis实例，其中一台为主服务器（Master），其余为从服务器（Slave）。

  • 主服务器负责写操作，而从服务器负责复制主服务器的数据，提供读操作。这样可以分担读写压力，并提高系统的可用性。

  • 一旦主服务器宕机，可以手动或自动将其中一台从服务器切换为主服务器，以确保服务的连续性。

  1. 哨兵模式：

  • 哨兵模式是主从复制的扩展，通过引入哨兵（Sentinel）进程来监控主服务器的状态。

  • 当主服务器宕机或不可达时，哨兵会自动选举一个从服务器升级为主服务器，以保障服务的可用性。

  • 哨兵模式解决了手动切换的缺点，增加了自动化和实时监控。

  1. 集群模式：

  • Redis集群模式通过分片和多节点部署来实现高可用性和横向扩展。

  • 数据被分为多个槽（slots），每个节点负责一部分槽的数据。这样可以均衡负载，提高并发处理能力。

  • 集群模式通过节点间的协调和通信，实现了数据的自动迁移和负载均衡，增强了系统的可扩展性和容错性。

总体而言，Redis的高可用性可以根据实际需求选择适当的部署方式。单机模式适用于小规模应用，而主从复制、哨兵模式和集群模式则适用于大规模、高并发的生产环境。选择合适的方式需要综合考虑系统的规模、性能需求以及容错能力。

持久化

RDB持久化

RDB（Redis Database Backup）持久化是Redis用于将内存中的数据定期保存到硬盘上的一种持久化方式。它通过生成快照来保存数据，并且是默认的持久化方式之一。以下是RDB持久化的流程和原理：

RDB持久化流程：

  1. 触发条件：
  • RDB持久化可以通过配置文件中的定时触发（例如每隔一段时间执行一次）或者根据写操作的数量来触发。
  1. 生成快照：

  • 当触发条件满足时，Redis会fork出一个子进程，该子进程负责执行RDB持久化操作。

  • 子进程会遍历整个数据集，然后将数据集的内容写入一个临时的RDB文件中。

  1. 写入临时文件：

  • 生成快照时，Redis使用一个临时文件来保存数据，以确保在生成过程中不会影响到实际的持久化文件。

  • 在确保临时文件完全生成后，Redis会用该临时文件替换原来的持久化文件。

  1. 持久化文件替换：

  • 当生成的临时RDB文件写入完成后，Redis会用该文件替换原先的RDB文件。

  • 这个替换操作是一个原子性的操作，它可以确保在替换期间不会丢失数据。

RDB持久化原理：

  • 快照文件格式：

  • RDB快照文件是一个二进制文件，包含了Redis在某个特定时间点上的数据集状态。

  • 这个文件包含了所有的键值对、过期时间、数据库配置等信息。

  • fork子进程：

  • Redis在进行RDB持久化时，通过fork系统调用创建一个子进程。

  • 子进程会复制父进程的内存数据，并在内存中执行数据的序列化操作，然后将数据写入临时文件。

  • 阻塞风险：

  • 在生成快照期间，Redis主进程可能会因为fork子进程而阻塞。

  • 阻塞时间取决于数据集的大小和复制操作的速度。在大型数据集的情况下，这可能导致一定时间内的服务停顿。

  • 持久化文件的加载：

  • 当Redis重新启动时，可以通过加载RDB文件将数据集重新载入到内存中，恢复之前的数据状态。

RDB持久化适用于需要进行周期性备份的场景，并且相对于AOF持久化，它对系统的性能影响较小。但是在生成快照时可能会导致阻塞，因此需要谨慎配置触发条件，以平衡数据的实时性和系统的性能。

RDB使用

触发条件

手动触发

save命令和bgsave命令都可以生成RDB文件。

  • 使用 SAVE 命令：SAVE 命令会阻塞 Redis 服务器，直到 RDB 文件生成完毕。这样的方式可能在数据较大时影响服务器性能，因此一般在生产环境中不推荐使用。
redis-cli> SAVE
  • 使用 BGSAVE 命令：BGSAVE 命令在后台异步执行 RDB 持久化，不会阻塞服务器，因此是推荐的方式。
redis-cli> BGSAVE

save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。 而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求。

bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用。

自动触发

在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化。

save m n 自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。

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
--264行--指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379
--242行--是否开启RDB文件压缩
rdbcompression yes

其他自动触发机制 除了save m n 以外，还有一些其他情况会触发bgsave：

  • 在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点。

  • 执行shutdown命令时，自动执行rdb持久化。

执行流程

  • Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。 bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。

  • 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令

  • 父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令

  • 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换

  • 子进程发送信号给父进程表示完成，父进程更新统计信息

启动时加载

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入 AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。 Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

AOF持久化

AOF（Append-Only File）持久化是Redis用于将写操作追加到一个文件中，以记录数据库状态的变更的一种持久化方式。以下是AOF持久化的流程和原理：

AOF持久化流程：

  1. 写操作记录：
  • 每当有写操作（例如SET、DEL等）发生时，Redis会将这个写操作以协议的形式追加到AOF文件末尾。
  1. 文件同步（可选）：

  • 根据配置，Redis可以选择在每次写操作后进行文件同步（fsync）操作，确保写入磁盘，提高数据持久性。

  • 文件同步的频率可以根据需求进行配置，可以选择在每个写命令、每秒一次或者根据时间间隔执行。

  1. AOF文件重写（可选）：

  • 为了避免AOF文件不断增长，Redis支持AOF文件的重写。这个操作会创建一个新的AOF文件，其中包含了当前数据集的完整快照，而不是所有历史写操作。

  • AOF文件重写可以通过BGREWRITEAOF命令手动触发，也可以根据配置的自动触发条件来执行。

  1. 文件加载：
  • 当Redis重新启动时，可以通过加载AOF文件将写操作重新执行，从而还原数据库的状态。

AOF持久化原理：

  • AOF文件格式：

  • AOF文件是一个文本文件，其中包含了Redis客户端向Redis服务器发送的原始通信协议的内容。这使得AOF文件相对易于阅读和理解。

  • 追加写入：

  • AOF持久化的主要原理是将写操作追加到AOF文件末尾，这是一个追加写入的操作，而不是覆盖写入。

  • 这样可以确保AOF文件始终包含了数据库状态的完整历史。

  • 文件同步：

  • 文件同步操作（fsync）用于确保将写入磁盘，提高数据的持久性。文件同步的方式有三种：无同步、每秒同步、每次写入同步，可以根据需求进行配置。

  • AOF文件重写：

  • AOF文件重写是通过遍历内存中的数据集来创建一个新的AOF文件，其中只包含了当前数据集的快照。

  • 这个过程可以减小AOF文件的体积，提高AOF文件的读写效率，同时保留了完整的数据历史。

AOF持久化适用于需要高可用性和数据安全性的场景，因为它可以提供更精确的数据恢复点，并且相对于RDB持久化，可以实现更小的数据丢失。 AOF持久化的缺点是相对于RDB，AOF文件体积可能会较大。

AOF使用

打开AOF

打开 AOF 持久化： 在 Redis 配置文件（redis.conf）中，找到并修改以下配置项，将其设置为 yes，启用 AOF 持久化：

vim /etc/redis/6379.conf
--700行--修改，开启AOF
appendonly yes

AOF 文件的位置： 默认情况下，AOF 文件将保存在 Redis 安装目录下，文件名为 appendonly.aof。你可以通过配置文件指定其他位置：

--704行--指定AOF文件名称
appendfilename "appendonly.aof"
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes

/etc/init.d/redis_6379 restart

命令追加

命令追加(append)

Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。 命令追加的格式是Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点。在AOF文件中，除了用于指定数据库的select命令（如select 0为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。

文件写入(write)和文件同步(sync)

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下： 为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

AOF缓存区的同步文件策略存在三种同步方式，它们分别是：
vim /etc/redis/6379.conf
--729--
appendfsync always：
命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。

appendfsync no：
命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。

appendfsync everysec：
命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

文件重写

AOF 重写： AOF 文件在运行一段时间后可能会变得很大，影响性能。为了解决这个问题，Redis 提供了 AOF 重写机制，可以通过以下配置开启：

vim /etc/redis/6379.conf
--729--
auto-aof-rewrite-percentage 100 
#当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
auto-aof-rewrite-min-size 64mb
#当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF

上述配置表示，当 AOF 文件大小超过当前大小的 100% 且文件大小超过 64MB 时，触发 AOF 重写。

文件重写之所以能够压缩AOF文件的原因

●过期的数据不再写入文件 ●无效的命令不再写入文件：如有些数据被重复设值(set mykey v1, set mykey v2)、有些数据被删除了(set myset v1, del myset)等。 ●多条命令可以合并为一个：如sadd myset v1, sadd myset v2, sadd myset v3可以合并为sadd myset v1 v2 v3。

文件重写的触发，分为手动触发和自动触发

●手动触发：直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。 ●自动触发：通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEAOF。 只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个选项同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

文件重写的流程

  1. 启动 AOF 重写： AOF 重写可以由用户手动触发（使用 BGREWRITEAOF 命令）或由 Redis 自动触发（根据配置的条件）。当触发 AOF 重写时，Redis 将创建一个子进程来执行重写操作。

  2. 创建临时文件： 在 AOF 重写过程中，Redis 首先会创建一个临时文件，通常以 "temp-rewriteaof-bg-pid.aof" 的形式命名。这个文件用于存储重写期间的写命令。

  3. 执行数据快照： 在 AOF 重写开始时，Redis 会执行一个数据快照（snapshot），将当前数据库的状态保存到内存中。这个快照包含了当前时刻的所有键值对。

  4. 重放写命令： 通过遍历内存中的数据快照，Redis 将写命令重新生成，并将这些写命令追加到临时 AOF 文件中。这确保了新的 AOF 文件包含了当前数据库的完整状态。

  5. 继续处理新命令： 在 AOF 重写期间，Redis 仍然会继续处理新的写命令，并将它们同时追加到原始的 AOF 文件和临时 AOF 文件中。这样可以保证在 AOF 重写过程中不会丢失任何数据。

  6. 替换旧 AOF 文件： 当 AOF 重写完成后，Redis 将原始的 AOF 文件替换为临时 AOF 文件。这是一个原子操作，以确保在替换的瞬间不会有数据丢失。

  7. 清理临时文件： 最后，Redis 会删除旧的 AOF 文件，将临时 AOF 文件重命名为正式的 AOF 文件，并释放相应的资源。此时，新的 AOF 文件包含了经过优化和紧凑的写命令集。

（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开启时，Redis启动时会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会载入RDB文件恢复数据。 当AOF开启，但AOF文件不存在时，即使RDB文件存在也不会加载。 Redis载入AOF文件时，会对AOF文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)，且aof-load-truncated参数开启，则日志中会输出警告，Redis忽略掉AOF文件的尾部，启动成功。aof-load-truncated参数默认是开启的。

手动执行 BGREWRITEAOF 命令： 你也可以手动执行 BGREWRITEAOF 命令来触发 AOF 重写，它会在后台进行重写操作，不会阻塞其他 Redis 操作。

redis-cli> BGREWRITEAOF

AOF 恢复： 在 Redis 启动时，如果启用了 AOF 持久化，Redis 会自动从 AOF 文件中重新执行写命令，以还原数据到内存中。

RDB和AOF的优缺点

RDB 持久化：

优点：

  1. 性能较好： RDB 持久化是通过在指定时间间隔内生成数据库的快照，因此对于备份和恢复操作来说，性能较好。加载快照通常比重新执行 AOF 文件中的所有写命令更快。

  2. 文件紧凑： RDB 文件是二进制格式的数据库快照，非常紧凑，适合用于全量备份和恢复。

  3. 适用于大数据集： 在大数据集的情况下，RDB 的性能可能会优于 AOF。

缺点：

  1. 数据可能丢失： RDB 是周期性生成快照，如果在生成快照的时间点发生故障，可能会导致最后一次快照后的数据丢失。

  2. 不适用于实时持久化： RDB 持久化是定时生成快照，不适用于对数据进行实时持久化的需求。

区别

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。有两种持久化方式：RDB（默认）和AOF持久化

? RDB（Redis DataBase）持久化 : Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

? AOF(append only file)持久化 :是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。

当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

两种方式都可以把Redis内存中的数据持久化到磁盘上，然后再将这些数据备份到别的地方去，RDB更适合做冷备，AOF更适合做热备

综合比对：

RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊：

如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF

如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB

灾难恢复选用RDB

双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

AOF 持久化：

优点：

  1. 数据更安全： AOF 持久化记录了每个写操作的详细命令，因此在故障发生时，可以通过重新执行 AOF 文件中的命令来还原数据库状态，避免数据丢失。

  2. 适用于实时持久化： AOF 持久化以日志形式追加写命令，适用于需要实时持久化数据的场景。

  3. 易于分析和修复： AOF 文件是文本格式，易于查看、分析和手动修改。这在需要修复损坏的数据时可能会更方便。

缺点：

  1. 文件较大： AOF 文件通常比 RDB 文件大，因为它包含了每个写操作的详细记录。这可能导致磁盘占用较多空间。

  2. 性能相对较低： 在写入频繁的情况下，AOF 持久化可能会对性能产生一定影响，因为每个写操作都要追加到 AOF 文件。

  3. 恢复时间较长： 在故障恢复时，由于需要重新执行 AOF 文件中的所有写命令，恢复时间可能会较长。

redis性能管理

查看Redis内存使用

192.168.9.236:7001> info memory

内存碎片率

内存碎片率是衡量系统内存利用效率的一个指标，通常表示系统中的空闲内存与总内存之比。具体来说，内存碎片率可以分为两类：

  1. 外部碎片率（External Fragmentation Rate）： 外部碎片率是指分散在内存中的不连续的小块空闲内存的比例。这些小块空闲内存虽然总和可以很大，但由于它们分布在各个位置，可能无法被有效地利用。外部碎片率的增加可能导致系统难以找到足够的连续内存块来满足某些大内存需求的程序，从而影响系统性能。

  2. 内部碎片率（Internal Fragmentation Rate）： 内部碎片率是指已经分配给进程但没有被利用的内存的比例。当内存分配算法为了满足某个进程的内存需求而分配了一块稍大于进程请求的内存块时，就会产生内部碎片。这部分内存虽然已经分配，但却没有被充分利用，因此被认为是碎片。

操作系统分配的内存值 used_memory_rss 除以 Redis 使用的内存总量值 used_memory 计算得出。
内存值 used_memory_rss 表示该进程所占物理内存的大小，即为操作系统分配给 Redis 实例的内存大小。

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

举例来说：Redis 需要分配连续内存块来存储 1G 的数据集。如果物理内存上没有超过 1G 的连续内存块， 那操作系统就不得不使用多个不连续的小内存块来分配并存储这 1G 数据，该操作就会导致内存碎片的产生。

#跟踪内存碎片率对理解Redis实例的资源性能是非常重要的：
●内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低，也说明 Redis 没有发生内存交换。
●内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率。需要在redis-cli工具上输入shutdown save 命令，让 Redis 数据库执行保存操作并关闭 Redis 服务，再重启服务器。
●内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加可用物理内存或减少 Redis 内存占用。

内存使用率

内存使用率是指系统当前正在使用的物理内存占总可用内存的比例。这是一个重要的性能指标，用于衡量系统内存资源的利用情况。

在Linux系统中，可以使用一些命令来查看内存使用率，其中最常用的是 free 命令。该命令会显示关于内存总量、已使用的内存、空闲内存等相关信息。

例如，在终端中执行以下命令可以查看内存使用率：

free -m

这将以兆字节（MB）为单位显示内存信息。也可以使用其他工具或监控软件来实时监测系统内存使用情况，以便及时调整系统配置或优化程序性能。

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

#避免内存交换发生的方法：
●针对缓存数据大小选择安装 Redis 实例
●尽可能的使用Hash数据结构存储
●设置key的过期时间

内存回收key

Redis中的内存回收策略，其中包括了三种不同的策略：

  1. 立即过期：对于每个设置了过期时间的key，会创建一个定时器，到过期时间就会立即清除。这样可以立即清除过期的数据，对内存很友好，但会占用大量CPU资源，影响缓存的响应时间和吞吐量。

  2. 惰性过期：只有在访问一个key时才判断该key是否已过期，过期则清除。这可以最大程度地节省CPU资源，但对内存非常不友好，可能导致大量过期key没有再次被访问而占用大量内存。

  3. 定期过期：每隔一定时间，会扫描一定数量的数据库的expires字典中的一定数量的key，并清除已过期的key。这是前两者的折中方案，通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使CPU和内存资源达到最优的平衡效果。

此外，当Redis达到配置文件最大内存限制时，有三种处理策略：

  1. noeviction（默认策略）：对于写请求不再提供服务，直接返回错误，除了DEL请求和部分特殊请求。

  2. allkeys-lru：从所有key中使用LRU算法进行淘汰。

  3. volatile-lru：仅从设置了过期时间的key中使用LRU算法进行淘汰。

内存清理策略，保证合理分配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：禁止淘汰数据（不删除直到写满时报错）

文章来源:https://blog.csdn.net/qq_51545656/article/details/135089410
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。