Redis淘汰策略、持久化、主从同步与对象模型

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
日志服务 SLS,月写入数据量 50GB 1个月
简介: Redis淘汰策略、持久化、主从同步与对象模型

淘汰策略

Redis是内存数据库,内存是稀缺资源。内存有限的情况下,如果使用额度已满,还继续往里面写入新数据的话,就需要淘汰掉一些占据内存的数据。

如果使用了expire或者pexpire指令设置key的过期时间,那么淘汰策略一般优先选择淘汰过期key的策略。存储key-value的结构体(struct redisObject)中有一个属性,LRU_BITS,大小为24位,一般存储着过期时间、使用次数等属性,其中有8位存储着使用次数,最大可计数到256次。

Redis.conf文件中与淘汰策略相关的设置:

  1. maxmemory,redis最大可使用的内存。
  2. maxmemory-policy,淘汰策略,默认是noeviction。
  3. maxmemory-samples,淘汰策略的采样方式。

其中,可选的淘汰策略如下,思维导图的一个末端代表了一种淘汰策略,例如第一个末端volatile-lru代表从过期key中淘汰最长时间没有使用的key,allkeys-lru末端代表从所有key中淘汰最长时间没有使用的key。

持久化

Redis作为一个内存数据库,一旦关闭,内存就会丢失。把数据载入到磁盘中,就是在实现持久化。

持久化的方式可基于AOF,RDB和混合使用。

AOF

append of file。将所有写操作记录追加到文件的末尾,redis重启的时候就把所有的写操作执行一遍进行数据恢复。该方法会产生大量的冗余数据。

AOF的always方法:redis每次写操作都先把操作记录持久化进入磁盘,再将执行结果返回给用户,是一种同步策略,在主线程中进行操作。

#Conf文件修改:
appendonly yes
appendfilename "appendonly.aof"
appendfsync always

AOF的every sec方法:先把写操作的记录写入一块缓存中,另起一个线程每秒钟把缓存刷入磁盘中,是一种异步策略。

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

流程:操作记录被写入aof_buf➡调用write函数把记录从aof_buf刷入内核的page cache(内核高速缓冲区)➡调用fsync函数把数据从page cache刷入磁盘。

AOF的方式,其实就对应着调用操作流程的调用方式。

注意:如果机器断电了,可能会造成内存丢失。但如果只是进程退出,会调用close函数,自动刷内存。

RDB

Redis Database,将内存中的数据以快照的形式保存到磁盘上的二进制文件中,实现数据的持久化。如何实现内存快照?fork一个子进程,由这个子进程把快照到的数据存入磁盘中。

进程把数据存储于虚拟内存当中,虚拟内存通过页表映射到物理内存上。

RDB的写时复制过程:

  1. fork一个子进程。
  2. 子进程复制了父进程的页表,映射到同一块物理内存。
  3. 子进程和父进程的页表的标记位都被设置为只读。
  4. 父进程依然对外提供服务,当有新的操作产生的时候,系统会为父进程复制一块新的物理内存,重新构建映射关系。
#Conf文件修改:
save 300 10 
#表示300s内如果由10个key被修改那么就储存一次。

Aof-rewrite

在 aof 的基础上,满足一定策略则 fork 进程,根据当前内存状态,转换成一系列的 redis 命令,序列化成一个新的 aof 日志文件中,序列化完毕后再将操作期间发生的增量 aof

日志追加到新的 aof 日志文件中,追加完毕后替换旧的 aof 日志文件;以此达到对 aof 日志瘦身的目的;

Rdb-aof混用

通过fork子进程,根据内存数据生成rdb文件。在rdb持久化期间,对redis的写操作会记录到重写缓冲区,当rdb持久化结束,附加到aof文件末尾。

持久化策略优缺点对比

大key

大key指的是value很大的key,一般是有很多项目的hash或者zset。一般会加大fsync的时候和写时复制的压力。

Redis的高可用设置

高可用:Redis可以在合理的时间给前台合理的回复。

实现高可用的关键:1、要有数据备份。2、当主节点宕机要能进行节点切换。

高可用设置目的:在某个redis节点发生宕机之后,依然可以在合理的时间给前台合理的回复。

数据备份

主从复制

主redis数据库发生数据变更的时候,要复制到从redis节点中。

同步复制:每次操作主redis的时候,都要先复制到从redis中,再给前台返回结果,缺点是速度慢。

异步复制:每次操作主redis的时候,操作成功直接返回,从redis在后台自行拉取数据。缺点是从redis 的数据可能与主redis不一致,从redis的数据可能不是最新的。

主从数据库的主被动关系

从数据库主动向主数据库建立连接。因为主从复制支持从数据库任意时间复制主数据库,主动权交给从数据库才能实现。

从数据库主动从主数据库拉数据。从数据库需要可以自由地选择获取主数据库的哪部分数据,以及如果主从断连,从数据库重连后可以续上复制。

全量复制与增量复制

主数据库一般有一个环形缓冲区,存储着数据,从数据库持有一个复制偏移量。复制偏移量代表了从数据库复制到的范围,如果和主数据库环形缓冲区的偏移量有差别,说明差别对应的部分说明还没复制到。

如果复制偏移量在环形缓冲区当前的偏移量的值的范围当中,说明增量数据没有覆盖住环形缓冲区一圈,可以进行增量更新。

如果复制偏移量不在环形缓冲区当前的偏移量的值的范围当中,说明增量数据已经覆盖住环形缓冲区一圈,可以进行全量更新。

节点切换

哨兵模式

哨兵集群:不存储数据,仅仅用于监控主节点是否宕机,监控哪个从节点的数据更新。如果发生了宕机,通知client和新的从redis建立连接。

哨兵模式是 Redis 可用性的解决方案;它由一个或多个 sentinel实例构成 sentinel 系统;该系统可以监视任意多个主库以及这些主库所属的从库;当主库处于下线状态,自动将该主库所属的某个从库升级为新的主库;

客户端来连接集群时,会首先连接 sentinel,通过 sentinel 来查询主节点的地址,然后再连接主节点进行数据交互,同时通过subscribe监听来自sentinel的信息。当主节点发生故障时, sentinel会将最新的主库地址告诉客户端。通过这样客户端无须重启即可自动完成节点切换

哨兵模式因为过于复杂、部署麻烦,并且不能解决扩容、及时性等问题,实务中很少使用它来解决高可用方案。

Redis cluster集群

以上图为例介绍cluster集群的特征:

  1. 去中心化:如图所示,有3个主节点,而不是只有1个中心节点。可以通过任意节点的端口(包括从节点)去读取数据。
  2. 主节点对等:主节点的关系是对等的,如果给其中一个节点写入数据,另外两个主节点是不会发生变化的。
  3. 主从切换:如果两个主节点判断另外一个节点发生了宕机,那么另一个主节点的从节点会顶上成为新的主节点。
  4. 解决了数据扩容问题:一个主节点满了之后可以向增加新的主节点写入新数据。

Redis cluster集群的实现

1、创建文件夹

# 创建 6 个文件夹
mkdir -p 7001 7002 7003 7004 7005 7006
cd 7001
vi 7001.conf
# 7001.conf 中的内容如下

2、编辑 7001.conf

注意路径是否需要修改

pidfile "/home/mark/redis-data/7001/7001.pid"
logfile "/home/mark/redis-data/7001/7001.log"
dir /home/mark/redis-data/7001/
port 7001
daemonize yes
cluster-enabled yes
cluster-config-file nodes-7001.conf
cluster-node-timeout 15000

3、复制配置

cp 7001/7001.conf 7002/7002.conf
cp 7001/7001.conf 7003/7003.conf
cp 7001/7001.conf 7004/7004.conf
cp 7001/7001.conf 7005/7005.conf
cp 7001/7001.conf 7006/7006.conf

4、修改配置

sed -i 's/7001/7002/g' 7002/7002.conf
sed -i 's/7001/7003/g' 7003/7003.conf
sed -i 's/7001/7004/g' 7004/7004.conf
sed -i 's/7001/7005/g' 7005/7005.conf
sed -i 's/7001/7006/g' 7006/7006.conf

5、创建启动配置

#!/bin/bash
redis-server 7001/7001.conf
redis-server 7002/7002.conf
redis-server 7003/7003.conf
redis-server 7004/7004.conf
redis-server 7005/7005.conf
redis-server 7006/7006.conf

6、智能创建集群

redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 --cluster-replicas 1

7、集群创建结果

如果创建了3个主节点,3个从节点,其中7004是7001的从节点,以此类推。

slots是给各个主节点设置的,举例:当有一个新的key被set的时候,redis会对这个key做一个hash,得到的hash值会对3取余,得到0-16383范围内的值,根据这个值找到对应的槽位,把数据存入相应的节点中。目的是为了负载均衡,让各个节点承受的压力一致。

8、设置获取值

redis-cli -c -p 7001
set name mark

注意虽然是往7001里set key,但是可能会被重定向到其他节点上。如果要get key,可以从任意节点get key,包括从节点。

目录
相关文章
|
1月前
|
NoSQL 算法 Redis
【Docker】(3)学习Docker中 镜像与容器数据卷、映射关系!手把手带你安装 MySql主从同步 和 Redis三主三从集群!并且进行主从切换与扩容操作,还有分析 哈希分区 等知识点!
Union文件系统(UnionFS)是一种**分层、轻量级并且高性能的文件系统**,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem) Union 文件系统是 Docker 镜像的基础。 镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。
290 5
|
2月前
|
存储 缓存 NoSQL
工作 10 年!Redis 内存淘汰策略 LRU 和传统 LRU 差异,还傻傻分不清
小富带你深入解析Redis内存淘汰机制:LRU与LFU算法原理、实现方式及核心区别。揭秘Redis为何采用“近似LRU”,LFU如何解决频率老化问题,并结合实际场景教你如何选择合适策略,提升缓存命中率。
339 3
|
3月前
|
存储 缓存 人工智能
Redis六大常见命令详解:从set/get到过期策略的全方位解析
本文将通过结构化学习路径,帮助读者实现从命令语法掌握到工程化实践落地的能力跃迁,系统性提升 Redis 技术栈的应用水平。
|
3月前
|
存储 NoSQL 算法
应对Redis中的并发冲突:有效解决策略
以上策略各有优劣:乐观锁和悲观锁控制得当时可以很好地解决并发问题;发布/订阅模式提高了实时响应能力;Lua脚本和Redis事务保证了命令序列的原子性;分布式锁适合跨节点的并发控制;限流措施和持久化配置从系统设计层面减少并发风险;数据分片通过架构上的优化减轻单个Redis节点的负担。正确选择适合自己应用场景的策略,是解决Redis并发冲突的关键。
276 0
|
5月前
|
存储 监控 NoSQL
流量洪峰应对术:Redis持久化策略与内存压测避坑指南
本文深入解析Redis持久化策略与内存优化技巧,涵盖RDB快照机制、AOF重写原理及混合持久化实践。通过实测数据揭示bgsave内存翻倍风险、Hash结构内存节省方案,并提供高并发场景下的主从复制冲突解决策略。结合压测工具链构建与故障恢复演练,总结出生产环境最佳实践清单。
172 9
|
5月前
|
消息中间件 监控 NoSQL
利用RabbitMQ与Redis实现消息的延迟传递的策略
这个系统就如同一个无懈可击的邮局,无论天气如何变换,它都能确保每一封信准时送达。通过巧妙地运用RabbitMQ的DLX和Redis的Sorted Sets,我们搭建了一座桥梁,让即时和延迟消息的传递高效且无缝对接。
92 3
|
8月前
|
NoSQL 数据库 Redis
什么是 Redis 主从同步?
Redis 的主从同步(replication)机制,允许 Slave 从 Master 那里,通过网络传输拷贝到完整的数据备份,从而达到主从机制。 主数据库可以进行读写操作,当发生写操作的时候自动将数据同步到从数据库,而从数据库一般是只读的,并接收主数据库同步过来的数据。一个主数据库可以有多个从数据库,而一个从数据库只能有一个主数据库。 主从数据同步主要分二个阶段 : 第一阶段 : 全量复制阶段 ● slave节点请求增量同步 ● master节点判断replid,发现不一致,拒绝增量同步 ● master将完整内存数据生成RDB,发送RDB到slave ● slave清空本地数据,加载m
|
8月前
|
NoSQL Redis
Redis的数据淘汰策略有哪些 ?
Redis 提供 8 种数据淘汰策略: 淘汰易失数据(具有过期时间的数据) 1. volatile-lru(least recently used):从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰 2. volatile-lfu(least frequently used):从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰 3. volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰 4. volatile-random:从已设置过期
|
8月前
|
NoSQL Redis
Redis的数据持久化策略有哪些 ?
Redis 提供了两种方式,实现数据的持久化到硬盘。 1. RDB 持久化(全量),是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 2. AOF持久化(增量),以日志的形式记录服务器所处理的每一个写、删除操作 RDB和AOF一起使用, 在Redis4.0版本支持混合持久化方式 ( 设置 aof-use-rdb-preamble yes )
|
8月前
|
缓存 NoSQL 中间件
Redis的线程模型
Redis采用单线程模型确保操作的原子性,每次只执行一个操作,避免并发冲突。它通过MULTI/EXEC事务机制、Lua脚本和复合指令(如MSET、GETSET等)保证多个操作要么全成功,要么全失败,确保数据一致性。Redis事务在EXEC前失败则不执行任何操作,EXEC后失败不影响其他操作。Pipeline虽高效但不具备原子性,适合非热点时段的数据调整。Redis 7引入Function功能,支持函数复用,简化复杂业务逻辑。总结来说,Redis的单线程模型简单高效,适用于高并发场景,但仍需合理选择指令执行方式以发挥其性能优势。
211 6