Redis 事务与持久化机制深度解析：原子性保证、Lua 脚本与 AOF / RDB 实现原理
前言
在高并发、高性能系统中，如何保证操作的原子性与数据的可靠持久化，一直是核心问题。
Redis 作为一款以内存为核心的高性能 KV 数据库，并没有采用传统关系型数据库的事务模型，而是提供了更轻量、更符合性能目标的事务与持久化机制。
本文将从工程视角与底层实现原理出发，系统讲清楚：
- Redis 如何保证原子性
- Lua 脚本与 Redis 事务的本质区别
- Redis 日志系统如何工作
- AOF 与 RDB 的实现细节与优缺点对比
一、Redis 如何保证原子性？
Redis 的原子性并不是通过锁或多版本并发控制（MVCC）实现的，而是基于单线程执行模型 + 特定机制来保证。
1.1 基于 Lua 脚本的原子性（推荐方案）
1.1.1 Lua 脚本的核心特性
Redis 提供了EVAL / EVALSHA命令，允许用户将一段 Lua 脚本发送给 Redis 执行，并且具备以下关键特性：
- 脚本执行期间不会被打断
- 脚本整体作为一个原子操作执行
- 不会插入其他客户端请求
Redis 保证：Lua 脚本要么全部执行完成，要么完全不执行
1.1.2 Lua 脚本为什么是原子的？
本质原因只有一个：
Redis 是单线程执行命令的
Lua 脚本在 Redis 中的执行流程如下：
- 客户端发送
EVAL请求 - Redis 将脚本加入事件循环
- 脚本执行期间：
不会处理其他客户端请求
不会发生上下文切换
- 脚本执行完成后，才会继续处理下一个请求
因此，Lua 脚本中的多个 Redis 命令：
redis.call("GET", "key") redis.call("SET", "key", "value") redis.call("INCR", "counter")在 Redis 看来就是一个不可分割的整体操作。
1.1.3 Lua 脚本的工程优势
- 避免多次网络 RTT
- 避免并发条件竞争
- 保证复杂逻辑的强一致性
- 高性能，适合库存扣减、限流、分布式锁等场景
生产环境中，强烈推荐使用 Lua 脚本替代 Redis 事务
1.2 Redis 事务（MULTI / EXEC）
Redis 也提供了事务机制，但其行为与传统数据库事务完全不同。
1.2.1 Redis 事务的基本用法
MULTI SET key1 value1 INCR key2 EXEC执行流程：
MULTI：开启事务- 命令进入队列（并未执行）
EXEC：按顺序执行所有命令
1.2.2 Redis 事务的本质
Redis 事务的核心特点是：
- 不保证隔离性
- 不支持回滚
- 只保证：命令按顺序执行
如果中途某条命令执行失败：
- 不会回滚之前已经执行成功的命令
- 后续命令仍然会继续执行（运行时错误除外）
1.2.3 WATCH：乐观锁机制
Redis 提供WATCH key来实现乐观锁：
- 在
EXEC之前，如果被 WATCH 的 key 被修改 - 当前事务直接失败
但 WATCH 只是冲突检测机制，并不是完整事务隔离。
1.2.4 Redis 事务 vs Lua 脚本
| 对比项 | Redis 事务 | Lua 脚本 |
|---|---|---|
| 原子性 | ❌ 不完全 | ✅ 完全 |
| 回滚 | ❌ 不支持 | 不需要 |
| 并发安全 | 依赖 WATCH | 天然安全 |
| 性能 | 一般 | 高 |
| 生产推荐 | ❌ | ✅ |
二、Redis 日志与持久化机制
Redis 是内存数据库，但并不意味着数据不安全。
它通过日志与快照机制，在性能与可靠性之间取得平衡。
三、AOF（Append Only File）日志机制
3.1 AOF 的基本思想
AOF 采用命令日志方式：
将每一条写命令，按顺序追加到 AOF 文件中
示例：
SET key value INCR counter DEL user:13.2 AOF 的执行流程
- 客户端写请求到达
- Redis 执行命令（内存）
- 命令追加到 AOF 缓冲区
- 根据策略刷盘
3.3 AOF 刷盘策略
| 策略 | 描述 | 数据安全 | 性能 |
|---|---|---|---|
| always | 每条命令都刷盘 | 最强 | 最差 |
| everysec | 每秒刷一次 | 较强 | 推荐 |
| no | 交给 OS | 最弱 | 最好 |
生产环境通常使用everysec
3.4 AOF 重写机制（Rewrite）
AOF 会越来越大，因此 Redis 提供AOF Rewrite：
- 不再记录历史命令
- 只生成等价的最小命令集
- 在后台子进程完成
这是 Redis 高可用的重要设计。
四、RDB（Redis DataBase）快照机制
4.1 RDB 的基本思想
RDB 采用全量内存快照：
在某一时刻，将内存中的数据一次性保存到磁盘
生成.rdb文件。
4.2 RDB 的触发方式
- 手动：
SAVE / BGSAVE - 自动：
save 900 1 save 300 10 save 60 100004.3 RDB 的实现原理
fork()出子进程- 利用写时复制（Copy-On-Write）
- 主进程继续处理请求
- 子进程负责持久化
4.4 RDB 的优缺点
优点：
- 文件体积小
- 恢复速度快
- 适合备份与灾难恢复
缺点：
- 可能丢失较多数据
- 不适合高实时性场景
五、AOF 与 RDB 对比总结
| 维度 | AOF | RDB |
|---|---|---|
| 数据安全 | 高 | 一般 |
| 性能影响 | 较高 | 低 |
| 文件大小 | 大 | 小 |
| 恢复速度 | 慢 | 快 |
| 使用建议 | 主用 | 备份 |
最佳实践：AOF + RDB 同时开启
总结
Redis 的原子性核心来自单线程模型
Lua 脚本是 Redis 中最可靠的原子操作方案
Redis 事务并非传统事务，仅适合简单场景
AOF 保证数据安全，RDB 保证恢复效率
Redis 的设计本质是：用工程取舍换取极致性能