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

Redis入门（部署、持久化、缓存问题）

news 2025/9/9 6:53:04

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.gz

cd 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.conf

redis-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.rdbdir /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文件，