Redis内存淘汰策略针对外层key,支持LRU、LFU、TTL及随机淘汰。持久化含RDB快照、AOF日志及混合模式,AOF支持always、everysec、no三种同步策略。主从采用异步复制保证最终一致性,哨兵实现主从切换,Redis-Cluster通过一致性哈希实现分布式数据均衡。
当内存占用达到 max_memory 上限时(在 redis.conf 中配置,例如主机内存为 96G,建议设置为 48G,因为持久化时需要 fork 一份当前 Redis 的快照),淘汰策略便会生效。
需明确一点:淘汰策略仅针对最外层 key,不会检测 value 内部的 key,例如 list 的 element 或 hash 的 field。
长期稳定更新的攒劲资源: >>>点此立即查看<<<
| 淘汰策略 | 含义 |
|---|---|
| volatile-lru | 淘汰最长时间未被使用的 key |
| volatile-lfu | 淘汰使用次数最少的 key,或随机采样 |
| volatile-ttl | 淘汰即将过期的 key |
| volatile-random | 随机淘汰 |
| 淘汰策略 | 含义 |
|---|---|
| allkeys-lru | 淘汰最长时间未被使用的 key |
| allkeys-lfu | 淘汰使用次数最少的 key,或随机采样 |
| volatile-random | 随机淘汰 |
选用此策略时,若内存达到上限,写入指令将直接返回错误。
Redis 作为内存数据库,所有数据存储在内存中,速度虽快但数据易丢失。默认开启 RDB 持久化。
底层 IO 流程:fopen → fwrite → setbuf → fflush → fsync → fclose
fwrite 操作本质上仅将 buffer 中的数据搬运至用户态缓冲区,内核对此毫不知情。随后,fflush 将用户态缓冲区的数据移动到 page cache(高速缓存)。若不调用 fsync,数据最终仍会写入磁盘,但时间不确定——通过 LRU 算法将 page cache 中的数据淘汰到磁盘文件中。

存在两个风险点:机器断电会丢失第 1、2 阶段的数据;进程关闭则会丢失第 1 阶段的数据。
fork 写时复制:子进程与父进程映射同一块物理内存。父进程会复制一份虚拟内存页表给子进程,并将两者设置为只读,虚拟内存映射到同一物理页。只有当其中一个进程试图修改共享的只读物理页面时(例如修改全局变量或在堆上分配新内存),才会触发写保护中断,物理页发生复制,修改者指向新页面,并将只读状态修改为可读可写。

利用 fork 进程功能,相当于为父进程内存创建了一份快照。更重要的是,此过程在维持 Redis 对外服务能力的同时,完成了数据的一次保存。
AOF 通过不断追加写操作日志到 buffer 中实现持久化。其优势在于:顺序磁盘 IO 的速度已接近内存随机 IO。但 AOF 也存在数据冗余问题,例如多次 set 操作中,仅最后一条 set 真正有效。
AOF 提供三种同步策略:
① always:只要对 Redis 有修改,立即写盘。
② every_sec:每秒进行一次落盘(由 bio_fsync_aof 执行)。
③ no:buffer 数据仅写入 page cache(机制同上)。
AOF-rewrite
fork 一个子进程,仅保存当前 Redis 内存状态,根据内存数据重新生成 AOF 文件。此举可去除同一 key 的历史冗余。重写 AOF 期间,所有对 Redis 的写操作会被记录到重写缓冲区,重写结束后,这些增量操作被附加到 AOF 文件末尾。
通过 fork 子进程进行持久化,基于内存中完整数据集生成快照。但 RDB 存在明显短板:两次 RDB 之间的数据修改无法被记录。
RDB-AOF 混合持久化
此模式在 RDB 持久化期间,将 Redis 的写操作记录到重写缓冲区。RDB 持久化完成后,缓冲区中的增量数据被附加到 AOF 文件末尾,兼顾了 RDB 的恢复速度与 AOF 的数据完整性。
所有持久化相关配置均在 redis.conf 中完成。
######### aof ########## redis.cnf appendonly no appendfilename "appendonly.aof" # aof read write invert # appendfsync always appendfsync everysec # appendfsync no # auto-aof-rewrite-percentage 为 0 则关闭 aof 复写 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # yes 如果 aof 数据不完整,尽量读取最多的格式正确的数据; # no 如果 aof 数据不完整 报错,可以通过 redis-check-aof 来修复 aof 文件; aof-load-truncated yes # 开启混合持久化 aof-use-rdb-preamble yes ######### rdb ########## # sa ve "" # sa ve 3600 1 # sa ve 300 100 # sa ve 60 10000
# 开启 aof appendonly yes # 关闭 aof复写 auto-aof-rewrite-percentage 0 # 关闭 混合持久化 aof-use-rdb-preamble no # 关闭 rdb sa ve "" # 1. 每条命令刷盘 redis 事务才具备持久性 # appendfsync always # 2. 每秒刷盘 appendfsync everysec # 3. 交由系统刷盘 # appendfsync no
# 开启 aof appendonly yes # 开启 aof复写 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 关闭 混合持久化 aof-use-rdb-preamble no # 关闭 rdb sa ve "" # 策略1:redis记录上次aof复写时的size,之后如果累计增长了100%则触发重写 auto-aof-rewrite-percentage 100 # 策略2:为了避免小数据量时频繁触发重写,需同时满足文件超过64mb才进行 auto-aof-rewrite-min-size 64mb
# 关闭 aof 同时也关闭了 aof复写 appendonly no # 关闭 aof复写 auto-aof-rewrite-percentage 0 # 关闭 混合持久化 aof-use-rdb-preamble no # 开启 rdb 也就是注释 sa ve "" # sa ve "" sa ve 3600 1 sa ve 300 100 sa ve 60 10000 # redis默认策略如下: # 注意:写了多个sa ve策略,只要满足一个就会触发rdb持久化 # 3600秒内有1次修改 # 300秒内有100次修改 # 60秒内有10000次修改
# 开启 aof appendonly yes # 开启 aof复写 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 开启 混合持久化 aof-use-rdb-preamble yes # 关闭 rdb sa ve ""
| 特性 | AOF(Append Only File) | RDB(Redis Database Snapshot) |
|---|---|---|
| 优点 | 数据可靠,丢失较少 持久化过程代价较低 |
RDB 文件小 数据恢复快 |
| 缺点 | AOF 文件过大 数据恢复慢 |
数据丢失较多 持久化过程代价较高(fork 子进程实现) |
主从复制的核心目标是解决单点故障带来的数据安全问题,防止 Redis 所在磁盘损坏后数据彻底丢失。
Redis 主从之间采用异步复制方式。异步复制的优点在于高效,缺点是只能保证最终一致性。现代分布式系统大多追求半数一致性,这是一个合理的折中方案。

#redis.conf replicaof 127.0.0.1 7002 info replication
哨兵模式是主从切换的经典实现。但哨兵仅保证单个节点的可用性,并非多节点同时对外服务。

Redis Cluster 引入多个中心节点对外提供服务,真正实现了分布式架构。

这里有一个绕不开的问题:向其中一个主节点写入数据时,如何保证数据均匀分布到所有主节点?这需要关注一致性哈希算法。关于 Redis-Cluster 集群的详细配置,此处不做展开,有兴趣可查阅官方文档。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述