
# 一、Redis 事务是什么？
## 1.1Redis事务介绍
Redis 事务是一种**将多条命令打包、按顺序一次性执行**的机制。客户端发送 `MULTI` 开启事务后，后续命令不会立刻执行，而是进入队列；发送 `EXEC` 时，Redis 会一次性、连续地执行队列中的全部命令
## 1.2 Redis 事务保证了什么？
- **命令按顺序执行** — 事务中的命令会按照入队顺序依次执行
- **执行期间不被打断** — 事务执行过程中，不会被其他客户端的命令插队（单线程保证）
- **要么全部执行，要么全部不执行** — 但注意，这里的"不执行"只针对语法错误的情况
## 1.3 Redis 事务不保证什么？
- 没有执行后的回滚：某条命令执行失败，已执行的不会撤销
- 不是完整 ACID：没有 MySQL 那种隔离级别、MVCC、持久化提交语义
- 不能写复杂业务逻辑：事务内无法在客户端根据上一条命令的返回值决定下一条

## 1.4 事务核心命令
|命令|作用|
|:-:|:-:|
|`MULTI`|开启事务|
|`EXEC`|提交执行|
|`DISCARD`|取消事务|
|`WATCH`|监视 key（乐观锁）|
|`UNWATCH`|取消监视|
## 1.5 基本演示
   ```bash
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET user:1001:name "Lucy"
QUEUED
127.0.0.1:6379> INCR user:1001:login_count
QUEUED
127.0.0.1:6379> EXPIRE user:1001:name 3600
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (integer) 1
3) (integer) 1
```
# 二、事务的基本使用
## 2.1 事务的生命周期
执行模型：单线程 + 命令队列
Redis 服务端（经典模型）用单线程处理命令。事务在此基础上增加了一层客户端维度的命令队列
Redis 事务的实现可以分为三个阶段：

```

│  开启事务    │ ──→ │  命令入队    │ ──→ │  执行事务    │
│   MULTI       │     │   QUEUED        │          │     EXEC     │
```
## 2.2 开启事务
 `multi `命令用于开启事务
   ```bash
127.0.0.1:6379> MULTI
OK
```
⚠️multi命令 `不能嵌套 `使用，会报错单不会终止客户端事务状态
```bash
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> multi
(error) ERR MULTI calls can not be nested
```

## 2.3 命令入队
命令会按照先进先出（FIFO）的顺序出入列
```bash
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
```
## 2.4 执行事务/放弃事务
 `exec ` 执行事务
```请在此输入代码块语言
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
```
 `discard ` 放弃事务
```bash
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1111
QUEUED
127.0.0.1:6379(TX)> set k2 v2222
QUEUED
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
```
## 2.5 事务错误与回滚
事务执行中的错误分三类：
- 执行时错误
- 入列时错误+终止整个事务
- 入列时错误+不终止流程
### 1. 执行时错误
下面例子中，设置世界命令（expire k1 10hr）在执行期间发生了错误，事务也会继续执行，直到队列中所有命令执行完成
```请在此输入代码块语言
# 查询k1原始值
127.0.0.1:6379> get k1
"v1"
# 开启事务
127.0.0.1:6379> multi
OK
# 第一个命令
127.0.0.1:6379(TX)> set k1 v1111
QUEUED
# 第二个命令
127.0.0.1:6379(TX)> expire k1 10hr
QUEUED
# 第三个命令
127.0.0.1:6379(TX)> set k2 VB
QUEUED
#执行事务
127.0.0.1:6379(TX)> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
# 第一个命令执行成功
127.0.0.1:6379> get k1
"v1111"
# 第三个命令执行成功
127.0.0.1:6379> get k2
"VB"
```

### 2. 入列时错误导致事务结束

```请在此输入代码块语言
127.0.0.1:6379> get k1
"vA"
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 Value1
QUEUED
127.0.0.1:6379(TX)> set k2
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1
"vA"
```

### 3. 入列时错误不会导致事务结束
```请在此输入代码块语言
127.0.0.1:6379> get k1
"vA"
127.0.0.1:6379> get k2
"VB"
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> multi
(error) ERR MULTI calls can not be nested
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
```
## 2.6 WATCH乐观锁机制
`WATCH`  是 Redis 提供的**乐观锁（Optimistic Locking）**机制，用来解决并发场景下的数据竞争问题。
核心逻辑：
>**监视一个或多个 key，如果在事务执行（EXEC）前这些 key 被其他客户端修改了，则事务自动失败。**

```bash
WATCH balance              # 1. 监视 key 
GET balance                # 2. 读取当前值 → "100"                            
MULTI                      # 3. 开启事务
DECRBY balance 50          # 4. 入队
EXEC                       # 5. 提交
```
**两种结果：**
- 如果  balance在 WATCH 和 EXEC 之间**没被修改** → EXEC 正常执行，返回结果
- 如果 balance 被别人修改了 → EXEC 返回 nil（空），事务不执行

# 三、Redis事务的底层原理
## 3.1 客户端状态标记

在 Redis 源码中，每个客户端（`client` 结构体）都有一个 `flags` 字段：

```c
typedef struct client {
    uint64_t flags;          // 客户端状态标记
    multiState mstate;       // 事务状态
    // ...
} client;
```

当执行 `MULTI` 时，Redis 会给客户端打上 `CLIENT_MULTI` 标记：

```c
void multiCommand(client *c) {
    c->flags |= CLIENT_MULTI;  // 标记进入事务状态
    addReply(c, shared.ok);
}
```

## 3.2 命令队列（multiState）

事务命令存储在 `multiState` 结构中：

```c
typedef struct multiState {
    multiCmd *commands;     // 命令数组（动态扩容）
    int count;             // 已入队命令数
    // ...
} multiState;

typedef struct multiCmd {
    robj **argv;           // 命令参数
    int argc;             // 参数个数
    struct redisCommand *cmd;  // 命令指针
} multiCmd;
```

每次客户端发送命令时，Redis 会检查 `CLIENT_MULTI` 标记：
- 如果已标记且命令不是 `EXEC/DISCARD/MULTI/WATCH`，则将命令追加到 `mstate.commands` 数组
- 否则正常执行

## 3.3 EXEC 执行过程

```c
void execCommand(client *c) {
    // 1. 检查是否有 WATCH 的 key 被修改
    if (c->flags & CLIENT_DIRTY_CAS) {
        // WATCH 的 key 被修改，事务失败
        discardTransaction(c);
        return;
    }

    // 2. 检查是否有入队错误
    if (c->flags & CLIENT_DIRTY_EXEC) {
        // 有语法错误，事务丢弃
        discardTransaction(c);
        return;
    }

    // 3. 逐条执行队列中的命令
    for (int i = 0; i < c->mstate.count; i++) {
        call(c, CMD_CALL_FULL);  // 执行单条命令
    }

    // 4. 清理事务状态
    discardTransaction(c);
}
```

## 3.4 WATCH 的实现原理

WATCH 基于一个**全局字典**，key 是被监视的键名，value 是监视它的客户端列表：

```c
typedef struct redisDb {
    dict *watched_keys;   // key → list<client>
    // ...
} redisDb;
```

当任何写命令修改了一个被 WATCH 的 key 时，Redis 会遍历该 key 的客户端列表，给每个客户端打上 `CLIENT_DIRTY_CAS` 标记：

```c
void signalModifiedKey(client *c, robj *key) {
    // 找到所有 WATCH 这个 key 的客户端
    list *clients = dictFetchValue(db->watched_keys, key);
    // 给每个客户端标记"脏"
    listForEach(clients, client) {
        client->flags |= CLIENT_DIRTY_CAS;
    }
}
```

这样当该客户端执行 `EXEC` 时，检测到 `CLIENT_DIRTY_CAS`，直接返回失败。

## 3.5 为什么 Redis 事务不需要加锁？

Redis 是**单线程模型**执行命令。`EXEC` 时，队列中的所有命令在一个事件循环（event loop）中连
续执行，中间不会穿插其他客户端的命令。这就是天然的隔离性，无需锁机制。


# 四、 Redis事务和Mysql事务

## 4.1 总体对比
Redis 事务和 MySQL 事务都叫“事务”，但设计目标不同：
|维度|Redis事务|MySQL事务（InnoDB）|
|:-:|:-:|:-:|
|主要目标|批量原子执行一组命令|保证业务数据一致性|
|ACID|只强调 原子性（A），弱隔离、无传统回滚|完整 ACID|
|回滚|不支持命令执行中途回滚|`ROLLBACK` 可回滚|
|隔离|单线程串行执行，无 MVCC|有隔离级别、行锁、MVCC|
|持久性|依赖 RDB/AOF，不等同于 DB commit|redo log + binlog，commit 后持久|
|典型场景|缓存、计数、分布式锁、限流|订单、支付、账务等强一致业务|

## 4.2 ACID 特性对比
| ACID | MySQL (InnoDB) | Redis |
|------|---------------|-------|
| **A（原子性）** | 完全保证，出错自动回滚 | 部分保证：语法错误全部丢弃；运行时错误**不回滚** |
| **C（一致性）** | 强一致（约束、触发器等） | 弱一致（无约束检查） |
| **I（隔离性）** | 4种隔离级别（读未提交→串行化） | 天然串行（单线程），相当于"串行化"级别 |
| **D（持久性）** | redo log 保证崩溃恢复 | 取决于 RDB/AOF 配置，默认可能丢数据 |
### 用转账例子理解差异
MySQL：天然适合「账户扣款 + 入账」在同一事务里，失败整体回滚。
START TRANSACTION;
UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT;
Redis：没有 `ROLLBACK`。即使 `MULTI` 里两条都成功，也无法自动保证「总额守恒」——业务约束要自己在应用或 Lua 里实现，且仍不如 InnoDB 可靠

## 4.3 使用场景对比

| 场景 | 推荐 |
|------|------|
| 银行转账、订单支付 | MySQL（需要强一致性和回滚） |
| 批量更新缓存 | Redis 事务 |
| 库存扣减（高并发） | Redis + Lua 脚本 |
| 复杂业务逻辑 | MySQL |
## 4.4 并发控制对比
| 机制 | MySQL | Redis |
|------|-------|-------|
| 悲观锁 | `SELECT ... FOR UPDATE` | 不支持（单线程无需） |
| 乐观锁 | 版本号字段 | `WATCH` 命令 |
| 行锁/表锁 | 支持 | 不支持（无需） |
## 4.5 Redis 为何不支持回滚？
Redis 官方给出的理由：
1. Redis 命令执行出错只有两种情况：语法错误（EXEC 前就能发现）或对 key 使用了错误类型的命令（这是编程 bug）
2. 不需要为编程 bug 设计回滚机制，因为生产环境不应该出现这种错误
3. 去掉回滚使 Redis 内部实现更简单、性能更高

# 五、Redis的Lua脚本
## 5.1 Lua介绍与Redis中Lua使用
[Lua是什么以及为啥在Redis中使用Lua？](https://cloud.tencent.com/developer/article/2706313) 

### 5.2 Lua与Redis事务
|维度|Redis事务(`MULTI`/`EXEC`)|RedisLua脚本|
|:-:|:-:|:-:|
|本质|把多条命令排队，一次性执行|在服务端执行一段脚本，脚本内多次 Redis 调用|
|原子性|有：EXEC 时整批命令不被其他客户端打断|有：整个脚本执行期间不被打断|
|条件逻辑|弱：排队阶段不能根据读结果动态决定写|强：可 `if/else`、循环、计算|
|乐观锁|靠 `WATCH` + `MULTI` + `EXEC`（CAS）|脚本内直接读-判断-写|
|回滚|无：某条命令执行失败，其余仍会执行|无：出错后已执行的写不会自动撤销|
|网络往返|一次 `MULTI + N条命令 + EXEC`|一次 `EVAL`/`EVALSHA`|
|复杂度|低，客户端易理解|较高，脚本维护、调试成本更高|
|集群|多 key 需在同一 slot|`KEYS` 参数中的 key 需在同一 slot|
   


Redis 事务是一种将多条命令打包、按顺序一次性执行的机制。客户端发送 MULTI 开启事务后，后续命令不会立刻执行，而是进入队列；发送 EXEC 时，Redis 会一次性、连续地执行队列中的全部命令

Redis事务——Redis系列(八)

后端

Redis事务是一种将多条命令打包执行的机制，通过MULTI开启事务、EXEC提交执行，保证命令按顺序执行且不被打断。虽然不支持回滚和完整ACID特性，但通过WATCH实现乐观锁机制，适合缓存更新等场景。与MySQL事务不同，Redis事务更注重批量执行而非强一致性。

数据一致性

代码解释

MySQL

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis事务——Redis系列(八)-腾讯云开发者社区-腾讯云

Redis事务——Redis系列(八)

Redis事务——Redis系列(八)

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐