一、Redis 是什么？
1. 核心定位
Redis（Remote Dictionary Server）是一款开源、C语言编写的内存/缓存型非关系型数据库（NoSQL），支持存储非结构化数据（如字符串、列表、哈希等），核心定位是"高性能缓存+数据存储"。
2. 核心特性
高性能：读取速度达 110000 次/s，写入速度达 81000 次/s
数据结构丰富：支持 string（字符串）、list（列表）、hash（哈希）、sets（无序集合）、sorted sets（有序集合）
原子性：单线程执行写命令，避免并发锁开销
支持持久化：可将内存数据同步到磁盘，防止数据丢失
支持主从复制、哨兵模式等集群方案，提升可用性
3. 为什么 Redis 这么快？
纯内存操作：避免磁盘 IO 的慢速开销。
单线程模型：无需上下文切换，减少并发管理开销（Redis 6.0 新增多线程仅用于处理请求接收，核心写命令仍单线程）。
IO 多路复用：同时处理多个客户端连接，提升并发处理能力。
二、Redis 怎么用？
1. 核心用途
作为"缓存中间件"，存储高热数据（访问频率高、查询耗时的热点数据），减少后端数据库压力。
2. 典型场景
秒杀活动：库存扣减、订单写入优先走 Redis，避免 MySQL 并发过载
实时榜单：用 sorted set 存储关键词+热度值，实现抖音热搜榜、商品销量榜等实时排序
数据缓存：用户信息、商品详情等高频查询数据，缓存后直接从 Redis 返回，提升响应速度
三、Redis 为什么能帮 MySQL 缓冲？如何帮？
1. 为什么能帮 MySQL 缓冲？
MySQL 短板：并发能力弱，高频访问场景下易卡顿（磁盘 IO 慢、锁竞争严重）
Redis 优势：纯内存操作+高并发支持，能承接大部分高频请求，相当于"流量过滤器"，减轻 MySQL 压力
2. 如何帮 MySQL 缓冲？（缓存流程）
① 客户端发起请求时，优先查询 Redis
② 若 Redis 中存在目标数据（缓存命中），直接返回数据，无需访问 MySQL
③ 若 Redis 中无数据（缓存未命中），再查询 MySQL
④ 将 MySQL 返回的结果写入 Redis 缓存，后续相同请求直接从 Redis 获取
通过该流程，Redis 拦截了大部分高频请求，避免 MySQL 被海量并发查询压垮，实现"缓冲"效果。
四、Redis 持久化：是什么、怎么做、为什么用？
1. 持久化的定义与意义（为什么用）
问题：Redis 数据默认存储在内存中，服务器宕机（断电、重启）会导致数据全部丢失。
解决方案：持久化是将内存中的数据定期/实时同步到磁盘的机制，目的是保证数据可靠性，宕机后可通过磁盘文件恢复数据，避免缓存雪崩（缓存全失后全量请求打向 MySQL）。
2. 两种持久化方案（怎么做）
| 方案 | 核心原理 | 触发方式 | 特点 |
|---|---|---|---|
| RDB（Redis DataBase） | 周期性生成数据快照（类似 VM 快照），将某一时刻的内存数据完整写入磁盘文件 | 1. 配置文件指定周期（如 900s 内改 1 次、300s 内改 10 次）； 2. 手动执行 save（阻塞主进程）或 bgsave（后台异步执行）命令 |
优点：文件体积小、恢复速度快； 缺点：数据一致性差（可能丢失周期内的新数据） |
| AOF（Append Only File） | 实时记录每一条写/删除命令（查询命令不记录），Redis 重启时重新执行命令恢复数据 | 1. 配置文件开启 appendonly yes； 2. 同步策略：每秒同步（默认）、每写一条同步、不主动同步 |
优点：数据一致性强（实时性好），主流方案； 缺点：文件体积大、恢复速度较慢 |
3. 核心区别
AOF 实时性优于 RDB，数据丢失风险更低，是生产环境首选。
RDB 适合数据备份、全量恢复场景，可与 AOF 配合使用（双重保障）。
五、Redis 主从复制怎么实现？
1. 核心目的
数据备份：从节点（Slave）复制主节点（Master）数据，避免单节点数据丢失；
负载均衡：读请求分流到从节点，主节点专注处理写请求，提升整体并发能力。
2. 核心原理
从节点主动向主节点发起同步请求，主节点通过 RDB 持久化生成数据快照，结合增量命令（同步期间的新数据操作），将完整数据同步到从节点，后续主节点的写操作会实时同步给从节点。
3. 同步流程（重点）
① Slave 启动后，向 Master 发送 sync command 同步请求
② Master 启动后台进程执行 RDB 持久化（生成数据快照），同时缓存同步期间的所有写命令
③ Master 完成 RDB 后，将 RDB 文件发送给 Slave
④ Slave 接收 RDB 文件，保存到磁盘并加载到内存
⑤ Master 再将缓存的写命令发送给 Slave，Slave 执行命令完成增量同步
⑥ 后续 Master 新增写操作，会实时同步给所有 Slave；若 Slave 宕机恢复后，会自动重新连接同步。
4. 搭建关键步骤（基于 Redis 5.0.7）
（1）环境准备
节点规划：Master（192.168.10.130）、Slave1（192.168.10.131）、Slave2（192.168.10.132）；
基础操作：关闭防火墙（systemctl stop firewalld）、禁用 SELinux（setenforce 0）。
（2）安装 Redis（所有节点）
Bash
# 安装依赖
yum install -y gcc gcc-c++ make
# 下载并解压
wget -p /opt http://download.redis.io/releases/redis-5.0.7.tar.gz
tar zxvf redis-5.0.7.tar.gz -C /opt/
# 编译安装
cd /opt/redis-5.0.7/
make && make PREFIX=/usr/local/redis install
# 配置环境变量
ln -s /usr/local/redis/bin/* /usr/local/bin/（3）Master 节点配置（/etc/redis/6379.conf）
Bash
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，修改监听地址为0.0.0.0
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
appendonly yes #700行，开启AOF持久化功能
# 重启生效
/etc/init.d/redis_6379 restart（4）Slave 节点配置（/etc/redis/6379.conf）
Bash
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，修改监听地址为0.0.0.0
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
#288行，指定要同步的Master节点IP和端口
replicaof 192.168.10.130 6379
appendonly yes #700行，开启AOF持久化功能
/etc/init.d/redis_6379 restart（5）验证主从效果
Bash
在Master节点上看日志：
tail -f /var/log/redis_6379.log
Replica 192.168.10.131:6379 asks for synchronization
Replica 192.168.10.132:6379 asks for synchronization
在Master节点上验证从节点：
redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.10.18,port=6379,state=online,offset=1246,lag=0
slave1:ip=192.168.10.19,port=6379,state=online,offset=1246,lag=1
六、Redis 哨兵模式
1. 哨兵模式的定义（解决什么问题）
主从复制的痛点：主节点宕机后，需手动将 Slave 切换为 Master，耗时费力且导致服务短暂不可用。
哨兵模式（Sentinel）是基于主从复制的高可用解决方案，核心是"自动故障转移"，无需人工干预即可实现主节点故障后的集群自愈。
2. 核心原理
哨兵是一个分布式系统，由 3个以上奇数哨兵节点（特殊 Redis 节点，不存储数据）组成，通过以下机制保障高可用：
监控：哨兵节点定期检测主从节点的存活状态
投票判定：当主节点故障时，超过半数哨兵节点达成共识（客观下线），触发故障转移
选举新主：通过 Raft 算法选举 1 个哨兵节点作为 Leader，由其执行故障转移操作
3. 核心作用
监控：每隔 1 秒向主从节点、其他哨兵节点发送 Ping 命令，检测节点健康状态
自动故障转移：主节点故障后，自动将最优 Slave 升级为新主，其他 Slave 同步新主数据，原主恢复后转为 Slave
通知：将故障转移结果（新主节点地址）发送给客户端，确保客户端正常访问
4. 故障转移机制（重点）
① 故障检测：哨兵节点每秒 Ping 主节点，若主节点在指定时间（默认 30 秒）内未响应或回复错误，该哨兵判定主节点"主观下线"
② 客观下线：当超过半数哨兵节点均判定主节点主观下线，即达成共识，主节点"客观下线"
③ 选举 Leader 哨兵：所有哨兵通过 Raft 算法选举 1 个 Leader，负责执行故障转移
④执行转移：
(1) 筛选最优 Slave（健康、优先级最高、复制最完整）升级为新主
(2) 通知其他 Slave 同步新主数据
(3) 原主节点恢复后，自动转为新主的 Slave
(4) 通知客户端更新主节点地址
5. 新主节点选举规则
① 过滤不健康（未响应 Ping、已下线）的 Slave；
② 选择配置文件中优先级最高的 Slave（replica-priority，默认 100，值越小优先级越高）；
③ 选择复制偏移量最大的 Slave（即同步主数据最完整的 Slave）。
6. 搭建关键步骤（基于 Redis 5.0.7）
（1）前置条件
已完成主从复制搭建（Master：192.168.10.130，Slave1：192.168.10.131，Slave2：192.168.10.132）。
（2）所有节点修改哨兵配置文件（/opt/redis-5.0.7/sentinel.conf）
vim /opt/redis-5.0.7/sentinel.conf
protected-mode no # 17行，关闭保护模式
port 26379 # 21行，哨兵默认监听端口
daemonize yes # 26行，后台启动
logfile "/var/log/sentinel.log" # 36行，日志路径
dir "/var/lib/redis/6379" # 65行，数据存储路径
# 84行，监控主节点（名称mymaster，IP+端口，需2个哨兵同意判定故障）
sentinel monitor mymaster 192.168.10.130 6379 2
sentinel down-after-milliseconds mymaster 30000 # 113行，30秒未响应判定下线
sentinel failover-timeout mymaster 180000 # 146行，故障转移超时时间180秒（3）启动哨兵模式（先启 Master，再启 Slave）
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf & # 后台启动哨兵（4）验证哨兵状态
redis-cli -p 26379 info Sentinel
（5）故障模拟与验证
# 1. 查看 Master 节点 redis-server 进程号
ps -ef | grep redis
# 2. 杀死 Master 进程（模拟主节点故障）
kill -9 7394（Master 进程号）
# 3. 查看哨兵日志，确认故障转移
tail -f /var/log/sentinel.log
# 4. 验证新主节点
redis-cli -p 26379 info Sentinel
# 预期输出：master0:address=192.168.10.131:6379（已切换为 Slave1）
七、整体总结
1. Redis 核心价值
Redis 作为"高性能内存缓存+NoSQL 数据库"，核心解决了 MySQL 并发能力弱、响应慢的痛点，通过缓存高热数据实现"减压提速"，同时通过持久化、主从复制、哨兵模式保障数据可靠性和集群高可用。
2. 关键组件逻辑关联
持久化：解决"内存数据易丢失"问题，是数据可靠的基础（RDB 备份+AOF 实时同步）
主从复制：解决"单节点负载高"问题，实现数据备份+读负载分流，是哨兵模式的前提
哨兵模式：解决"主从复制手动故障转移"问题，实现集群高可用，让 Redis 具备生产环境部署能力
3. 核心流程闭环
客户端请求 → Redis 缓存命中→ 直接返回；未命中→ 查询 MySQL→ 结果写入 Redis→ 后续复用
集群层面：主节点写数据→ 同步至 Slave→ 哨兵监控节点状态→ 主节点故障自动切换→ 服务无感知
4. 生产环境核心方案
缓存策略：Redis 缓存高热数据，减轻 MySQL 压力
数据可靠：开启 AOF 持久化+定期 RDB 备份
高可用：主从复制（1 主 N 从）+ 哨兵模式（≥3 个哨兵节点），实现自动故障转移
核心目标：高性能、高可用、数据可靠