当前位置: 代码网 > it编程>数据库>Redis > Redis的主从同步与对象模型详解

Redis的主从同步与对象模型详解

2026年03月27日 Redis 我要评论
淘汰策略当内存达到max_memory(在redis.conf中进行配置,主机内存96g,则设置为48g,因为持久化需要fork一份当前redis的快照)首先明确淘汰策略并不会检测value内部的ke

淘汰策略

当内存达到max_memory(在redis.conf中进行配置,主机内存96g,则设置为48g,因为持久化需要fork一份当前redis的快照)
首先明确淘汰策略并不会检测value内部的key,也即list的element,hash的field这些。

时限key中淘汰

淘汰策略意义
volatile-lru最长时间没有使用
volatile-lfu最少次数使用 或 随机采样
volatile-ttl最近要过期
volatile-random随机

所有key中淘汰

淘汰策略意义
allkeys-lru最长时间没有使用
allkeys-lfu最少次数使用 或 随机采样
volatile-random随机

禁止淘汰(默认)

指令返回错误

持久化

redis是一个内存数据库,所有的数据储存在内存中,虽然访问速度快但是易丢失。默认开启rdb持久化
fopen fwrite setbuf fflush fsync fclose
fwrite只是把buffer中的数据写到用户态缓冲区中,内核并不知情
fflush把fd对应的用户态缓冲区内部数据移动到page cache(高速缓存)
不调用fsync,数据也会到文件中,只不过不知道何时,通过lru把page cache中的数据淘汰到file中。

机器断电,丢失1,2的数据
进程关闭,丢失1的数据
fork写时复制:子进程和父进程映射同一块物理内存。
父进程复制一块虚拟内存页表给子进程,同时二者设置为可读,二者虚拟内存映射到同一块物理页。只有其中的任意一个进程试图修改一个共享的只读物理页面时(例如,修改一个全局变量或在堆上分配新内存),才会写保护中断触发,物理页复制,谁修改,谁指向新的,把只读状态修改为可读可写状态。

利用fork进程 的功能给父进程的内存打了快照。
在维持了redis对外服务能力的基础上,对redis数据做了一次保存。

aof

通过追加写日志到buffer的方式进行持久化。顺序磁盘io≈内存随机io
但是会有数据冗余的情况,多条set只有最后一条set是有效的。
aof的策略:
①always 一旦有对redis的修改就要落盘
②every_sec (bio_fsync_aof)每秒钟进行一次落盘
③no buffer的数据到page cache(见上)

aof-rewrite
fork一份子进程,只保存redis内存当前的状态,根据内存数据状态生成aof文件,避免同一个key的历史冗余。在重写aof期间,对redis所有的写操作记录到重写缓冲区,当重写结束后,附加到aof文件末尾。

rdb

通过fork子进程进行持久化,基于内存中的数据进行持久化。但是缺点是rdb不能看到两次rdb之间数据的修改。
rdb-aof混合持久化
在rdb持久化期间,对redis的写操作记录到重写缓冲区,rdb持久化建立后,附加到aof文件末尾

redis持久化相关配置

在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 #########
# save ""
# save 3600 1
# save 300 100
# save 60 10000

aof

# 开启 aof
appendonly yes
# 关闭 aof复写
auto-aof-rewrite-percentage 0
# 关闭 混合持久化
aof-use-rdb-preamble no
# 关闭 rdb
save ""
# 1. 每条命令刷盘 redis 事务才具备持久性
# appendfsync always
# 2. 每秒刷盘
appendfsync everysec
# 3. 交由系统刷盘
# appendfsync no

aof-fwrite

# 开启 aof
appendonly yes
# 开启 aof复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 关闭 混合持久化
aof-use-rdb-preamble no
# 关闭 rdb
save ""
# 1. redis 记录上次aof复写时的size,如果之后累计超过了原来的size,则会发生aof复写;
auto-aof-rewrite-percentage 100
# 2. 为了避免策略1中,小数据量时产生多次发生aof复写,策略2在满足策略1的前提下需要超过 64mb 才会发生aof复写;
auto-aof-rewrite-min-size 64mb

rdb

# 关闭 aof 同时也关闭了 aof复写
appendonly no
# 关闭 aof复写
auto-aof-rewrite-percentage 0
# 关闭 混合持久化
aof-use-rdb-preamble no
# 开启 rdb 也就是注释 save ""
# save ""
save 3600 1
save 300 100
save 60 10000
# redis 默认策略如下;
# 注意;写了多个 save 策略,只需要满足一个则开启rdb持久化
# 3600 秒内有以1次修改
save 3600 1
# 300 秒内有100次修改
save 300 100
# 60 秒内有10000次修改
save 60 10000

rdb-aof混合持久化

# 开启 aof
appendonly yes
# 开启 aof复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 开启 混合持久化
aof-use-rdb-preamble yes
# 关闭 rdb
save ""

redis持久化方案的优缺点

特性aof (append only file)rdb (redis database snapshot)
优点数据可靠,丢失较少
持久化过程代价较低
rdb 文件小
数据恢复快
缺点aof 文件过大
数据恢复慢
数据丢失较多
持久化过程代价较高(fork子进程实现)

高可用:redis主从复制数据备份+主从切换机制-在几秒钟内得到合理答案

主要用来实现redis数据的可靠性;防止redis所在的磁盘损坏,造成数据永久丢失;
redis主从间采用异步复制的方式;异步复制优点高效,缺点是只能保证最终一致。现代分布式系统都是半数一致性。

#redis.conf
replicaof 127.0.0.1 7002
info replication

主从切换

哨兵模式
只保证一个节点的可用性

redis-cluster集群

多个中心节点对外提供服务。

问题:向其中一个主节点写入数据时,怎么保证数据均衡地落到其他主节点
关注分布式一致性hash
配置redis-cluster集群

https://github.com/0voice

到此这篇关于redis的主从同步与对象模型的文章就介绍到这了,更多相关redis主从同步与对象模型内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!

(0)

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论

验证码:
Copyright © 2017-2026  代码网 保留所有权利. 粤ICP备2024248653号
站长QQ:2386932994 | 联系邮箱:2386932994@qq.com