redis

一、学习路线与整体认知

1.1 学习目标

• 理解 Redis 是什么、为什么快、适合做什么
• 掌握常用数据结构与基本命令
• 理解 RDB/AOF 持久化与高可用架构
• 能回答缓存穿透、击穿、雪崩及内存管理问题

1.2 Redis 在系统中的位置

• 常作为应用与关系型数据库之间的缓存层
• 缓存热点数据，减少数据库访问压力
• 也可用于计数、排行榜、会话、队列等场景

1.3 关系型数据库与 NoSQL

• 关系型数据库：表结构清晰、SQL、事务能力强
• NoSQL：数据模型灵活，便于横向扩展
• 两者通常互补，不是简单的替代关系

二、Redis 基础概念

2.1 Redis 是什么

• 开源、基于内存的键值数据库
• 支持多种数据结构与数据持久化
• 常用于缓存，也可用于计数、排行榜等

2.2 Redis 为什么快

• 主要数据访问在内存中完成，减少磁盘 I/O
• 命令执行核心通常由单线程处理，减少锁竞争
• I/O 多路复用高效处理大量网络连接
• Redis 6 起网络 I/O 可采用多线程，但命令执行核心仍以单线程为主

2.3 Redis 的主要特点

• 读写性能高，适合高并发访问
• 数据结构丰富，命令操作灵活
• 支持 RDB、AOF 持久化
• 支持主从复制、哨兵和 Cluster 集群

2.4 典型应用场景

• 缓存：商品详情、用户资料
• 计数器：访问量、点赞数
• 排行榜：热度、积分（Sorted Set）
• 会话与临时数据：设置过期时间
• 限流、队列等场景需结合具体设计

三、核心数据结构与命令

3.1 通用键操作

• SET key value：设置字符串值；GET key：获取字符串值
• EXISTS key：检查键是否存在；DEL key：删除键
• TYPE key：查看值类型；EXPIRE key seconds / TTL key：设置或查看过期时间

3.2 String 字符串

• 存储字符串、数字、序列化内容；SET name Alice / GET name
• INCR visits：原子递增计数；SET session:1 abc EX 3600：设置一小时过期

3.3 List 列表

• 有序、可重复，适合简单队列或列表；LPUSH key value：从左侧插入
• RPUSH key value：从右侧插入；LPOP / RPOP：从两端弹出

3.4 Hash 哈希

• 一个 key 下保存多个字段和值，适合对象属性；HSET user:1 name Tom age 20
• HGET user:1 name / HGETALL user:1；小型对象可减少大量独立键的管理开销

3.5 Set 集合

• 无序、元素不重复；SADD tags redis mysql：添加成员
• SISMEMBER tags redis：判断成员是否存在；可用于标签、去重、交集与并集

3.6 Sorted Set 有序集合

• 每个成员关联一个 score，按分值排序；ZADD hot 100 redis：添加成员及分值
• ZRANGE hot 0 -1 WITHSCORES：按序查看；适合排行榜、热度排序

3.7 其他结构与版本提示

• Bitmap：位图，适合签到、状态标记；HyperLogLog：近似统计不重复数量
• Stream：消息流结构；不同 Redis 版本支持的结构和命令有所差异

3.8 键查询与管理

• KEYS pattern：按模式查询键；生产环境谨慎使用 KEYS *，键很多时可能阻塞服务
• SCAN：分批迭代键，适合渐进式遍历；RENAME 会覆盖目标键，RENAMENX 仅在目标不存在时重命名
• DBSIZE：当前数据库键数量

3.9 数据库与清理

• 默认逻辑数据库通常为 0--15，默认连接使用 0；SELECT index：切换逻辑数据库
• MOVE key db：在逻辑库间移动键；FLUSHDB：清空当前逻辑库
• FLUSHALL：清空所有逻辑库，操作前务必确认

四、安装、连接与常用工具

4.1 常见工具

• redis-server：启动 Redis 服务；redis-cli：连接并执行命令
• redis-benchmark：基础性能压测工具；redis-check-rdb / redis-check-aof：检查持久化文件（依版本而定）

4.2 连接 Redis

• redis-cli -h host -p 6379：指定地址与端口
• redis-cli -a password：可用于带密码连接，注意避免命令行泄露密码
• 默认端口通常为 6379

4.3 常见配置项

• bind：指定监听地址；port：监听端口，默认 6379
• daemonize：是否以守护进程方式运行（传统配置）；logfile：日志文件路径
• requirepass：传统密码配置项，实际版本应按对应认证配置管理
• maxmemory：设置可用内存上限；appendonly：是否启用 AOF

4.4 基础排查与安全

• 确认服务进程、端口、日志和配置文件
• 检查客户端到 Redis 的网络连通性与防火墙规则
• 不要把 Redis 直接暴露到不可信公网
• 设置认证、限制监听地址并按最小权限开放访问

4.5 性能测试入门

• 示例：redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000
• -c 指定并发连接数；-n 指定请求总数
• 压测结果受硬件、网络、命令、数据大小与配置影响，不能直接当作通用性能承诺

五、过期键与内存管理

5.1 过期时间 TTL

• 缓存数据应根据业务设置合理 TTL；EXPIRE key seconds 设置过期时间
• TTL key 查看剩余时间；可给缓存 TTL 加随机抖动，减少同一时刻集中失效

5.2 maxmemory 与淘汰策略

• maxmemory：限制 Redis 可用内存；内存达到上限后，按 maxmemory-policy 处理
• noeviction：不淘汰键，写入可能报错；allkeys-lru：从所有键中淘汰近期最少使用的键
• volatile-lru：只从设置了过期时间的键中按 LRU 淘汰
• allkeys-random / volatile-random：随机淘汰；volatile-ttl：优先淘汰剩余 TTL 较短的键
• 具体可用策略随 Redis 版本而变化

5.3 内存监控

• INFO memory：查看内存指标；used_memory：Redis 分配用于数据及内部开销的内存
• used_memory_rss：操作系统视角的进程常驻物理内存
• mem_fragmentation_ratio：RSS 与 used_memory 的比值，需结合系统状态分析

5.4 内存优化思路

• 合理规划实例内存并预留系统开销；为缓存键设置 TTL，清理无用数据
• 选择合适的数据结构并控制大键；设置 maxmemory 与匹配业务的淘汰策略
• 关注 swap、碎片率、慢命令与大批量操作

六、持久化机制（重点）

6.1 为什么要持久化

• Redis 主要在内存中保存数据，进程或主机故障可能造成数据丢失
• 持久化把数据保存到磁盘，用于重启后恢复

6.2 RDB 快照

• 将某个时间点的数据状态保存为 RDB 文件；常通过 BGSAVE 后台生成快照
• SAVE 会阻塞 Redis 主线程，生产环境通常避免直接执行
• save m n：m 秒内至少 n 次变化时触发快照，满足任一配置条件即可触发
• 优点：文件通常较紧凑，恢复速度较快，适合备份和全量复制
• 缺点：两次快照之间的最新变更可能丢失；BGSAVE 会 fork 子进程，fork 时可能短暂阻塞，并产生额外内存与磁盘 I/O 开销

6.3 AOF 日志

• 记录写命令，重启时重放命令恢复数据；查询命令通常不写入 AOF
• appendonly yes：启用 AOF（以对应版本配置为准）
• appendfsync always：每次写命令都同步，安全性高但性能开销较大
• appendfsync everysec：通常每秒同步，性能与安全性折中
• appendfsync no：由操作系统决定同步时机，数据安全性较低

6.4 AOF 重写

• 长期追加写命令会使 AOF 文件变大；BGREWRITEAOF 根据当前数据状态生成更精简的新文件
• 重写不是简单删除旧文本，而是用可重建当前状态的命令替代冗余历史命令
• 重写期间的新写入会被额外缓冲，最终合并后替换旧文件

6.5 RDB 与 AOF 对比

• RDB 保存数据快照：文件紧凑、恢复较快，但可能丢失最近变更
• AOF 保存写操作日志：通常数据丢失窗口更小，但文件和恢复成本可能更大
• 可按业务需要组合使用，不能简单认为某一种永远最好
• 启动时使用哪种文件恢复、文件损坏如何处理，应以具体 Redis 版本和配置为准

6.6 持久化面试答法

• RDB：保存某一时刻的数据快照；AOF：记录写命令并在恢复时重放
• BGSAVE 尽量后台生成快照；SAVE 会阻塞
• everysec 常是性能与数据安全之间的折中选择

七、高可用与数据分布

7.1 主从复制

• 主节点通常负责写，从节点复制主节点数据并可分担读请求
• 作用：数据冗余、读扩展与故障恢复基础
• 单靠主从复制不会自动完成主从切换
• 复制通常存在延迟，不能无条件认为从库数据实时一致

7.2 Sentinel 哨兵

• 监控主从节点状态
• 主节点发生故障时，通过投票与故障判定进行自动故障转移
• 帮助客户端发现新的主节点（客户端需支持相应机制）
• 不解决数据分片；写能力通常仍由一个主节点承担

7.3 Redis Cluster 集群

• 通过哈希槽将键分布到多个主节点，实现数据分片
• 每个主节点可配置从节点用于复制与故障转移
• 解决单机内存和写入扩展受限的问题
• 客户端需要支持 Cluster 协议或使用兼容代理

7.4 三种方案的区别

• 主从：复制数据、读扩展；切换通常需额外机制
• 哨兵：主从基础上提供监控与自动故障转移
• Cluster：分片存储，并结合副本提供可用性
• 持久化是数据恢复手段，不等同于高可用

7.5 常见理解误区

• 有副本不代表零数据丢失，复制可能异步
• 高可用不等于备份，误删可能同步到副本
• 生产环境仍需备份、监控、故障演练与恢复验证

八、缓存常见问题（面试重点）

8.1 缓存穿透

• 含义：请求的数据在缓存和数据库中都不存在，持续访问数据库
• 原因：恶意请求或大量查询不存在的 ID
• 方案一：对不存在结果缓存空值，并设置较短 TTL
• 方案二：使用布隆过滤器预判数据是否可能存在
• 布隆过滤器判断"不存在"通常可信；判断"存在"仍可能是假阳性

8.2 缓存击穿

• 含义：某个热点键过期瞬间，大量请求同时查询数据库
• 方案一：互斥锁或请求合并，限制同一热点数据的并发回源
• 方案二：热点数据逻辑过期并异步刷新
• 方案三：对合适的热点数据延长 TTL 或不设置物理过期（需设计更新机制）

8.3 缓存雪崩

• 含义：大量键在同一时刻过期，或缓存服务整体不可用，导致请求集中打到数据库
• 方案一：TTL 增加随机值，避免集中失效
• 方案二：使用高可用架构，降低缓存整体不可用概率
• 方案三：限流、熔断、降级，保护数据库
• 方案四：热点数据提前刷新或准备备用方案

8.4 三者快速区分

• 穿透：查不存在的数据，缓存挡不住
• 击穿：一个热点键失效，流量集中回源
• 雪崩：大量键同时失效或缓存整体故障

8.5 缓存使用原则

• 缓存不是最终数据的唯一保障，关键数据需明确持久化与一致性方案
• 更新数据库与删除/更新缓存的顺序需要结合业务设计
• 监控命中率、延迟、内存、淘汰、连接数与数据库回源量

九、高频面试问答与复习清单

9.1 基础问题

• Redis 是什么？基于内存的键值数据库，支持多种数据结构与持久化
• Redis 为什么快？内存访问、命令执行模型与 I/O 多路复用共同作用
• Redis 常见数据结构有哪些？String、List、Hash、Set、Sorted Set
• Redis 默认端口是多少？通常是 6379

9.2 持久化问题

• RDB 和 AOF 有什么区别？快照与写命令日志的区别
• SAVE 和 BGSAVE 有什么区别？前者阻塞执行，后者通过子进程后台生成
• AOF 重写是做什么的？用更精简的命令重建当前数据状态
• 持久化能否替代备份？不能，仍需独立备份和恢复验证

9.3 高可用与缓存问题

• 主从、哨兵、Cluster 有何区别？复制、自动切换、分片
• 穿透、击穿、雪崩如何区分？不存在数据、单个热点失效、大量失效/服务故障
• 内存满了怎么办？检查数据与大键、TTL、maxmemory 和淘汰策略
• 为什么不建议生产环境随意执行 KEYS *？可能遍历大量键并阻塞服务

9.4 动手复习清单

• 练习 SET/GET/DEL/EXPIRE/TTL/TYPE/INCR
• 练习 Hash、List、Set、Sorted Set 的基本命令
• 理解并能口述 RDB、AOF 与 AOF 重写流程
• 能画出主从复制、哨兵和 Cluster 的区别
• 能用自己的话说明穿透、击穿、雪崩及解决办法