一、redis事务

• Redis 事务：定义、特性、用法与核心要点

• Redis 事务是 一组命令的有序集合，核心作用是将多个命令 “打包” 执行 ——要么全部执行，要么全部不执行（部分场景例外），且执行过程中不会被其他客户端的命令打断（串行执行）。

• 它和 MySQL 等关系型数据库的事务有本质区别：Redis 事务更轻量，不支持严格的 ACID 特性（尤其缺乏 “回滚” 机制），核心目标是保证命令的串行执行和批量提交。

• Redis 事务的核心命令

• Redis 事务通过 4 个核心命令实现完整流程，作用如下：

命令	功能描述
MULTI	开启事务：之后输入的所有命令都会被 “入队”（暂不执行），返回 QUEUED 标识
EXEC	执行事务：触发队列中所有命令按顺序执行，返回每个命令的执行结果（数组形式）
DISCARD	取消事务：清空命令队列，终止当前事务，不会执行任何入队命令
WATCH	监视 1 个或多个键：事务执行前，若被监视的键被其他客户端修改，事务会被取消（乐观锁核心）

事务的完整流程分为 3 步：开启事务 → 命令入队 → 执行 / 取消事务，用实际操作示例说明：

js
127.0.0.1:6379> MULTI  # 1. 开启事务
OK
127.0.0.1:6379> SET user:1:name "zhangsan"  # 2. 命令入队（暂不执行）
QUEUED
127.0.0.1:6379> SET user:1:age 25
QUEUED
127.0.0.1:6379> GET user:1:name  # 入队查询命令
QUEUED
127.0.0.1:6379> EXEC  # 3. 执行事务，返回所有命令结果
1) OK  # SET user:1:name 的结果
2) OK  # SET user:1:age 的结果
3) "zhangsan"  # GET user:1:name 的结果

取消事务

js
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET k1 v1
QUEUED
127.0.0.1:6379> DISCARD  # 取消事务，队列清空
OK
127.0.0.1:6379> GET k1  # 命令未执行，返回 nil
(nil)

二、redis持久化

• Redis 是内存数据库，默认情况下数据仅存储在内存中，一旦服务器宕机（如断电、重启），数据会全部丢失。持久化的核心目的是：将内存中的数据定期 / 实时写入磁盘，重启后从磁盘恢复数据，避免数据丢失。
• Redis 提供两种核心持久化机制：RDB（Redis DataBase） 和 AOF（Append Only File），也支持两者结合的混合持久化（Redis 4.0+），适用于不同业务场景。

RDB 持久化（快照模式）

RDB 是 Redis 的默认持久化方式，核心是：在指定时间点，将内存中的全量数据生成一份二进制快照文件（默认文件名 dump.rdb），写入磁盘。重启时，直接加载该文件到内存，快速恢复数据。

触发方式

• SAVE：直接由主进程生成快照，阻塞所有客户端请求，直到快照完成（不推荐线上使用，适用于小内存、测试环境）；
• BGSAVE：后台生成快照（Background Save），主进程不阻塞，通过子进程完成快照（线上推荐使用）。

js
127.0.0.1:6379> BGSAVE  # 后台生成RDB快照
Background saving started

自动触发（配置文件 redis.conf）

通过 save 配置 “触发条件”：在 seconds 秒内，数据发生 changes 次修改，自动执行 BGSAVE。 默认配置（可修改）：

js
save 900 1    # 900秒（15分钟）内至少1次修改
save 300 10   # 300秒（5分钟）内至少10次修改
save 60 10000 # 60秒（1分钟）内至少10000次修改

• 优点：

• 恢复速度快：RDB 是二进制全量快照，重启时直接加载到内存，比 AOF 快一个数量级；

• 文件体积小：压缩后的二进制文件，占用磁盘空间少，适合备份（如每天凌晨生成 RDB 快照备份）；

• 性能影响小：快照由子进程完成，主进程仅 fork() 时短暂阻塞，不影响正常服务。

• 缺点：

• 数据丢失风险高：仅记录 “某个时间点” 的快照，若两次快照之间宕机，期间的修改数据会全部丢失（如配置 save 60 10000，则最多可能丢 1 分钟数据）；

• fork() 开销大：若 Redis 内存较大（如 10GB+），fork() 会消耗大量虚拟内存，且可能导致主进程短暂阻塞（毫秒 / 秒级）；

• 不适合实时持久化：无法做到 “秒级” 数据落地，适合对数据一致性要求不高的场景。

AOF 持久化（日志模式）

AOF（Append Only File）是增量持久化方式，核心是：将每一条 “写命令”（如 SET、INCR、HMSET）以文本格式追加到 AOF 日志文件（默认 appendonly.aof）中。重启时，Redis 会重新执行 AOF 文件中的所有命令，还原内存数据。

工作原理（三步流程）

1. 命令追加（Append）：客户端执行写命令后，Redis 先将命令写入内存中的 “AOF 缓冲区”（避免频繁磁盘 IO）；
2. 缓冲区同步（Sync）：根据配置的 “同步策略”，将缓冲区数据刷写到磁盘（核心是平衡性能和数据安全性）；
3. 文件重写（Rewrite）：AOF 文件会随命令增多而膨胀，Redis 会定期 “重写” AOF 文件，删除无效命令（如 SET k1 v1 后又 DEL k1）、合并重复命令（如 INCR k1 3 替代 3 次 INCR k1），压缩文件体积。

核心配置（redis.conf）

js
appendonly yes  # 默认为 no，改为 yes 启用 AOF    

同步策略

AOF 缓冲区同步到磁盘的策略，通过 appendfsync 配置，有 3 种选择：

优缺点

优点：

• 数据丢失少：支持秒级 / 零级数据落地（everysec/always），宕机最多丢失 1 秒数据（或零丢失），适合对数据一致性要求高的场景；
• 文件可读性强：AOF 是文本文件，可直接查看命令日志，甚至手动修改（如误删数据后，编辑 AOF 文件删除误操作命令，再重启恢复）；
• 无 fork() 阻塞风险：重写虽用子进程，但主进程仅需处理 “重写缓冲区”，阻塞时间极短（远低于 RDB 的 fork() 开销）。

缺点：

• 恢复速度慢：重启时需重新执行所有命令，若 AOF 文件较大（如 10GB+），恢复时间可能长达分钟级，远慢于 RDB；

• 文件体积大：未重写的 AOF 文件体积远大于 RDB（如频繁修改同一键，会记录大量重复命令），磁盘占用高；

• 性能开销略高：写命令需追加到缓冲区 + 定期刷盘，everysec 模式下性能比 RDB 略低（但可接受），always 模式性能损耗明显。

混合持久化（Redis 4.0+，默认启用）

混合持久化是 RDB + AOF 的结合方案：AOF 文件开头存储 “RDB 全量快照”，后面追加 “AOF 增量命令日志”。重启时，先加载 RDB 快照快速恢复全量数据，再重放 AOF 增量命令，补充快照后的修改数据。

启用混合持久化后（aof-use-rdb-preamble yes），执行 BGREWRITEAOF 或自动重写时，Redis 会：

• 子进程生成 RDB 快照，写入新 AOF 文件开头；
• 主进程将重写期间的增量命令写入 “重写缓冲区”；
• 子进程写完 RDB 后，主进程将缓冲区命令追加到新 AOF 文件；
• 用新 AOF 文件（RDB + 增量命令）替换旧 AOF 文件。

核心优势

• 恢复速度快：兼顾 RDB 的 “快速加载” 和 AOF 的 “数据完整性”；
• 文件体积小：RDB 部分压缩，AOF 部分仅存增量命令，比纯 AOF 小；
• 数据丢失少：仅丢失 “最后一次重写到宕机” 期间的命令（最多 1 秒，取决于 appendfsync 配置）。