redis详解2

5.redis的持久性

redis是内存数据库,如果不讲内存中的数据保存到磁盘中,那么一旦服务进程退出,服务器中的数据状态也会消失,所以rdis提供了持久化的功能。

一、什么是 Redis 持久化?

Redis 是 内存数据库断电数据就没了 。持久化就是:把内存里的数据保存到硬盘上,让数据可以长久保存,重启不丢失。


二、Redis 有两种持久化方式

1)RDB(快照)

2)AOF(日志)


三、RDB 详解(Redis DataBase)

是什么?

定时把内存数据拍成一张 "快照",保存到 dump.rdb 文件。

触发规则(redis.conf)

复制代码
save 900 1      // 900秒内至少改了1个key → 拍快照
save 300 10     // 300秒内改了10个 → 拍
save 60  10000  // 60秒内改了10000个 → 拍

原理

  • fork 子进程

  • 把数据写入临时文件

  • 写完替换旧的 dump.rdb

  • 主进程不阻塞,继续处理请求

优点

  • 恢复极快

  • 文件小,适合大规模数据恢复

  • 对性能影响小

缺点

  • 可能丢数据(最后一次快照之后的数据会丢)

四、AOF 详解(Append Only File)

是什么?

记录每一条 "写命令",保存到 appendonly.aof。 重启时把命令重新执行一遍恢复数据。

三种刷盘策略

复制代码
appendfsync always    // 每次修改都同步 → 最安全,最慢
appendfsync everysec  // 每秒同步一次 → 推荐!
appendfsync no        // 让系统自己决定 → 最快,最不安全

优点

  • 数据几乎不丢失

  • 日志只追加,写入稳定

缺点

  • 文件比 RDB 大很多

  • 恢复速度 比 RDB 慢

  • 对性能影响略大

6.redis发布订阅

概念

Redis 发布订阅是一种消息通信模式,包含三个角色:发布者、频道、订阅者。发布者向指定频道发送消息,所有订阅了该频道的客户端都能实时接收到消息,属于一对多的消息广播机制。它不负责消息存储,消息发出后若订阅者不在线则无法收到,也不保证消息可靠性。

核心命令

  1. 订阅频道 SUBSCRIBE channel1 channel2 ...:客户端订阅一个或多个频道,进入监听状态,等待接收消息。
  2. 发布消息 PUBLISH channel message:发布者向指定频道发送消息,所有订阅该频道的客户端都会收到。
  3. 模式订阅 PSUBSCRIBE pattern:按通配符模式订阅频道,比如PSUBSCRIBE news*可订阅所有以 news 开头的频道。
  4. 取消订阅 UNSUBSCRIBE channelPUNSUBSCRIBE pattern:取消指定频道或模式的订阅。

适用场景

  • 实时消息推送(如公告、系统通知)
  • 简单的广播通知、群聊消息
  • 跨服务的轻量级事件通知

优缺点

优点:实现简单、实时性高、轻量无侵入;缺点:不持久化消息、不保证消息必达、无消息确认机制,不适合核心业务消息传输。

7.redis主从复制

概念

主从复制是 Redis 的数据备份与读写分离机制,通过配置将一台 Redis 服务器(主节点 master)的数据,实时同步到一台或多台其他 Redis 服务器(从节点 slave)。主节点负责写操作,从节点负责读操作,既能分担主节点压力,也能实现数据冗余备份。

核心原理

  1. 建立连接:从节点启动后,向主节点发送同步请求,建立网络连接。
  2. 全量复制 :主节点执行bgsave生成 RDB 快照文件,发送给从节点;从节点清空自身数据,加载快照完成初始同步。
  3. 增量复制:全量同步后,主节点将后续的写命令缓存起来,实时发送给从节点,从节点执行命令保持数据一致。
  4. 心跳检测:主从节点之间定时发送心跳包,维持连接并校验同步状态。

核心配置

从节点配置:SLAVEOF 主节点IP 端口主节点有密码时:MASTERAUTH 密码

作用

  1. 读写分离:主写从读,提升 Redis 并发处理能力;
  2. 数据备份:从节点保留完整数据副本,防止主节点数据丢失;
  3. 故障兜底:主节点宕机后,可手动将从节点升级为主节点,保证服务可用。

特点

  • 一个主节点可对应多个从节点;
  • 从节点只能读,不能写;
  • 数据最终一致性,短时间内可能存在微小延迟。

8.redis缓存穿透,击穿,雪崩

  1. 缓存穿透(Cache Penetration)

是什么

大量请求根本不存在的数据,缓存里没有,数据库里也没有,请求直接穿透缓存打到 DB。

典型场景:

  • 恶意请求 id = -1、id = 999999999

  • 业务逻辑错误,大量查询不存在的 key

危害

数据库压力暴增,甚至打挂 DB。

解决方案

  1. 缓存空值 查询不存在时,缓存一个 null 或空对象,设置短过期时间

  2. **布隆过滤器(Bloom Filter)**提前把所有存在的 key 存入布隆过滤器,请求先过过滤器,不存在直接返回。

  3. 接口层参数校验非法 id、非法参数直接拦截。


  1. 缓存击穿(Cache Breakdown)

是什么

某个热点 key 突然过期,大量并发请求同时访问该 key,全部落到数据库。

特点:

  • 单个 key 热点

  • 缓存过期瞬间

  • DB 瞬间压力飙升

危害

数据库被瞬间打满。

解决方案

  1. **互斥锁(Mutex Lock)**缓存未命中时,加锁,只允许一个线程去查 DB,其他线程等待。

  2. 热点 key 永不过期不设置过期时间,后台定时更新。

  3. 逻辑过期缓存中存过期时间,后台异步刷新,不阻塞请求。

  4. 随机过期时间避免大量 key 同一时间过期。


  1. 缓存雪崩(Cache Avalanche)

是什么

大量缓存 key 同一时间集体失效,或 Redis 宕机,所有请求直接打到数据库。

特点:

  • 大范围缓存失效

  • DB 压力巨大,极易宕机

解决方案

  1. 过期时间加随机值避免批量 key 同时过期。

  2. 多级缓存本地缓存(Caffeine/Caffeine)+ Redis 缓存。

  3. Redis 高可用主从、哨兵、集群,避免 Redis 单点宕机。

  4. 限流、熔断、降级保护数据库,过载直接返回兜底数据。

  5. 缓存预热启动时提前加载热点数据。


一句话快速区分

  • 穿透 :查不存在的数据 → 缓存和 DB 都没有

  • 击穿热点 key 过期 → 单个 key 并发打 DB

  • 雪崩大量 key 同时失效 / Redis 挂了 → 全面打 DB

相关推荐
白露与泡影2 小时前
Java面试题库及答案解析(2026版)
java·开发语言·面试
程序员阿明2 小时前
spring boot3 集成jjwt(java-jwt)版本的
java·spring boot·python
bbq粉刷匠2 小时前
Java--剖析synchronized
java·开发语言
ayt0072 小时前
Netty AbstractNioChannel源码深度剖析:NIO Channel的抽象实现
java·数据库·网络协议·安全·nio
Gofarlic_OMS2 小时前
装备制造企业Fluent许可证成本分点典型案例
java·大数据·开发语言·人工智能·自动化·制造
码王吴彦祖2 小时前
顶象 AC 纯算法迁移实战:从补环境到纯算的完整拆解
java·前端·算法
杰克尼2 小时前
redis(day03-商户查询缓存)
数据库·redis·缓存
开心码农1号3 小时前
Java rabbitMQ如何发送、消费消息、全套可靠方案
java·rabbitmq·java-rabbitmq
刘~浪地球3 小时前
Redis 从入门到精通(十三):哨兵与集群
数据库·redis·缓存