免费做网站视频,软件项目管理是做什么,企业获客方式,沈阳黑酷做网站建设优化公司怎么样Redis高可用主要通过以下几种方式来实现#xff1a;单机、主从复制、哨兵模式、和集群模式。这些方式都旨在提高系统的稳定性和可用性#xff0c;特别是在面对服务器故障或其他问题时。 持久化#xff1a; 在数据库和缓存系统中#xff0c;持久化是指将数据保存在存储介质单机、主从复制、哨兵模式、和集群模式。这些方式都旨在提高系统的稳定性和可用性特别是在面对服务器故障或其他问题时。 持久化 在数据库和缓存系统中持久化是指将数据保存在存储介质通常是硬盘上以确保在系统重启或关闭时数据不会丢失。Redis作为一个内存数据库也提供了持久化的机制以防止数据在内存中丢失。 在Redis中主要有两种持久化方式 RDB持久化 RDB持久化是将Redis在内存中的数据定期保存到硬盘上的一个快照文件。 这个快照是一个二进制文件包含了某个时间点上的所有数据。可以根据配置的规则例如每隔一段时间保存一次或者当有一定数量的写操作发生时保存。 RDB持久化适用于备份和灾难恢复但会导致在保存时的短暂停顿。 AOF持久化 AOFAppend-Only File持久化是通过将写操作追加到一个文件中来记录数据库状态的变更。 这个文件是一个文本文件可以通过配置将其同步到硬盘。由于是追加操作AOF持久化方式通常比RDB更耗时但可以提供更好的数据安全性因为它可以记录每一次写操作。 AOF持久化适用于需要快速恢复并且可以接受稍微增加存储和写操作开销的情况。 可以根据应用的需求选择使用RDB、AOF或者同时使用两者即混合持久化。混合持久化可以兼具RDB的快速恢复和AOF的数据安全性。在实际应用中选择适当的持久化方式需要权衡数据安全、性能、存储开销等因素。 主从复制模式 主从复制是通过在多台服务器上运行Redis实例其中一台为主服务器Master其余为从服务器Slave。 主服务器负责写操作而从服务器负责复制主服务器的数据提供读操作。这样可以分担读写压力并提高系统的可用性。 一旦主服务器宕机可以手动或自动将其中一台从服务器切换为主服务器以确保服务的连续性。
哨兵模式 哨兵模式是主从复制的扩展通过引入哨兵Sentinel进程来监控主服务器的状态。 当主服务器宕机或不可达时哨兵会自动选举一个从服务器升级为主服务器以保障服务的可用性。 哨兵模式解决了手动切换的缺点增加了自动化和实时监控。
集群模式 Redis集群模式通过分片和多节点部署来实现高可用性和横向扩展。 数据被分为多个槽slots每个节点负责一部分槽的数据。这样可以均衡负载提高并发处理能力。 集群模式通过节点间的协调和通信实现了数据的自动迁移和负载均衡增强了系统的可扩展性和容错性。
总体而言Redis的高可用性可以根据实际需求选择适当的部署方式。单机模式适用于小规模应用而主从复制、哨兵模式和集群模式则适用于大规模、高并发的生产环境。选择合适的方式需要综合考虑系统的规模、性能需求以及容错能力。
持久化
RDB持久化
RDBRedis Database Backup持久化是Redis用于将内存中的数据定期保存到硬盘上的一种持久化方式。它通过生成快照来保存数据并且是默认的持久化方式之一。以下是RDB持久化的流程和原理
RDB持久化流程
触发条件
RDB持久化可以通过配置文件中的定时触发例如每隔一段时间执行一次或者根据写操作的数量来触发。
生成快照 当触发条件满足时Redis会fork出一个子进程该子进程负责执行RDB持久化操作。 子进程会遍历整个数据集然后将数据集的内容写入一个临时的RDB文件中。
写入临时文件 生成快照时Redis使用一个临时文件来保存数据以确保在生成过程中不会影响到实际的持久化文件。 在确保临时文件完全生成后Redis会用该临时文件替换原来的持久化文件。
持久化文件替换 当生成的临时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 BGSAVEsave命令会阻塞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持久化
AOFAppend-Only File持久化是Redis用于将写操作追加到一个文件中以记录数据库状态的变更的一种持久化方式。以下是AOF持久化的流程和原理
AOF持久化流程
写操作记录
每当有写操作例如SET、DEL等发生时Redis会将这个写操作以协议的形式追加到AOF文件末尾。
文件同步可选 根据配置Redis可以选择在每次写操作后进行文件同步fsync操作确保写入磁盘提高数据持久性。 文件同步的频率可以根据需求进行配置可以选择在每个写命令、每秒一次或者根据时间间隔执行。
AOF文件重写可选 为了避免AOF文件不断增长Redis支持AOF文件的重写。这个操作会创建一个新的AOF文件其中包含了当前数据集的完整快照而不是所有历史写操作。 AOF文件重写可以通过BGREWRITEAOF命令手动触发也可以根据配置的自动触发条件来执行。
文件加载
当Redis重新启动时可以通过加载AOF文件将写操作重新执行从而还原数据库的状态。
AOF持久化原理 AOF文件格式 AOF文件是一个文本文件其中包含了Redis客户端向Redis服务器发送的原始通信协议的内容。这使得AOF文件相对易于阅读和理解。 追加写入 AOF持久化的主要原理是将写操作追加到AOF文件末尾这是一个追加写入的操作而不是覆盖写入。 这样可以确保AOF文件始终包含了数据库状态的完整历史。 文件同步 文件同步操作fsync用于确保将写入磁盘提高数据的持久性。文件同步的方式有三种无同步、每秒同步、每次写入同步可以根据需求进行配置。 AOF文件重写 AOF文件重写是通过遍历内存中的数据集来创建一个新的AOF文件其中只包含了当前数据集的快照。 这个过程可以减小AOF文件的体积提高AOF文件的读写效率同时保留了完整的数据历史。
AOF持久化适用于需要高可用性和数据安全性的场景因为它可以提供更精确的数据恢复点并且相对于RDB持久化可以实现更小的数据丢失。 AOF持久化的缺点是相对于RDBAOF文件体积可能会较大。
AOF使用
打开AOF
打开 AOF 持久化 在 Redis 配置文件redis.conf中找到并修改以下配置项将其设置为 yes启用 AOF 持久化
vim /etc/redis/6379.conf
--700行--修改开启AOF
appendonly yesAOF 文件的位置 默认情况下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操作。
文件重写的流程 启动 AOF 重写 AOF 重写可以由用户手动触发使用 BGREWRITEAOF 命令或由 Redis 自动触发根据配置的条件。当触发 AOF 重写时Redis 将创建一个子进程来执行重写操作。 创建临时文件 在 AOF 重写过程中Redis 首先会创建一个临时文件通常以 temp-rewriteaof-bg-pid.aof 的形式命名。这个文件用于存储重写期间的写命令。 执行数据快照 在 AOF 重写开始时Redis 会执行一个数据快照snapshot将当前数据库的状态保存到内存中。这个快照包含了当前时刻的所有键值对。 重放写命令 通过遍历内存中的数据快照Redis 将写命令重新生成并将这些写命令追加到临时 AOF 文件中。这确保了新的 AOF 文件包含了当前数据库的完整状态。 继续处理新命令 在 AOF 重写期间Redis 仍然会继续处理新的写命令并将它们同时追加到原始的 AOF 文件和临时 AOF 文件中。这样可以保证在 AOF 重写过程中不会丢失任何数据。 替换旧 AOF 文件 当 AOF 重写完成后Redis 将原始的 AOF 文件替换为临时 AOF 文件。这是一个原子操作以确保在替换的瞬间不会有数据丢失。 清理临时文件 最后Redis 会删除旧的 AOF 文件将临时 AOF 文件重命名为正式的 AOF 文件并释放相应的资源。此时新的 AOF 文件包含了经过优化和紧凑的写命令集。
1Redis父进程首先判断当前是否存在正在执行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 BGREWRITEAOFAOF 恢复 在 Redis 启动时如果启用了 AOF 持久化Redis 会自动从 AOF 文件中重新执行写命令以还原数据到内存中。
RDB和AOF的优缺点
RDB 持久化
优点 性能较好 RDB 持久化是通过在指定时间间隔内生成数据库的快照因此对于备份和恢复操作来说性能较好。加载快照通常比重新执行 AOF 文件中的所有写命令更快。 文件紧凑 RDB 文件是二进制格式的数据库快照非常紧凑适合用于全量备份和恢复。 适用于大数据集 在大数据集的情况下RDB 的性能可能会优于 AOF。
缺点 数据可能丢失 RDB 是周期性生成快照如果在生成快照的时间点发生故障可能会导致最后一次快照后的数据丢失。 不适用于实时持久化 RDB 持久化是定时生成快照不适用于对数据进行实时持久化的需求。
区别
持久化就是把内存的数据写到磁盘中去防止服务宕机了内存数据丢失。有两种持久化方式RDB默认和AOF持久化
• RDBRedis 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 持久化
优点 数据更安全 AOF 持久化记录了每个写操作的详细命令因此在故障发生时可以通过重新执行 AOF 文件中的命令来还原数据库状态避免数据丢失。 适用于实时持久化 AOF 持久化以日志形式追加写命令适用于需要实时持久化数据的场景。 易于分析和修复 AOF 文件是文本格式易于查看、分析和手动修改。这在需要修复损坏的数据时可能会更方便。
缺点 文件较大 AOF 文件通常比 RDB 文件大因为它包含了每个写操作的详细记录。这可能导致磁盘占用较多空间。 性能相对较低 在写入频繁的情况下AOF 持久化可能会对性能产生一定影响因为每个写操作都要追加到 AOF 文件。 恢复时间较长 在故障恢复时由于需要重新执行 AOF 文件中的所有写命令恢复时间可能会较长。 redis性能管理
查看Redis内存使用
192.168.9.236:7001 info memory内存碎片率
内存碎片率是衡量系统内存利用效率的一个指标通常表示系统中的空闲内存与总内存之比。具体来说内存碎片率可以分为两类 外部碎片率External Fragmentation Rate 外部碎片率是指分散在内存中的不连续的小块空闲内存的比例。这些小块空闲内存虽然总和可以很大但由于它们分布在各个位置可能无法被有效地利用。外部碎片率的增加可能导致系统难以找到足够的连续内存块来满足某些大内存需求的程序从而影响系统性能。 内部碎片率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中的内存回收策略其中包括了三种不同的策略 立即过期对于每个设置了过期时间的key会创建一个定时器到过期时间就会立即清除。这样可以立即清除过期的数据对内存很友好但会占用大量CPU资源影响缓存的响应时间和吞吐量。 惰性过期只有在访问一个key时才判断该key是否已过期过期则清除。这可以最大程度地节省CPU资源但对内存非常不友好可能导致大量过期key没有再次被访问而占用大量内存。 定期过期每隔一定时间会扫描一定数量的数据库的expires字典中的一定数量的key并清除已过期的key。这是前两者的折中方案通过调整定时扫描的时间间隔和每次扫描的限定耗时可以在不同情况下使CPU和内存资源达到最优的平衡效果。
此外当Redis达到配置文件最大内存限制时有三种处理策略 noeviction默认策略对于写请求不再提供服务直接返回错误除了DEL请求和部分特殊请求。 allkeys-lru从所有key中使用LRU算法进行淘汰。 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禁止淘汰数据不删除直到写满时报错
