Redis部署
一、Redis部署
1、单机部署
特点：
最简单的部署方式，单节点运行。
适合开发、测试或小规模应用。
无高可用性，节点宕机则服务不可用。
教程：
在这里我们选择用虚拟机（Linux环境 centos 7）来实现部署redis
在官网中下载redis压缩包Redis下载
注意：浏览器可能识别文件不安全，选择保留文件
利用终端工具将压缩包上传到虚拟机并解压压缩包
tar -zvxf redis-5.0.4.tar.gz结果如图：
注意的是redis是用C写的所以需要C的环境：
tar -zvxf redis-5.0.4.tar.gzcd redis-5.0.4编译redis
make && make install如此编译成功：
2、主从部署
特点：
- 一主多从（Master-Slave），主节点负责写，从节点负责读（读写分离）。
- 数据异步复制，从节点可提升读性能。
- 主节点宕机时需手动切换（无自动故障转移）。
教程：
这里我们准备三台虚拟机：
Master 192.168.81.131
Slave1 192.168.81.132
Slave2 192.168.81.133
在第一台虚拟机部署好redis（单机模式）后，利用
scp -r redis root@192.168.81.132:/root/
scp -r redis root@192.168.81.133:/root/复制到其他两台虚拟机，
修改slave1 和 slave2的配置：主机地址、端口和密码
保存并退出后，
在两台虚拟机中下载C环境：
yum install -y gcc tcl编译redis：
make && make install启动redis：
redis-server redis.confredis-cli -a 123456在master中输入info replication，显示如下：
注意：该过程要在关闭防火墙的前提下操作！
此后三台虚拟机的数据会一样！
3、哨兵部署
Redis 哨兵（Sentinel）是 Redis 官方提供的 高可用性（HA）解决方案，用于监控主从节点、自动故障转移（Failover）和通知管理员。
特点：
- 高可用方案，哨兵（Sentinel）监控主从节点，自动故障转移（Failover）。
- 至少需要 3 个 Sentinel 节点（避免脑裂问题）。
- 客户端通过 Sentinel 获取最新的主节点地址
教程：
打开三台虚拟机的sentinel.conf文件，做以下配置：
protected-mode no |
6行，关闭保护模式 |
daemonize yes |
15行，指定sentinel为后台启动 |
logfile "/root/redis/redis-5.0.4/sentinel.log" |
34行，指定日志存放路径 |
dir /root/redis |
73行，指定数据库存放路径 |
sentinel monitor mymaster 192.168.81.131 6379 2 |
93行，修改指定该哨兵节点监控20.0.0.20:6379这个主节点，该主节点的 |
sentinel down-after-milliseconds mymaster 30000 |
134行，判定服务器down掉的时间周期，默认30000毫秒（30秒） |
sentinel failover-timeout mymaster 180000 |
234行，故障节点的最大超时时间为180000（180秒） |
sentinel auth-pass mymaster 123456 |
主机密码 |
sentinel annoince-ip 192.168.81.131 |
本机地址 |
sentinel announce-port 26379 |
本机端口 |
然后启动哨兵模式：
redis-sentinel sentinel.conf注意：哨兵模式是基于主仆模式来启动的，必须保证其启动的状态，，
查看状态：
redis-cli -p 26379 info sentinel如图：
二、redis缓存击穿、穿透与雪崩
1、 缓存穿透（Cache Penetration）
问题描述
- 现象：大量请求查询 不存在的数据，绕过缓存直接访问数据库。
- 原因：恶意攻击或业务逻辑缺陷（如查询不存在的用户ID）。
- 影响：数据库负载激增，可能被拖垮。
解决方案
方法 |
说明 |
缓存空对象 |
对查询结果为 null 的请求也缓存（设置短TTL，如 5 分钟）。 |
布隆过滤器 |
在缓存前加一层布隆过滤器，快速判断数据是否存在，拦截无效请求判断数据是否存在，拦截无效请求。 |
参数校验 |
对请求参数做合法性检查（如ID必须为数字）。 |
2、 缓存击穿（Cache Breakdown）
问题描述
- 现象：某个 热点Key突然失效，同时大量请求直接击穿缓存访问数据库。
- 原因：高并发请求 + Key过期或手动删除。
- 影响：数据库瞬时压力过大。
解决方案
方法 |
说明 |
永不过期 |
对极热点Key设置逻辑过期（后台异步更新），不设置TTL。 |
互斥锁 |
使用 Redis 的 SETNX 实现分布式锁，只允许一个请求重建缓存。 |
双缓存策略 |
设置主备缓存（主缓存过期后，备缓存短暂顶替，异步更新主缓存）。 |
3.、缓存雪崩（Cache Avalanche）
问题描述
- 现象：大量Key同时失效 或 Redis集群宕机，导致所有请求涌向数据库。
- 原因：缓存集中过期、Redis服务崩溃。
- 影响：数据库压力过大，系统可能崩溃。
解决方案
方法 |
说明 |
过期时间随机化 |
对Key的TTL添加随机值（如基础30分钟 + 随机0-10分钟），避免同时过期。 |
多级缓存 |
结合本地缓存（Caffeine）和分布式缓存（Redis），降低Redis依赖。 |
集群高可用 |
使用 Redis 哨兵或集群模式，避免单点故障。 |
熔断降级 |
通过 Hystrix 等工具在数据库压力过大时返回默认值，保护后端。 |
三者的区别对比
问题类型 |
关键特征 |
触发条件 |
解决重点 |
穿透 |
查询不存在的数据 |
恶意攻击或无效参数 |
拦截非法请求 |
击穿 |
单个热点Key失效 |
高并发 + Key突然过期 |
避免并发重建缓存 |
雪崩 |
大量Key失效或Redis宕机 |
缓存集中过期/服务崩溃 |
分散过期时间 + 高可用 |
三、redis持久化
Redis 持久化是将内存中的数据保存到磁盘，确保服务重启后数据不丢失。Redis 提供 两种持久化机制：RDB（快照） 和 AOF（日志追加），各有优缺点，也可结合使用。
1. RDB（Redis Database）（默认）
原理
- 定时生成数据快照（二进制文件，默认 dump.rdb）。
- 触发方式：
- 手动执行 SAVE（阻塞）或 BGSAVE（后台异步）。
- 配置自动触发（如 save 900 1：900秒内至少1次修改则触发）。
优点
- 高性能：二进制文件紧凑，恢复速度快。
- 适合备份：单个文件便于迁移和灾难恢复。
- 最小化磁盘写入：仅保存某一时刻的数据。
缺点
- 可能丢失数据：两次快照之间的数据未持久化。
- 大数据量时阻塞：BGSAVE 的子进程在保存时可能占用较多 CPU/内存。
配置示例
save 900 1 # 900秒内至少1次修改则触发
save 300 10 # 300秒内至少10次修改
save 60 10000 # 60秒内至少10000次修改dbfilename dump.rdb
dir /var/lib/redis
记录会保存在dump.rdb文件里，防止断电丢失。
2. AOF（Append Only File）
原理
- 记录所有写操作命令（文本格式，默认 appendonly.aof）。
- 写入策略：
- appendfsync always：每次写命令都同步到磁盘（最安全，性能最低）。
- appendfsync everysec（默认）：每秒同步一次（平衡性能与安全）。
- appendfsync no：由操作系统决定（最快，但可能丢失数据）。
优点
- 数据安全性高：最多丢失1秒数据（everysec 模式）。
- 可读性强：AOF 文件是文本格式，便于人工分析或修复。
缺点
- 文件体积大：长期运行后 AOF 文件可能膨胀（需定期 BGREWRITEAOF 重写）。
- 恢复速度慢：需重新执行所有命令，比 RDB 慢。
配置示例
# 启用 AOF 持久化模式（默认是关闭的）
appendonly yes
# 定义 AOF 持久化文件的名称
appendfilename "appendonly.aof"
# 数据同步策略：
# always - 每次写入都同步（最安全但性能最差）
# everysec - 每秒同步一次（推荐配置，平衡性能与安全）
# no - 由操作系统决定（最快但可能丢失数据）
appendfsync everysec
# AOF/RDB 文件存储目录
dir /var/lib/redis修改redis,conf文件，appendonly yes
重启redis，进行操作redis后，可以看到出现了aof文件，
打开文件可以发现，记录了我们的所有操作：
