redis事务详解
Redis事务
- Redis事务
- 一. 基本概念
- 二. 相关命令
- 1. MULI(开启事务)
- 2. EXEC(执行事务)
- 3. DISCARD(取消事务)
- 4. WATCH(乐观锁监控)
- 三. 错误处理
- 四. 事务特性
- 五.乐观锁与悲观锁
- 乐观锁:
- 悲观锁:
- 六. 事务优缺点
- 七. 适用场景
Redis事务
一. 基本概念
Redis事务通过命令队列实现,用户将多个命令按顺序加入队列,最终通过EXEC
命令一次性执行。其特点是:
- **原子性:**队列中的命令要么全部执行,要么全部不执行(但存在例外情况,如运行时错误)。
- **隔离性:**事务执行期间不会被其他客户端的命令打断,所有命令按顺序串行执行。
- 无回滚机制:
Redis
不支持传统数据库的事务回滚,设计初衷是简化实现并提高性能。
二. 相关命令
1. MULI(开启事务)
后续所有命令被加入队列,返回QUEUED
表示入队成功。
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 value1
QUEUED
2. EXEC(执行事务)
执行队列中的所有命令,返回每个命令的结果。
127.0.0.1:6379> EXEC
1) OK
3. DISCARD(取消事务)
清空队列并退出事务状态。
127.0.0.1:6379> DISCARD
OK
4. WATCH(乐观锁监控)
监视一个或多个键,若在事务执行前这些键被修改,则事务自动取消。
127.0.0.1:6379> WATCH key1
OK
三. 错误处理
- 语法错误: 若在输入命令时, 命令语法错误, 则整个事务都不会执行。
- 运行错误:在提交事务执行命令时,若出现错误(如对
string 类型
执行set 类型
命令时), 则忽略此命令, 其他命令正常执行
四. 事务特性
原子性(Atomicity)
- 语法错误时保证原子性(全部不执行)。
- 运行时错误时部分执行,无法保证原子性。
一致性(Consistency)
- 无论事务成功或失败,数据始终保持合法状态(如语法错误回滚、运行时错误保留正确操作)。
隔离性(Isolation)
Redis
单线程执行命令,天然保证隔离性。- 通过
WATCH
实现乐观锁,避免其他客户端修改关键数据。
持久性(Durability)
- 依赖持久化机制:若开启
AOF
且配置为always
模式,事务完成后数据立即持久化;否则无法保证。
五.乐观锁与悲观锁
为了保证在高并发领域的数据一致性, redis
借鉴了数据库领域的 乐观锁
和 悲观锁
。
乐观锁:
通过 watch
命令在执行事务前指定 key
, 监视事务执行过程中key
是否发生变化 实现。若发生变化,则回滚事务。若未发生变化,则执行事务。
执行流程:
- 使用
WATCH key
监控目标键; - 开启事务(
MULTI
)并执行操作命令; - 提交事务(
EXEC
),此时若键被修改则事务失败,需重试
适用场景:
- 读多写少的高并发场景(如库存查询、抢票系统);
- 需要轻量级并发控制,避免阻塞其他客户端
悲观锁:
使用 SET key value NX EX timeout
指定独占锁, 使用 NX
和 EX
参数保证key
的独占性 和 指定过期时间
适用场景:
- 写操作频繁, 且需求强一致性
六. 事务优缺点
- 优点:
- 轻量级,执行效率高(无锁、单线程)。
WATCH
机制支持简单并发控制。
- 缺点:
- 不支持回滚,运行时错误需开发者处理。
- 持久性依赖配置,默认不保证。
七. 适用场景
-
批量执行命令(如更新多个键)。
-
结合
WATCH
实现简单乐观锁(如秒杀库存控制)。 -
要求命令顺序执行且无需复杂回滚的场景。