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

相关推荐
专注API从业者24 分钟前
Open Claw 京东商品监控选品实战:一键抓取、实时监控、高效选品
java·服务器·数据库
摇滚侠41 分钟前
DBeaver 导入数据库 导入 SQL 文件 MySQL 备份恢复
java·数据库·mysql
keep one's resolveY1 小时前
SpringBoot实现重试机制的四种方案
java·spring boot·后端
天空属于哈夫克32 小时前
企业微信API常见的错误和解决方案
java·数据库·企业微信
摇滚侠2 小时前
VMvare 虚拟机 Oracle19c 安装步骤,远程连接 Oracle19c,百度网盘安装包
java·oracle
梁萌2 小时前
idea报错找不到XX包的解决方法
java·intellij-idea·启动报错·缺少包
Agent产品评测局3 小时前
生产排期与MES/ERP系统打通,实操方法详解 —— 2026企业级智能体自动化选型与实战指南
java·运维·人工智能·ai·chatgpt·自动化
阿丰资源3 小时前
基于Spring Boot的电影城管理系统(直接运行)
java·spring boot·后端
呱牛do it3 小时前
企业级门户网站设计与实现:基于SpringBoot + Vue3的全栈解决方案(Day 8)
java
虹科网络安全3 小时前
艾体宝产品|深度解读 Redis 8.4 新增功能:原子化 Slot 迁移(下)
数据库·redis·bootstrap