当前位置：首页 > news >正文

通俗解释redis高级：redis持久化（RDB持久化、AOF持久化）、redis主从、redis哨兵、redis分片集群

news 2025/9/14 6:58:19

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

你的公司（业务系统）所有的重要数据都交给这个“闪电侠”秘书（Redis）来处理，因为他速度极快（内存操作）。

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

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

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

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

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

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

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

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

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

主从复制需要手动切换，太麻烦了。于是你请来了几个**“监工”（哨兵进程）**。

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

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

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

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

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