Redis知识点和面试题

一、基础概念

（一）Redis 概述与特点

Redis 是一款开源的高性能内存键值数据库。其特点显著：

• 速度快：基于内存运行，采用单线程模型并搭配高效数据结构，极大提升数据处理速度。
• 数据结构丰富：支持 String、Hash、List、Set、Sorted Set 等多种数据结构，满足多样化应用需求。
• 持久化机制：具备 RDB 和 AOF 两种持久化方式，可保障数据在断电等意外情况下不丢失。
• 高可用性支持：支持主从复制和集群，能提升系统的读取性能、增强数据安全性及实现水平扩展。

（二）数据类型及应用场景

1. String
   可存储字符串、整数、浮点数。常用于缓存简单数据，如网页片段；作为计数器，记录文章阅读量等；还可用于存储序列化对象，如 JSON 格式数据。
2. Hash
   本质是键值对集合，适合存储对象，像用户信息（姓名、年龄、地址等）、商品信息（名称、价格、库存等），方便单独更新或访问对象字段。
3. List
   有序字符串列表，可应用于消息队列，实现异步任务处理；也用于展示最新消息列表，如最新评论展示。
4. Set
   无序唯一字符串集合，可存储唯一值，如标签管理；还能进行集合运算，如求交集、并集等操作。
5. Sorted Set
   有序唯一字符串集合，每个元素关联一个分数用于排序。常用于排行榜场景，如游戏排名；也适用于范围查询，如按时间排序的日志查询。

（三）操作原子性

Redis 单个命令操作具有原子性，这是因为它采用单线程处理模式，一个命令要么完整执行，要么不执行，不会执行到一半被中断。但事务中的多个命令整体并不保证原子性，例如事务执行过程中出现错误，已执行的命令不会回滚。

（四）与 Memcached 的区别

1. 数据类型：Redis 支持多种丰富的数据类型；而 Memcached 主要支持简单的键值对。
2. 持久化：Redis 拥有 RDB 和 AOF 持久化方式；Memcached 一般不具备持久化功能。
3. 分布式：Redis 有多种成熟的集群方案；Memcached 的分布式实现依赖客户端。
4. 内存管理：Redis 可配置淘汰策略管理内存；Memcached 内存管理方式相对简单。

二、持久化

（一）持久化机制及优缺点

1. RDB
   优点是对 Redis 性能影响较小，适合大规模数据恢复场景。缺点是可能丢失最近的数据变更，因为它是间隔一段时间生成快照。
2. AOF
   优点是数据恢复更安全，数据丢失较少，实时记录写操作。缺点是对性能影响较大，频繁写操作会导致文件体积不断增大。

（二）持久化方式的选用

• 若允许一定时间内数据丢失，且更注重性能，可单独选用 RDB。
• 若要求数据尽量不丢失，应选择 AOF。
• 实际应用中也可二者结合，RDB 用于定期全量备份，AOF 实时记录写操作，兼顾数据安全性和性能。

三、主从复制与集群

（一）主从复制

主从复制原理是主节点负责写数据，从节点同步主节点数据。其作用明显，实现读写分离提升读取性能，通过数据冗余提高安全性，当主节点发生故障时，从节点可作为备用节点继续提供服务。

（二）Redis Sentinel（哨兵）

Sentinel 用于监控 Redis 主从集群。原理是持续监控主从节点健康状态，一旦主节点宕机，通过选举机制选出新的主节点并进行切换，从而实现自动故障切换和高可用。

（三）Redis Cluster（集群）

Redis Cluster 通过分片实现数据分布和水平扩展。数据自动分片存储于不同节点，当节点出现故障时可自动迁移数据，还能通过增加节点扩展存储和处理能力。

四、事务与脚本

（一）事务操作及实现过程

Redis 事务通过 MULTI（开启事务）、EXEC（执行事务）、DISCARD（取消事务）、WATCH（监控键值防数据竞争） 等命令支持。实现过程为：先使用 MULTI 开启事务，之后除特殊命令外的其他命令入队，最后使用 EXEC 执行事务队列中的命令。

（二）事务特性保证情况

单个命令原子性有保证，但事务整体不保证原子性（出错时已执行命令不回滚）；在一致性方面会检查命令错误，尽力保证数据一致性；不支持隔离性；本身不保证持久性，依赖持久化机制实现数据持久保存。

（三）Lua 脚本应用

使用 Lua 脚本可保证多个操作的原子性，减少网络开销（将常用逻辑封装），并且脚本可复用，提高开发效率和系统性能。

五、缓存相关

（一）缓存问题及解决

1. 缓存雪崩：大量缓存同一时间失效，导致大量请求涌入数据库。解决办法包括设置不同过期时间，避免缓存集体失效；对热点数据设置永不过期；加锁排队，防止大量请求同时访问数据库。
2. 缓存穿透：请求不存在的数据，缓存和数据库都无法查到。可采用布隆过滤器过滤非法请求，或进行空值缓存，避免无效请求穿透到数据库。
3. 缓存击穿：热点缓存失效瞬间，大量请求访问数据库。解决方法有对热点数据加互斥锁，保证同一时间只有一个请求重建缓存；提前更新热点缓存，防止失效瞬间的大量请求冲击。

（二）提高缓存命中率策略

合理设置缓存过期时间，避免过早或过晚失效；对数据分类缓存，提高缓存针对性；使用合适数据结构存储数据；预热缓存，提前加载热点数据到缓存中。

六、原理深入理解

（一）RDB 持久化快照生成

Redis 生成 RDB 快照文件时，会 fork 一个子进程，子进程负责将当前内存中的数据以二进制格式写入临时文件，完成后用临时文件替换旧的 RDB 文件（dump.rdb）。fork 操作使得主进程能继续处理客户端请求，不被持久化操作阻塞。

（二）AOF 持久化写命令记录

Redis 每执行一个写命令，就会将其以协议格式追加到 AOF 文件末尾。可通过配置 appendfsync 参数控制写入磁盘时机，always 表示每次写操作都同步到磁盘；everysec 是每秒同步一次；no 则由操作系统决定同步时间。

七、应用场景抉择

（一）高并发高安全场景

在高并发且对数据安全性要求极高的场景下，建议同时开启 RDB 和 AOF 持久化方式。AOF 通过配置 always 选项，能最大程度保证数据不丢失；RDB 可定期生成全量快照，用于快速恢复数据和备份。不过，这样会增加磁盘 I/O 开销和存储成本。

（二）数据变更频繁场景

对于数据变更频繁，但允许一定时间内数据丢失的缓存场景，RDB 更合适。因为 RDB 是间隔一段时间生成快照，对性能影响小。即使发生故障导致数据丢失，在可接受范围内，且 RDB 文件小，恢复速度相对快。

八、对比分析

（一）RDB 与 AOF 数据恢复速度差异原因

RDB 是直接加载完整的二进制数据快照文件，一次性将数据读入内存，所以恢复速度快；AOF 则要重放文件中的所有写命令来恢复数据，命令多、操作复杂，尤其在数据集大时，恢复耗时较长。

（二）RDB 与 AOF 对性能影响差异

RDB 在 fork 子进程生成快照时，若数据集大，fork 操作可能阻塞主进程几十到几百毫秒，但平时对主进程无 IO 操作影响；AOF 每次写操作都可能涉及磁盘 IO（取决于 appendfsync 配置），频繁写时会占用较多磁盘 I/O 资源，影响 Redis 整体性能。

九、优化调整

（一）RDB 持久化触发策略优化

可根据业务写操作频率调整配置文件中 save 参数。如业务写操作频繁，缩短触发快照的时间间隔和写操作次数阈值；若写操作不频繁，适当延长间隔，减少不必要的快照生成，降低性能开销。

（二）AOF 文件优化

当 AOF 文件过大时，利用 AOF 重写机制（rewrite）。Redis 会在后台创建一个新的 AOF 文件，对原文件中的冗余命令进行合并（如多个对同一键的修改命令合并为最后一个），生成体积更小、更高效的 AOF 文件，可手动触发或配置自动触发条件。

十、其他重要方面

（一）分布式锁实现

实现 Redis 分布式锁常用 SETNX 命令，获取锁时设置唯一值和过期时间，释放锁时验证值再删除；也可使用 Redisson 等客户端工具，其内部封装了复杂逻辑，使用更便捷可靠。

（二）性能优化手段

包括优化内存使用，如设置最大内存、压缩对象；优化持久化，合理配置 RDB 和 AOF；进行网络传输优化，减少网络开销；调整性能参数，如调整线程数等。

（三）性能监控方式

使用 INFO 命令可查看各项统计信息，如内存使用、请求次数、命中率等；也可借助 Redis - CLI 工具、第三方监控工具（如 Prometheus + Grafana ）进行全面且可视化的性能监控。