Redis常用进阶 存储原理和主从思路

最新推荐文章于 2025-07-27 02:05:06 发布
原创 最新推荐文章于 2025-07-27 02:05:06 发布 · 1.2k 阅读 · 30 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #数据库 #缓存

Redis常用进阶 存储原理和主从思路

简介

此篇用于需要时随时查阅的知识. 由于不断的学习总是会忘记一些 所以用于记录

笔记对应视频为黑马redis

https://www.bilibili.com/video/BV1Pu411Y7bq

单点redis的问题 :

  1. 数据丢失问题 持久化
  2. 并发能力弱 主从集群
  3. 存储能力问题 ES
  4. 故障恢复问题 哨兵 健康监测 恢复 (此类不做了解)

所有例子采用的是win10的redis linux其实同理 环境搭建比较费事主要用于记录解决方案

使用的redis版本 Redis-6.0.17-Windows-x64

存储机制

RDB

RDB 全程为redis database backupfile 就是使用线程将内存中的数据记录到磁盘中 当做redis案例故障重启后 从磁盘读取的快照文件 用于恢复数据 默认是保存在当前目录

save 使用主进程执行RDB

bgsave是使用子线程执行rdb

当redis主线程停止的时候 会默认的执行一次RDB

image-20250319172453868

默认情况下 redis只有在结束主线程之前才会执行一次rdb 但是如果出现宕机数据就会出现丢失

image-20250319174724222

配置定时RDB

我们可以通过配置文件的配置项 来设置多少时间内有多少数据变动来触发rdb

这是redis的默认出发设置

image-20250319172809753

我们也可以通过 dir来设置文件存储的位置 不推荐开启压缩 因为cpu资源更加宝贵

image-20250319174740420

bgsave

开始的时候会fork主进程到子进程 子进程共享内存数据 完成之后读取内存数据到RDB文件

image-20250319174905955

RDB缺点
  • RDB执行时间长 可能存在数据丢失风险
  • 子进程压缩和写出比较耗时

AOF

Append Only File Redis处理的每一个写命令都会记录在AOF文件中 可以当做命令日志文件,如果redis出现了故障 恢复的时候就读取日志文件恢复

AOF默认是关闭的 我们需要去配置打开

image-20250319175205840

aof 有三种频率 自上向下

  • 每执行一次就存
  • 写命令执行完先放入缓冲区 一秒一秒的写入 最多丢失1秒的数据
  • 执行完命令直接放入缓冲区 由系统决定什么时候写到磁盘

image-20250319175242959

性能对比:

image-20250319175411717

使用

image-20250319180112076

image-20250319180136855

AOF文件的缺点

AOF占用的硬盘体积会比RDB大很多很多 因为AOF记录的是写命令 如果修改的key重复那么会多出很多无意义的记录

可以通过 执行 bgrewriteaof命令来让AOF执行重写功能 用最少的命令达到相同的记录效果

image-20250319180435225

虽然变成了乱码 但是可以从一些片面的信息看到我们的key和一些值

redis给我们提供了配置 可以设置 AOF文件大于一定体积的时候就执行一次bgrewriteaof命令来最大限度的提升使用效率 分别是

  • 根据上次文件的体积
  • 根据固定的大小

image-20250319180717849

对比

image-20250319180803045

主从架构

主从架构是用来提升redis的并发上限的 主从之间会同步数据来达到承载更多数据压力的效果, 主节点来执行写操作 从节点来执行读操作就可以提升上限

这次根据教程的例子 我们搭建一主二从

  • 7001 master
  • 7002 slave
  • 7003 slave

架构搭建

恢复配置 关闭 aof 开启 rdb 创建三个文件夹 每一个redis实例都需要自己的配置文件

创建完毕后将 redis.conf复制到每一个目录 然后修改端口号

我们配置主从可以使用 replicaof或者slaveof命令 来使用

也可以使用配置文件的方式来完成主从绑定

启动所有实例

image-20250319182147939

配置主从的命令如下:

SLAVEOF 主节点的ip 主节点的端口

image-20250319182415962

这样主从的配置就配置好了 , 我们可以使用 INFO REPLICATION命令来查看主从信息

image-20250319182558308

我们在主节点写入 所有的从节点都可以查询到数据

数据同步原理

主从数据的第一次同步 是全量的同步 ,交流信息校验过程如下:

而主从之间的同步需要使用 RDB 文件这也是为什么配置架构的时候我们需要打开RDB

image-20250319182912396

master持有数据集id这个id具有唯一性 对应着一个数据集 所有slave都回去继承这个repid,

主机通过偏移量来确认主从同步的数据是否一致 ,所以slave同步时需要将repid和偏移量体提交给master来判断数据的同步容量,

主从之间的增量同步 : 如果主从之间的断开时间太多 slave和master差距太大 就只能全量同步了,如果没有超出设定的范围则根据偏移量来完成增量同步

image-20250319183548540

数据同步优化原理

  • 在主节点中配置启用无磁盘复制 REPL-DISKLESS-SYNC 避免全量同步时磁盘io的占用 尽可能减少全量同步
  • 我们可以适当的提高 repl-baklog的大小 增加缓冲区 及时的恢复宕机的slave
  • 如果主节点压力太大 slave太多 可以采用链式的方法来降低各个主节点的压力
滚雪球学Redis[4.2讲]：Redis Sentinel 深度解析：工作原理、配置与高可用架构下的故障转移
**My Coding Family**
10-14 1320
然而，单纯依靠主从复制并不能完全消除故障带来的风险，尤其是在主节点宕机或网络分区时，如何确保服务的持续可用性就成为一个亟待解决的问题。Sentinel不仅监控Redis实例的状态，还可以在主节点出现故障时，自动进行故障转移，从而保证系统的高可用性。：一旦确认主节点宕机，Sentinel会选择一个从节点提升为新的主节点，并修改其配置，指示其他从节点重新复制新的主节点的数据。在应用程序中，使用支持Sentinel的Redis客户端库，可以自动处理主节点和从节点的变化，确保连接的高可用性。
数据库之Redis运维手册（私人整理）
企业实战系列集 ●●● https://ximenjianxue.blog.youkuaiyun.com
11-20 8016
1、redis配置文件 #cat 8000.conf daemonize no #[yes/no]默认值no，该参数用于定制redis服务是否以守护模式运行。 pidfile /var/run/redis.pid #默认值/var/run/redis.pid，指定redis服务的进程号文件路径，以守护模式运行时需要配置本参数； port 8000 #默认值6379，指定redis服务...
104. Python语言 的 项目前导(上) 之 Redis 第五章 ：Redis 持久化 —— AOF
sinat_38761218的博客
11-10 595
Python语言 的 项目前导(上) 之 Redis 第章 ：Redis
Redis - 原理篇
十二间记，知不足而奋斗，望远山而前行。千里不辞行路远，时光早晚到天涯。
06-01 3768
Redis原理篇：Redis五种数据结构、网络模型、网络协议、内存策略：内存key过期、内存淘汰
[Redis 系列]redis 学习 17，redis 存储结构原理 1
m0_37322399的博客
07-08 487
关于 redis 相信大家都不陌生了，之前有从 0 -1 分享过 redis 的基本使用方式，用起来倒是都没有啥问题了，不过还是那句话，会应用之后，我们必须要究其原理，知其然知其所以然今天我们来分享一下关于 redis 的存储结构的原理我们都知道 redis 是一个 K-V 内存数据库，类似于 memcache ，那么一般存储这种 K-V 键值对的数据结构是什么呢？是 红黑树 ， 那么我们对于红黑树的增删改查的时间复杂度是 O(logN)，对于红黑树而言，只要内存足够，那么这个 N 是可以无限大的这对于 r
最全Redis原理
qq_49264501的博客
03-19 3216
Redis
Redis存储原理
oxygen3000的博客
09-18 1744
我们知道，通过链表组织就是一种应对hash冲突的策略，hash冲突会使索引效率降低，然鹅从源码可以看到有一个负载因子，也就是已有元素与数组长度之比（used/size），负载因子越大表示hash冲突就越大，而我们知道hash时间复杂度是O(1)，hash冲突到后面会使时间复杂度增加到O(n)。当负载因子大于1的时候就要进行扩容操作，也就是将数组长度翻倍，增大分母减小负载因子。而当负载因子小于0.1（恰好大于used的2^n）的时候就要进行缩容，因为这是占着茅坑不拉屎，浪费空间。不管扩容还是缩容，数组长度都会
redis进阶--IDEA环境
m0_69468924的博客
05-06 2219
redis进阶--IDEA环境
【redis进阶】哨兵 (Sentinel)
qq_52842680的博客
01-26 1918
Redis 的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工进行主从切换，同时大量的客户端需要被通知切换到新的主节点上，对于上了一定规模的应用来说，这种方案是无法接受的，于是Redis 从 2.8 开始提供了 Redis Sentinel（哨兵）来解决这个问题。Redis Sentinel 的概念Redis Sentinel 的部署Redis Sentinel 命令Redis Sentinel 客户端Redis Sentinel 实现原理一、基本概念。
Redis核心知识点深度剖析：原理、机制与应用
禅与计算机程序设计的艺术
12-14 1833
C语言的字符串用\0收尾，在redis的使用场景下，很可能因为这个结束符导致数据被截断。C语言字符串获取长度需要进行遍历，即O(n)级别的时间复杂度。C语言进行字符串拼接总是需要预先做好分配，否则很容易出现缓冲区溢出的问题。对于不断扩大的字符串还需要反复创建新的字符数组解决问题。用于表示地理坐标信息，从而实现经纬度数据检索，它主要支持的命令有：Redis 的 GEO 模块提供了一系列用于处理地理位置数据的命令。
Redis的存储原理和数据模型
记录一位C++爱好者的笔记
09-12 1672
首先我们需要了解一下单线程的局限性：如果在单线程中碰到了一些耗时操作，比如cpu的大量计算和阻塞等待的io处理，那么整个线程就会被阻塞等待，大大降低效率，这样对Redis而言就会影响性能。那么针对这些问题，Redis有没有相关的处理方式，比如io密集型，cpu密集型。
Redis 实现原理或机制
Flying_Fish_roe的博客
09-07 2166
Redis 的高性能、高可用性和灵活性来自其精巧的实现原理和机制。通过高效的内存管理、灵活的数据结构、强大的持久化机制、主从复制和集群功能，Redis 能够满足各种复杂的应用场景需求。无论是在缓存、会话管理、还是分布式存储领域，Redis 都能够提供卓越的性能和稳定性。
深入解析 Redis 原理：架构、数据结构与高效存储
whl 博客专栏
03-20 2643
Redis 是一款高性能的内存键值数据库，以其单线程 + 多路复用的架构，实现了极高的吞吐量。本文深入解析 Redis 的核心原理，包括数据结构（如 SDS、跳表、哈希表等）、持久化机制（RDB 快照与 AOF 日志）、高并发优化（惰性删除、定期删除）及分布式架构（主从复制、Sentinel、Cluster）。通过合理的缓存策略和数据结构选择，Redis 在高并发系统中表现卓越，为大规模应用提供可靠的存储与加速方案。
redis 存储原理与数据模型
Ricardo2的博客
07-29 1709
然而，如果直接使用KEYS命令获取所有键，会对性能产生严重影响，因为KEYS命令会阻塞其他操作，并且在数据集较大时，返回所有键也会消耗大量内存。经过证明，当数据量足够大（256）时，通过概率构造的跳表趋向于理想跳表，并且此时如果删除节点，无需重构跳表结构，此时依然趋向于理想跳表。在 redis 实例中形成了很大的对象，比如一个很大的 hash 或很大的 zset，这样的对象在扩容的时候，会一次性申请更大的一块内存，这会导致卡顿；redis的EXPIRE机制用于设置键的过期时间，即在指定时间后自动删除键。
Redis中的基本数据类型及其存储原理
香烟，瓜子，矿泉水
11-11 1958
前言 redis是一种常见的NOSQL数据库，它支持五种数据类型：String字符串，Hash哈希，List列表，Set集合及ZSet有序集合，今天我们来讲讲它们的用法以及存储原理 基本数据类型 String字符串 主要用来存储字符串、整数、浮点数 操作命令 插入一个值 set test 1 批量插入 mset tom 2 jack 6 获取值 get test 批量获取 mget tom jack 加锁插入，如果 key 存在，则不成功。可用于分布式锁，可通过del key释放锁 setnx t
Redis存储原理与数据模型
m0_49540285的博客
04-24 1645
所以大概 率会发生冲突；常说 redis 是单线程的，指的是 redis 处理命令的线程只有一个，而整个 redis 进程是存在多个线程的，包括 i/o耗时和cpu耗时开启的多个子线程。当 hashtable 中的元素过多的时候，不能一次性 rehash 到 ht[1] ，这样会长期占用 redis，其他 命令得不到响应，所以需要使用渐进式 rehash；redis 的命令处理是单线程的主线程，通过处理命令的主线程将需要处理的任务放到任务队列中，由调度器下发到子线程进程处理，并返回结果给主线程。
Redis 数据存储原理
qq_38470315的博客
04-24 567
核心模块如图 1-10。图1-10图 1-10Client 客户端，官方提供了 C 语言开发的客户端，可以发送命令，性能分析和测试等。网络层事件驱动模型，基于 I/O 多路复用，封装了一个短小精悍的高性能 ae 库，全称是。在 ae 这个库里面，我通过aeApiState结构体对四种 I/O 多路复用的实现进行适配，让上层调用方感知不到在不同操作系统实现 I/O 多路复用的差异。Redis 中的事件可以分两大类：一类是网络连接、读、写事件；
【Redis】Redis 数据存储原理和结构
Antonio915的博客
07-27 1103
Redis底层采用字典(dict)作为核心存储结构，通过哈希表实现高效键值存取。字典由哈希表节点(dictEntry)、哈希表(dictht)和顶层字典结构(dict)组成，采用链地址法处理哈希冲突。其核心特性包括：1)使用位运算优化索引映射；2)渐进式重哈希机制，在扩容/缩容时避免性能抖动；3)哈希表节点形成单向链表解决冲突。Redis针对不同数据类型(如String/Hash/List)采用差异化编码策略，根据数据量大小在内存效率与访问速度间取得平衡，如小数据量使用ziplist/intset，大数据量
Redis基本原理
tom的博客
03-07 2612
一.Redis 简介 Redis 是一款基于 ANSI C 语言编写的，BSD 许可的，日志型 key-value 存储组件，它的所有数据结构都存在内存中，可以用作缓存、数据库和消息中间件。 Redis 是远程字典服务的缩写，一个 Redis 实例可以有多个存储数据的字典，客户端可以通过 select 来选择字典即 DB 进行数据存储。 二.Redis 特性 同为 key-value 存储组件，Memcached 只能支持二进制字节块这一种数据类型。而 Redis 的数据类型却丰富的多，它具有 8
Redis高级进阶学习知识
最新发布
08-29
<think> 嗯，用户明确提出了想获取Redis高级进阶学习的相关知识。从用户引用的多个资料片段来看，用户应该已经掌握了Redis的基础知识，现在希望向更深入的领域探索。 用户引用的资料[1]特别提到了一份涵盖原理、集群、应用、拓展、源码五个方面的Redis高级笔记，这正好符合用户当前的需求阶段。资料[2]也验证了这个知识框架的完整性。而资料[3]提到的数据类型深度解析和优化方法，资料[5]涉及的持久化配置细节，都是进阶学习的关键内容。 考虑到用户可能的发展方向，需要覆盖以下几个方面：首先是底层原理，包括内存管理、线程模型等；其次是集群方案，特别是分布式场景下的解决方案；然后是实战优化，如何提升Redis在生产环境中的表现；最后是源码层面，为深度定制做准备。 在组织回复时，应该突出知识体系的层次性。把最核心的原理放在第一部分，因为这是理解后续内容的基础。集群方案要强调主从复制和分片的区别，这是很多开发者容易混淆的点。优化部分需要给出具体可操作的技巧，比如连接池配置和慢查询分析方法。源码学习路径要降低用户的学习门槛，建议从核心数据结构开始。 用户提到"面试跟日常开发肯定够用"，说明可能有职业发展需求，所以补充了面试加分项这个实用模块。同时注意到资料[4]提到面试官会随机考察知识广度，因此在集群方案中特意加入了Codis等生态工具的介绍。 最后用资料[1]的"原来Redis还能这么玩"作为结尾呼应，保持轻松专业的语气。相关问题设计覆盖了用户可能继续探索的方向，特别是源码和性能优化这类深度话题。 </think> 以下是Redis高级进阶学习的核心知识体系，结合权威资料整理为系统化框架，助你全面提升Redis实战与原理理解： --- ### **一、底层原理深度解析** [^1][^2] 1. **内存管理机制** - 动态字符串(SDS)设计与优势 - 字典(rehash)渐进式迁移策略 - 跳表(zskiplist)实现有序集合 - 内存碎片优化方案 2. **多线程模型演进** - Redis 6.0+多线程IO原理 - 单线程命令处理的原子性保障 - 后台线程处理过期键和AOF ```c // SDS结构示例（源码简化版） struct sdshdr { int len; // 实际字符串长度 int free; // 剩余空间 char buf[]; // 字节数组 }; ``` --- ### **二、高可用集群架构** [^1][^2] | **方案** | **核心机制** | **适用场景** | |----------------|------------------------------|-------------------------| | 主从复制 | 全量同步+增量同步 | 读写分离基础架构 | | Redis Sentinel | 哨兵选举、故障自动转移 | 高可用监控解决方案 | | Redis Cluster | 虚拟槽分区(16384 slots) | 分布式横向扩展 | | Codis | Proxy层分片方案 | 大规模集群迁移过渡方案 | --- ### **三、性能优化实战** [^3][^5] 1. **持久化调优** - RBD配置策略：`save 900 1` vs `save 60 10000` - AOF重写优化：`auto-aof-rewrite-percentage 100` - 混合持久化：`aof-use-rdb-preamble yes` 2. **高并发陷阱规避** - Pipeline批量操作减少RTT - 连接池配置：`maxTotal`与`maxIdle`比例 - 慢查询监控：`slowlog-log-slower-than 10000` --- ### **四、源码级深度探索** [^1][^2] 1. **学习路径建议：** - ① 事件驱动框架：`aeEventLoop` - ② 数据结构实现：`dict.c` / `ziplist.c` - ③ 网络通信模型：`networking.c` 2. **调试技巧：** ```bash # GDB调试Redis实例 gdb --args ./src/redis-server redis.conf break processCommand ``` --- ### **五、应用场景进阶** [^3][^4] 1. **分布式锁方案** - Redlock算法实现与争议 - SETNX + Lua原子释放 2. **二级索引构建** - 利用ZSet实现多维度排序 - GEO模块实现地理位置查询 3. **流处理系统** - Stream数据结构实现消息队列 - 消费者组(Consumer Group)负载均衡 --- ### **六、面试深度考点** [^4] ```markdown 高频问题示例： 1. Redis事务与MySQL事务的本质区别？ 2. 缓存雪崩/穿透/击穿解决方案对比 3. 集群脑裂(Split-Brain)的产生与预防 4. Redis7新特性（Function API、ACL增强） ``` > 资料建议：结合《Redis设计与实现》+ Redis官方源码注释学习[^1][^3]，实战推荐通过`redis-benchmark`压测不同配置的性能差异[^5]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

冷环渊

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值