通俗解释redis高级:redis持久化(RDB持久化、AOF持久化)、redis主从、redis哨兵、redis分片集群

我们把Redis想象成一个超强记忆力、但有时会忘事的"闪电侠"秘书

你的公司(业务系统)所有的重要数据都交给这个"闪电侠"秘书(Redis)来处理,因为他速度极快(内存操作)


1. 持久化:防止"闪电侠"忘事

"闪电侠"记东西都在脑子里(内存),但万一他哪天突然晕倒了(服务器断电/崩溃),脑子里的东西就全忘了。所以需要一种方法,把他脑子里的东西记到本子上(硬盘),这就是持久化

RDB持久化 (Snapshotting - 拍快照)
  • 怎么工作 :就像给"闪电侠"的记忆拍一张完整的照片 (某个时间点的数据全集),存到一个文件里(.rdb文件)。
    • 可以设定规则:比如每隔1小时拍一次,或者写了1000次命令后拍一次。
  • 优点
    • 恢复快:重启后,就像看一张大合影,一下子所有人就位,恢复数据非常快。
    • 文件小:照片是压缩的,文件很小,方便备份和传输。
  • 缺点
    • 可能丢数据:如果上次拍照是1小时前,现在他晕倒了,那这1小时内的新记忆就全丢了。
    • 拍照耗时:数据量很大时,拍照过程会比较慢,可能会短暂影响他处理新命令的速度。

比喻定时给整个公司员工拍集体大合影。恢复时,直接按照合影把人叫回来上班。效率高,但两次拍照之间入职的新员工就丢了。

AOF持久化 (Append-only File - 写日记)
  • 怎么工作 :"闪电侠"准备了一个日记本appendonly.aof文件)。他不拍照片了,而是把你让他做的每一件事(每一条写命令) 都按顺序记下来。
    • SET name Alice -> 记下"记下名字:Alice"
    • SET age 30 -> 记下"记下年龄:30"
  • 优点
    • 数据安全,丢的少:可以配置每秒同步一次日记本(甚至每条命令都同步)。最多丢1秒的数据,非常安全。
  • 缺点
    • 恢复慢 :重启后,他需要拿出日记本,把上面几千条命令重新执行一遍,速度比看照片慢很多。
    • 文件大:日记本会越来越大,记录的都是琐事。

比喻事无巨细地写工作日志。恢复时,需要把日志里所有工作重新做一遍。很安全,但效率低,日志本越来越厚。

通常:两者结合使用,用RDB做冷备份,用AOF保证数据安全。


2. 主从复制:给"闪电侠"配徒弟

"闪电侠"虽然快,但万一他生病了(主节点宕机),公司就停摆了。而且他一个人也忙不过来(读请求压力大)。

  • 怎么工作 :给你厉害的"闪电侠"秘书(主节点/Master )配几个徒弟(从节点/Slave)
    • 徒弟们什么都不用干,就做一件事:实时地、一字不差地抄大师傅脑子里的东西(同步主节点的数据)。
    • 以后,谁来查资料(读请求),都可以让徒弟们去办。
    • 但谁要修改资料(写请求),必须还得找大师傅。
  • 好处
    • 读写分离:大师傅专心处理写操作,徒弟们处理读操作,性能提升。
    • 数据备份:徒弟们都有完整的数据副本,大师傅出事了,还有个备份。
  • 问题 :如果大师傅真出事了,需要手动指定一个徒弟变成新大师傅,这个过程不够自动。

比喻师傅带徒弟,徒弟复制师傅的全部技能(数据)。徒弟可以帮师傅接待客人(读请求),但定规矩(写请求)必须师傅来。


3. 哨兵模式 (Sentinel):给秘书团队配"监工"

主从复制需要手动切换,太麻烦了。于是你请来了几个**"监工"(哨兵进程)**。

  • 怎么工作 :这些监工啥活也不干,就不停地盯着大师傅和徒弟们 是不是还活着(心跳检测)。
    • 如果监工们发现大师傅失联了 (主节点宕机),他们就会自动开会(投票),从徒弟中选举出一个新的师傅,并通知所有其他徒弟和客户端:"以后他就是新老大!写请求都找他!"
  • 好处实现了高可用(High Availability),主节点的故障切换从手动变成了全自动,业务几乎无感知。

比喻人力资源总监(哨兵)盯着团队。一旦经理(主节点)猝死,HR立刻组织投票,提拔一名表现好的员工(从节点)当新经理,并通知全公司。


4. 分片集群 (Cluster):组建一个"闪电侠"军团

公司业务暴增,数据量大的一个"闪电侠"和他的徒弟们都存不下了(单机内存容量瓶颈),而且写请求多到一个大师傅也处理不过来(写性能瓶颈)。

  • 怎么工作
    • 你不再依赖一个"闪电侠",而是请来了多个"闪电侠"小组,每个小组独立工作(每个节点都是主节点,存储一部分数据)。
    • 你制定一个规则(一致性哈希算法 ):比如,数据以关键字分片,用户A的数据存在1组用户B的数据存在2组
    • 每个小组也可以有自己的徒弟(从节点)和监工(哨兵)。
  • 好处
    • 海量数据存储:数据分散在多个节点上,突破了单机内存限制。
    • 高性能读写:写请求也被分散到不同的主节点上,提升了整体并发处理能力。
    • 高可用:每个小组内部依然通过主从+哨兵模式来保证可用性。

比喻公司做大后,按业务线分成了几个事业部(分片),每个事业部有自己的经理和员工(主从节点),独立运营又能相互协作。CEO(客户端)通过一套规则(Cluster协议)知道什么事该找哪个事业部。

总结

技术 通俗比喻 解决的核心问题
RDB持久化 拍集体照 快速备份/恢复,但可能丢数据
AOF持久化 写工作日志 数据安全,丢数据少,但恢复慢
主从复制 师傅带徒弟 数据备份读写分离
哨兵模式 HR监工 高可用自动故障转移
分片集群 分事业部 海量数据存储高并发读写

这些高级特性让Redis从一个简单的"快"缓存,进化成了一个功能完善、稳定可靠的高性能内存数据系统

相关推荐
海梨花1 小时前
【从零开始学习RabbitMQ】
分布式·学习·rabbitmq
代码不停1 小时前
计算机工作原理(简单介绍)
数据库·redis·缓存
失散134 小时前
分布式专题——26 BIO、NIO编程与直接内存、零拷贝深入辨析
java·分布式·rpc·架构·nio·零拷贝
计算机编程小央姐4 小时前
大数据工程师认证项目:汽车之家数据分析系统,Hadoop分布式存储+Spark计算引擎
大数据·hadoop·分布式·数据分析·spark·汽车·课程设计
祈祷苍天赐我java之术4 小时前
Redis 热点数据与冷数据解析
java·redis·mybatis
the beard6 小时前
Redis Zset的底层秘密:跳表(Skip List)的精妙设计
数据库·redis·list
C++chaofan7 小时前
Redisson分布式限流
java·jvm·spring boot·redis·分布式·mvc·redisson
元气满满的霄霄8 小时前
Spring Boot整合缓存——Redis缓存!超详细!
java·spring boot·redis·后端·缓存·intellij-idea
gsfl10 小时前
Redis 缓存
数据库·redis·缓存
月夕·花晨11 小时前
Gateway-过滤器
java·分布式·spring·spring cloud·微服务·gateway·sentinel