Redis 事务到底是什么？

原创 于 2025-10-01 11:45:00 发布 · 1.1k 阅读 · 26 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #数据库 #缓存

一、Redis 事务的基本概念

1.1 什么是 Redis 事务

Redis 事务是一组命令的集合，它允许将多个命令打包，然后一次性、按顺序地执行。在事务执行期间，不会被其他客户端发送的命令打断，保证了事务内命令的原子性（这里的原子性与传统关系型数据库有所区别，后续会详细说明）。简单来说，Redis 事务就是 "要么全部执行，要么全部不执行"（在不考虑中途出错的特殊情况时）。

Redis 事务通过以下三个核心命令实现：

  • MULTI：标记事务开始
  • EXEC：执行事务中的所有命令
  • DISCARD：取消事务，放弃执行事务块内的所有命令

实际应用场景示例

  1. 电商系统：

    • 用户下单时需要扣减商品库存、创建订单记录
    • 这两个操作可以放在一个 Redis 事务中执行
    • 确保这两个操作要么都成功，要么都失败
    • 避免出现库存扣减了但订单没创建，或者订单创建了但库存没扣减的情况

  2. 社交网络：

    • 用户关注某人时需要更新双方的关注/粉丝列表
    • 这两个更新操作可以放在同一事务中

  3. 游戏系统：

    • 玩家交易物品时需要同时减少卖方物品和增加买方物品
    • 这两个操作可以原子性地执行

1.2 Redis 事务与传统数据库事务的区别

传统关系型数据库（如 MySQL）的事务遵循 ACID 原则（原子性、一致性、隔离性、持久性），而 Redis 事务在特性上与传统数据库事务存在显著差异：

特性传统关系型数据库事务Redis 事务
原子性严格支持，事务内操作要么全成功，要么全回滚部分支持，事务内命令执行中出错时：<br>- 已执行命令无法回滚<br>- 未执行命令不再执行
一致性严格保证，事务执行前后数据满足完整性约束基本保证，需要依赖开发者：<br>- 合理设计命令序列<br>- 正确处理异常情况
隔离性支持多种隔离级别（读未提交、读已提交、可重复读、串行化）事务执行期间不会被其他命令打断，类似串行化隔离级别
持久性支持，通过事务日志等机制保证数据持久化依赖 Redis 的持久化策略（RDB、AOF），事务本身不直接保证持久性

关键差异分析

  1. 原子性实现方式：

    • MySQL：通过回滚日志(undo log)实现回滚
    • Redis：没有回滚机制，错误发生后继续执行后续命令

  2. 隔离级别：

    • MySQL：提供多种隔离级别选择
    • Redis：只有一种类似串行化的隔离级别

  3. 错误处理：

    • MySQL：语法错误会导致整个事务回滚
    • Redis：语法错误会导致整个事务不执行，运行时错误不影响已执行命令

二、Redis 事务的相关命令

Redis 提供了一组专门用于操作事务的命令，这些命令构成了 Redis 事务功能的核心。掌握这些命令的用法对于在分布式环境中确保数据操作的原子性至关重要。下面详细介绍每个命令的功能、语法、使用场景及实际应用示例。

2.1 MULTI：开启事务

MULTI命令用于标记一个事务的开始，执行该命令后，Redis 会进入事务模式。在此模式下，客户端发送的所有命令都会被放入事务队列中暂存，而不是立即执行。

语法

MULTI

使用示例

127..0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET user:1001:name "张三"
QUEUED
127.0.0.1:6379(TX)> INCR user:1001:visits
QUEUED

详细说明

  1. 执行MULTI命令后，Redis 会返回OK响应，表示已成功进入事务模式
  2. 此时客户端提示符会从127.0.0.1:6379>变为127.0.0.1:6379(TX)>，表示当前处于事务上下文
  3. 后续所有非事务控制命令（如SET、GET等）都会被服务器返回QUEUED响应，表示命令已加入事务队列
  4. 事务队列中的命令会按照先进先出(FIFO)的顺序保存

2.2 EXEC：执行事务

EXEC命令用于触发事务的执行，Redis 会按顺序执行事务队列中的所有命令。该命令是确保事务原子性的关键操作。

语法

EXEC

使用示例

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET cart:1001:item1 "手机"
QUEUED
127.0.0.1:6379(TX)> SET cart:1001:item2 "耳机"
QUEUED
127.0.0.1:6379(TX)> EXEC
1) OK
2) OK

详细说明

  1. 执行EXEC后，Redis 会依次执行队列中的所有命令
  2. 返回结果是一个数组，其中每个元素对应事务中一个命令的执行结果
  3. 如果事务中某个命令执行失败（如语法错误），不会影响其他命令的执行
  4. 事务执行后会自动取消所有WATCH的键
  5. 典型应用场景：电商购物车结算时，需要同时更新库存、订单和支付信息

2.3 DISCARD：取消事务

DISCARD命令用于显式地放弃当前事务，清空事务队列并退出事务状态。

语法

DISCARD

使用示例

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET temp:data "test"
QUEUED
127.0.0.1:6379(TX)> DISCARD
OK
127.0.0.1:6379> GET temp:data
(nil)

详细说明

  1. 执行DISCARD后，事务队列中的所有命令都会被丢弃
  2. 客户端会立即退出事务状态
  3. 所有被WATCH的键也会被自动取消监视
  4. 适用场景：当检测到业务条件不满足时，可以安全地取消事务而不会产生副作用

2.4 WATCH：监视键

WATCH命令实现了Redis的乐观锁机制，用于在事务执行前监控指定的键，如果这些键被其他客户端修改，则当前客户端的事务会被拒绝执行。

语法

WATCH key [key ...]

使用示例

情况一：监视的键未被修改
# 客户端A
127.0.0.1:6379> WATCH account:1001:balance
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> DECRBY account:1001:balance 50
QUEUED
127.0.0.1:6379(TX)> INCRBY account:1002:balance 50
QUEUED
127.0.0.1:6379(TX)> EXEC
1) (integer) 450
2) (integer) 550

情况二：监视的键被其他客户端修改
# 客户端A
127.0.0.1:6379> WATCH inventory:item001
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> DECR inventory:item001
QUEUED

# 客户端B在其他连接中执行
127.0.0.1:6379> DECR inventory:item001
(integer) 99

# 客户端A
127.0.0.1:6379(TX)> EXEC
(nil)

详细说明

  1. WATCH可以监视一个或多个键
  2. 监视会持续到EXEC命令执行（事务成功或失败）
  3. 如果被监视的键在WATCH之后、EXEC之前被修改，整个事务会被取消
  4. 典型应用场景：账户转账、库存扣减等需要保证数据一致性的操作
  5. 监视机制是Redis实现CAS(Check-And-Set)操作的基础

2.5 UNWATCH：取消监视

UNWATCH命令用于显式取消对所有键的监视，通常在确定不需要继续监视或者需要更改监视策略时使用。

语法

UNWATCH

使用示例

127.0.0.1:6379> WATCH order:status user:1001:credits
OK
127.0.0.1:6379> UNWATCH
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET test "value"
QUEUED
127.0.0.1:6379(TX)> EXEC
1) OK

详细说明

  1. 执行UNWATCH后，所有被WATCH的键都会被取消监视
  2. 事务执行成功(EXEC)或取消(DISCARD)时也会自动执行UNWATCH
  3. 适用场景：当业务逻辑发生变化，不再需要之前监视的键时
  4. 注意：UNWOSTCH不能只取消对特定键的监视，它会取消所有键的监视

事务命令综合使用建议

  1. 将WATCH、MULTI/EXEC组合使用可以实现可靠的乐观锁
  2. 事务中的命令不宜过多，建议控制在合理范围内以避免长时间阻塞
  3. Redis事务不支持回滚，需要开发者自行处理部分失败的情况
  4. 在集群模式下，所有事务操作必须落在同一个节点上（使用相同的hash slot）

三、Redis 事务的执行流程详解

3.1 开启事务（MULTI）

客户端通过发送MULTI命令来显式地开启一个Redis事务。当Redis服务器接收到MULTI命令后，会进行以下操作：

  1. 将客户端的状态标志flags中的REDIS_MULTI位设置为1，表示该客户端已进入事务状态
  2. 初始化一个空的事务命令队列（FIFO队列），用于存储后续接收到的命令
  3. 返回"OK"响应给客户端，表示事务已成功开启

例如，在Redis-cli中执行：

127.0.0.1:6379> MULTI
OK

3.2 添加命令到事务队列

在事务开启后（MULTI之后，EXEC之前），客户端发送的所有常规Redis命令都不会立即执行，而是被加入事务队列。具体流程如下：

  1. 命令入队检查：

    • 服务器首先检查命令语法是否正确（参数数量、参数类型等）
    • 如果语法错误（如命令不存在或参数错误），立即返回错误信息，如(error) ERR unknown command 'SETX'
    • 如果语法正确，将命令封装为事务队列节点并加入队列

  2. 入队响应：

    • 对于成功入队的命令，统一返回"QUEUED"响应
    • 例如： 
      127.0.0.1:6379> SET key1 value1
QUEUED
127.0.0.1:6379> INCR key2
QUEUED

  3. 注意事项：

    • 不会检查命令的逻辑可行性（如对字符串执行INCR）
    • 不支持事务中的事务（嵌套MULTI会被拒绝）
    • 某些命令（如INFO、SHUTDOWN等）会被立即执行而不会入队

3.3 执行或取消事务

3.3.1 执行事务（EXEC）

当客户端发送EXEC命令时，Redis会：

  1. 前置检查：

    • 验证客户端是否处于事务状态
    • 检查事务队列是否为空（空队列执行会返回错误）

  2. 执行阶段：

    • 按FIFO顺序依次执行队列中的所有命令
    • 每个命令执行时：
      • 检查键类型是否正确（如对字符串执行LPUSH会报错）
      • 执行过程中某个命令失败不会影响其他命令的执行
      • 不会自动回滚已执行的命令

  3. 结果返回：

    • 将所有命令的执行结果按顺序放入数组返回
    • 例如： 
      1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value

  4. 状态清理：

    • 清除客户端的REDIS_MULTI标志
    • 清空事务队列
    • 取消所有WATCH的键

3.3.2 取消事务（DISCARD）

当客户端发送DISCARD命令时：

  1. 立即清空事务队列中的所有命令
  2. 将客户端状态从事务状态恢复为普通状态
  3. 取消所有被WATCH的键
  4. 返回"OK"表示事务已取消

典型应用场景：当客户端发现事务中的命令可能有问题时，可以主动放弃当前事务。

3.4 带有WATCH的乐观锁事务

3.4.1 WATCH机制详解

WATCH命令为Redis事务提供了CAS（Check-And-Set）功能：

  1. 工作原理：

    • 客户端可以WATCH任意数量的键
    • Redis会记录这些键的版本号（通过数据库的dirty计数器实现）
    • 如果在WATCH和EXEC之间这些键被修改过（包括过期），事务将失败

  2. 使用示例：

    127.0.0.1:6379> WATCH balance
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> INCRBY balance 100
QUEUED
127.0.0.1:6379> EXEC
(nil)  # 如果balance在WATCH后被其他客户端修改过

3.4.2 执行流程差异

相比普通事务，带WATCH的事务在EXEC时会额外执行：

  1. 版本检查：

    • 比较被WATCH键的当前版本号与WATCH时的版本号
    • 如果任何键的版本号不匹配，说明键已被修改

  2. 处理结果：

    • 如果有键被修改：返回nil表示事务失败，不执行任何命令
    • 如果所有键未修改：正常执行事务队列中的所有命令

  3. 注意事项：

    • WATCH的效果只对下一次EXEC有效
    • UNWATCH可以手动取消所有WATCH的键
    • WATCH的键即使被其他命令修改（如EXPIRE）也会导致事务失败

四、Redis 事务的特性深入分析

4.1 atomicity（原子性）

原子性是事务的核心特性之一，传统数据库事务的原子性是指事务内的操作要么全部执行成功，要么全部执行失败odel不会出现部分执行的情况。而 Redis 事务的原子性与传统数据库有所不同，需要分情况讨论：

情况 1：事务队列中存在语法错误的命令

详细说明： 当使用MULTI开启事务后，如果在命令peer-queueing阶段(即命令入队时)就出现语法错误，Redis会立即拒绝饶命令，moslem整个事务都不会被执行。这种在命令入队阶段就能检测到的错误称为"编译"错误。

典型场景：

  • 命令参数个数错误
  • 命令拼写错误
  • 使用了不存在的命令

示例详解：

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> readd key1Platform value7  # 拼写错误
(error) ERR unknown command 'readd'
127.0.0.1:6379(TX)> SET key8  # 缺少value参数
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

影响范围：

  • 整个事务会被完全放弃
  • 不会修改任何数据
  • 客户端需要重新发起isco整个事务

情况 2：事务队列中存在逻辑问题

详细说明： 当命令语法正确但存在运行时错误时sun, Redis会执行所有正确的命令，仅对错误的命令返回错误信息。这种在读red执行阶段才能发现的错误称为"错误。

典型场景：

  • 对字符串类型执行IN模tonumber操作
  • 对不存在的键执行类操作
  • 类型不匹配的操作

示例深入分析：

127.0.0.1:6379> SET counter "100"
OK
127.0.0.1:6379> MULTI
OK
127仴.0 backend.1:637(TX)> INCR counter  # 正常执行
QUEUED
127.0.0.1:6379(TX)> LPUSH counter 200  # 类型错误
QUEUED
127.0.0.1:6379(TX)> SET status "done"
QUEUED
127.0.0.1:6379(TX)> EXEC
1) (integer) 101  # 成功
2) (error) WRONGTYPE Operation against a key having the wrong kind of value  # 错误
3) OK  # 成功
127.0.0.1:6379> GET counter
"101"  # 前一命令已执行
127.0.0.1:6379> GET status
"done"  # 后一命令也执行了

影响分析：：

  • 事务中部分命令成功执行
  • 会修改部分数据
  • 需要在客户端处理部分成功的情况

情况 3：客户端连接中断

详细说明： 如果在MULTI后但EXEC前连接断开，Redis会自动丢弃该客户端的事务队列。

恢复机制：

  • 客户端需要重建连接
  • 需要重新发起整个事务
  • 可以使用WATCH命令防止数据变更

情况 4：服务器崩溃

持久化策略分析：

1.无持久化：

  • anecdotal数据完全丢失
  • 事务相当于从未执行

2.RDB持久化：

  • 取决于最近一次快照时间 Objetivo- 可能丢失最近的事务(若未触发快照)
  • 已快照过程中崩溃可能导致文件损坏

3.AOF模式：

  • Aappendakisync always 情况下:
    • 每个命令都会写入磁盘
    • 崩溃后Officer事务可能部分执行
  • appendfsync everysec 情况下:
    • 可能丢失最后1秒的数据
  • appendfsync no 情况下:
    • 依赖操作系统刷盘时机

最佳实践建议：

1.对于关键数据，建议：

  • 使用WATCH命令实现乐观锁
  • 在应用层实现补偿机制
  • 必要时结合Lua脚本保证原子性

2.持久化配置建议 Innocent:

  • 生产环境推荐RDB+AOF混合使用
  • AOF建议配置 clustersappendfsync everysec
  • 对于极高一致性要求的场景，可考虑always模式

3.监控与恢复: 下载

  • 定期检查Redis日志
  • 实现监控告警机制
  • 准备数据恢复预案

总结： Redis事务的原子性特性需要根据具体场景来评估，在设计系统时应该充分考虑这种部分原子性特征，并采取相应的补偿措施来保证数据一致性。

4.2 一致性

一致性是指事务执行前后，数据库从一个合法状态转变为另一个合法状态，保证数据的完整性约束没有被破坏。在 Redis 中，事务的一致性保障机制相对简单，主要依赖于开发者合理设计命令和处理异常情况。根据事务执行过程中是否出现错误，Redis 事务的一致性可以分为以下几种典型场景：

情况 1：事务执行前没有错误（命令语法正确、无逻辑错误）

在这种理想情况下，所有命令都符合 Redis 语法规范且逻辑正确，事务执行后数据将保持完全一致。具体表现为：

  1. 事务队列中的所有命令都会按FIFO（先进先出）顺序执行
  2. 执行过程中不会出现命令失败的情况
  3. 数据从一个合法状态转变为另一个合法状态

典型应用场景：银行转账业务

MULTI
DECRBY account:A 100
INCRBY account:B 100
EXEC

在这个例子中，如果账户A有足够余额且两个账户都存在，执行后账户A减少100元，账户B增加100元，总金额保持不变，满足业务约束条件。

情况 2：事务执行前存在语法错误

Redis 采用"预检查"机制来保证一致性：

  1. 在命令入队时就会进行语法检查
  2. 如果发现语法错误（如命令不存在、参数数量错误等），整个事务会被标记为失败
  3. 执行EXEC时将拒绝执行整个事务队列

错误示例：

MULTI
SET key1 value1
SETT key2 value2  # 错误命令
SET key3 value3
EXEC

此时由于SETT命令语法错误，所有命令都不会执行，数据库保持原状。

情况 3：事务执行前存在逻辑错误

这类错误更隐蔽且需要开发者特别注意：

  1. 命令语法正确但执行时可能失败（如对字符串执行INCR操作）
  2. Redis不会自动回滚已执行的命令
  3. 需要开发者自行实现补偿机制

典型场景：库存管理

MULTI
DECR stock  # 扣减库存
INCR orders  # 增加订单
EXEC

如果orders键是字符串类型，INCR操作会失败，但库存已被扣减。此时应该：

# 检查执行结果
results = EXEC
if results[1] is error:
    INCR stock  # 手动回滚

情况 4：执行EXEC时服务器崩溃

这种情况下的一致性取决于持久化配置：

  1. 无持久化：

    • 数据完全丢失
    • 系统重启后处于初始空状态
    • 从业务角度看可能违反一致性约束

  2. RDB持久化：

    • 崩溃时未触发RDB快照：等同无持久化
    • 崩溃时正在写RDB：可能导致损坏的快照文件
    • 能恢复到最后一次成功快照的状态

  3. AOF持久化：

    • appendfsync always：基本能保证事务持久性
    • appendfsync everysec：可能丢失最近1秒的数据
    • AOF重写时崩溃：需使用redis-check-aof工具修复

建议解决方案：

  • 关键业务建议使用AOF+everysec配置
  • 结合WAL（Write-Ahead Logging）模式
  • 定期备份RDB文件到异地

4.3 隔离性

Redis通过单线程模型和特殊的事务机制提供强隔离性保障：

事务执行原子性

  1. 命令队列特性：

    • MULTI开始事务后，所有命令进入队列
    • EXEC时队列命令作为整体执行
    • 执行期间不会被其他客户端命令打断

  2. 网络层隔离：

    • 事务执行期间独占网络I/O
    • 其他客户端命令进入等待队列
    • 类似传统数据库的表级锁

示例时序：

Client1: MULTI
Client1: SET x 1
Client2: SET x 2  # 被阻塞
Client1: EXEC     # 先执行
Client2: SET x 2  # 后执行

WATCH机制

  1. 乐观锁实现：

    WATCH key
val = GET key
MULTI
SET key newVal
EXEC  # 如果key被修改则失败

  2. 监控原理：

    • 维护被监视键的版本号
    • EXEC时检查版本是否变化
    • 变化则放弃整个事务

  3. 典型应用：

    • 秒杀系统库存扣减
    • 账户余额检查
    • 分布式锁实现

隔离级别对比

特性Redis事务SQL Serializable
脏读不可能不可能
不可重复读可能*不可能
幻读可能*不可能
实现机制单线程锁机制

4.4 持久性

RDB持久化细节

  1. 触发机制：

    • save 900 1（15分钟1次修改）
    • save 300 10（5分钟10次修改）
    • save 60 10000（1分钟10000次修改）
    • 手动SAVE/BGSAVE命令

  2. 事务影响：

    • 执行期间不阻塞事务
    • 但可能丢失两次快照间的事务
    • 建议配置：stop-writes-on-bgsave-error yes

AOF持久化优化

  • 写入策略对比：
配置持久性保证性能影响适用场景
appendfsync always最高最大金融交易
appendfsync everysec中等中等大多数业务
appendfsync no最低最小可丢失数据场景
  • 重写机制：
    • 自动压缩AOF文件
    • BGREWRITEAOF触发
    • 重写期间新命令写入缓冲区

混合持久化方案

推荐配置：

appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes  # 混合模式
save 900 1                # RDB备份

优势：

  • 快速恢复（RDB）
  • 数据安全（AOF）
  • 重写效率高（混合）

崩溃恢复流程

  1. 检查AOF文件完整性
  2. 加载RDB基础数据
  3. 重放AOF增量命令
  4. 数据一致性校验（可选）

五、Redis 事务的常见问题及解决方案

5.1 问题1：事务执行失败导致数据不一致

问题本质与复现

Redis 事务的"部分原子性"特性导致当遇到逻辑错误时，事务会部分执行而非整体回滚。这与传统关系型数据库的事务行为有显著差异。具体表现为：事务队列中某个命令执行失败时，Redis 会跳过该错误命令，继续执行后续命令，而不是回滚整个事务。

典型复现场景：

  1. 电商系统中同时执行库存扣减和订单创建
  2. 订单键被错误地设置为字符串类型，而业务代码却尝试使用哈希命令(HSET)
  3. 导致库存扣减成功但订单创建失败

详细复现步骤

# 1. 初始化库存（字符串类型）
127.0.0.1:6379> SET product:stock:1001 10
OK

# 2. 开启事务，包含错误命令
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> DECRBY product:stock:1001 2  # 正确命令
QUEUED
127.0.0.1:6379(TX)> HSET order:3001 product_id 1001 quantity 2  # 错误命令（键类型不匹配）
QUEUED
127.0.0.1:6379(TX)> EXEC
1) (integer) 8  # 库存扣减成功
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value  # 订单创建失败

# 3. 验证数据状态
127.0.0.1:6379> GET product:stock:1001
"8"  # 库存已扣减
127.0.0.1:6379> GET order:3001
(nil)  # 订单未创建

解决方案：三层防护机制

方案1：事前检查键类型与业务规则

在事务执行前进行全面的数据校验：

  1. 检查键是否存在
  2. 验证键类型是否正确
  3. 检查业务数据是否满足条件（如库存是否充足）

Python实现示例：

def check_stock_validity(stock_key, reduce_num):
    # 检查键类型
    if r.type(stock_key) != b'string':
        return False, "键类型错误"
    
    # 检查库存充足性
    current_stock = int(r.get(stock_key))
    if current_stock < reduce_num:
        return False, "库存不足"
    
    return True, "校验通过"

# 使用示例
valid, msg = check_stock_validity("product:stock:1001", 2)
if not valid:
    print(f"事务终止：{msg}")
else:
    # 执行事务...

方案2：使用Lua脚本替代事务（推荐）

Lua脚本在Redis中的执行是原子性的，且支持复杂逻辑判断：

优势：

  1. 完整的原子性保证
  2. 支持条件判断和业务逻辑
  3. 执行效率更高

库存扣减Lua脚本示例：

-- 参数说明：
-- KEYS[1]: 库存键
-- KEYS[2]: 订单键
-- ARGV[1]: 扣减数量
-- ARGV[2]: 商品ID

-- 1. 数据校验
local stock = tonumber(redis.call('GET', KEYS[1]))
if not stock or stock < tonumber(ARGV[1]) then
    return {false, "库存不足"}
end

-- 2. 执行操作
redis.call('DECRBY', KEYS[1], ARGV[1])
redis.call('HSET', KEYS[2], 'product_id', ARGV[2], 'quantity', ARGV[1])

return {true, "操作成功"}

方案3：事后主动回滚

当发生部分失败时，实现补偿机制：

实现要点：

  1. 记录操作日志
  2. 设计回滚逻辑
  3. 确保回滚操作的幂等性

Python回滚示例：

try:
    # 执行事务
    result = pipe.execute()
except Exception as e:
    # 检查哪些操作已执行
    if 'result' in locals() and result and isinstance(result[0], int):
        # 执行回滚
        r.incrby(stock_key, result[0])
        print(f"已回滚库存，错误：{e}")

5.2 问题2：并发竞争引发脏数据

问题本质与复现

并发场景下多个客户端同时修改同一数据，导致数据不一致。典型表现为：

  1. 超卖（库存扣减为负数）
  2. 超扣（实际扣减量大于预期）

复现代码：

import threading

def reduce_stock():
    current = int(r.get('stock'))
    if current > 0:
        r.decr('stock')

# 启动20个线程并发扣减初始为10的库存
threads = [threading.Thread(target=reduce_stock) for _ in range(20)]
[t.start() for t in threads]
[t.join() for t in threads]

print(r.get('stock'))  # 可能为负数

解决方案

方案1：乐观锁（WATCH命令）

适用场景：并发量中等，冲突概率较低

实现步骤：

  1. WATCH监视关键键
  2. 获取当前值
  3. 在事务中执行修改
  4. 处理冲突（重试机制）

Python实现：

def optimistic_lock(key, max_retry=3):
    for _ in range(max_retry):
        try:
            r.watch(key)
            current = int(r.get(key))
            if current <= 0:
                break
                
            pipe = r.pipeline()
            pipe.multi()
            pipe.decr(key)
            if pipe.execute():
                return True
        except WatchError:
            continue
    return False

方案2：分布式锁

适用场景：高并发，强一致性要求

实现方案：

  1. 使用SETNX实现简单锁
  2. 考虑锁超时机制
  3. 实现锁续期

Python示例：

def acquire_lock(lock_name, acquire_timeout=10, lock_timeout=10):
    end = time.time() + acquire_timeout
    while time.time() < end:
        if r.set(lock_name, 'locked', nx=True, ex=lock_timeout):
            return True
        time.sleep(0.1)
    return False

def release_lock(lock_name):
    r.delete(lock_name)

Redis 的并发竞争问题是什么？如何解决这个问题？了解 Redis 事务的 CAS 方案吗？
悟已往之不谏，知来者之可追
05-10 636
问题 Redis 的并发竞争问题是什么？如何解决这个问题？了解 Redis 事务的 CAS 方案吗？ 分析 这个也是线上非常常见的一个问题，就是多客户端同时并发写一个 key，可能本来应该先到的数据后到了，导致数据版本错了；或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了。 而且 Redis 自己就有天然解决这个问题的 CAS 类的乐观锁方案。 某个时刻，多个系统实例都去更新某个 key。可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式
12.Redis 事务有何意义？
爱欧米
12-14 1156
Redis事务通常会使用MULTI,EXEC,WATCH,DISCARD,UNWATCH,WATCH key [key ...]等命令来完成, Redis实现事务实现的机制与常见的关系型数据库事务特征总结如下。 BD与Redis事务差异 异同 BD事务 redis事务 相同点 事务在提交前不可见 不同点 1.redis不支持回滚 2.redis事务执行期间不会锁定待修改key,其他非事务修改可以修改此key 3.非ACID标准 Redis 事务可以一次执行多个命令..
Redis 事务
weixin_45080272的博客
03-22 8083
使用watch检测balance，在开启事务后（标注1处），在新窗口执行标注2中的操作，更改balance的值，模拟其他客户端在事务执行期间更改watch监控的数据，然后再执行标注1后命令，执行EXEC后，事务未成功执行。基于这样的问题，提出了redis分布式锁，你加一把锁，每一个用户过来的时候都需要获取这把锁，只有获取这把锁的时候才能操作成功，没有获取锁的话，操作失败。基于上面的问题，那我在一个客户端操作的时候，把所有的指令一次性按照顺序排他的放在一个队列中，执行完了之后再让其他的客户端操作。
Redis事务详解
热门推荐
怪咖@的博客
05-30 1万+
事务是指一个完整的动作，要么全部执行，要么什么也没有做。Redis 事务不是严格意义上的事务，只是用于帮助用户在一个步骤中执行多个命令。单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以Redis 事务的执行并不是原子性的。Redis 事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。
掌握 Redis 事务，提升数据处理效率的必备秘籍
禅与计算机程序设计的艺术
10-21 8674
那么，如何在项目中正确、高效地使用Redis事务呢？，该锁的总是乐观的认为自己操作的数据不会被他人修改，进行修改操作时不会针对临界资源上锁，而是修改的时候判断一下当前去数据版本号和修改的数据是否一致，通过比对版本号是否一致判断是否被人修改，只要版本号一致当前线程修改操作就会生效，常见的解决方案有悲观锁和乐观锁，悲观锁(Pessimistic Lock)的原理是认为自己操作的数据很可能会被他人修改，所以对临界资源操作都持有悲观的态度，每次进行操作前都会对数据上锁保证互斥，常见的关系型数据库。
Redis学习文档
cuishujian_2003的博客
10-21 1083
Redis 事务实际开发中使用的非常少，功能比较鸡肋，不要将其和我们平时理解的关系型数据库的事务混淆了。除了不满足原子性和持久性之外，事务中的每条命令都会与 Redis 服务器进行网络交互，这是比较浪费资源的行为。明明一次批量执行多个命令就可以了，这种操作实在是看不懂。因此，Redis 事务是不建议在日常开发中使用的Redis 可以通过 MULTIEXECDISCARDWATCH等命令来实现事务(Transaction)功能。
redis事务常用操作详解
12-16
在实际使用中，Redis事务适用于需要确保数据一致性的一系列操作，例如在更新用户余额时，需要同时增加用户的存款和减少其取款，这两个操作必须全部成功或全部失败，以防止数据不一致。通过事务，可以确保这样的操作...
redis事务实现原理
SO_zxn的博客
02-13 869
redis事务实现原理
redis 的并发竞争问题是什么？如何解决这个问题？了解 redis 事务的 CAS 方案吗？
02-14
redis 的并发竞争问题是什么？如何解决这个问题？了解 redis 事务的 CAS 方案吗？
[Redis][事务]详细讲解
SnowK博客
09-25 5200
[Redis][事务]详细讲解
Redis 事务：别再傻傻分不清，一文搞懂！
qq_56158663的博客
04-07 1925
秒懂 Redis 事务！告别晦涩，这篇大白话讲透了 👍
redis事务详解，带你搞懂redis的事务
秃了也弱了
06-01 1605
通过multi的命令开启事务，multi执行后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即执行，而是被放到一个队列中。Redis的事务涉及到四个命令：multi（开启事务），exec（执行事务），discard（取消事务），watch（监视）。我们发现，第一条命令是执行成功的，也就是在发生异常的情况下，之后错误的命令没有被执行，正确的命令还是执行成功，并没有被回滚。我们会发现，hset我们的语法有问题，事务会被拒绝执行，也就是队列中所有的命令都不会得到执行。如果中途不想执行事务了，怎么办？
Redis事务
做一个乐于分享的程序员
08-14 1996
redis事务，multi ,exec,discard
【Redis经典面试题七】Redis的事务机制是怎样的？
qq_38196449的博客
01-02 1500
Redis 的 Pipeline 机制是一种用于优化网络延迟的技术，主要用于在单个请求/响应周期内执行多个命令。在没有 Pipeline 的情况下，每执行一个 Redis 命令，客户端都需要等待服务器响应之后才能发送下一个命令。这种往返通信尤其在网络延迟较高的环境中会显著影响性能。在 Pipeline 模式下，客户端可以一次性发送多个命令到 Redis 服务器，而无需等待每个命令的响应。Redis 服务器接收到这批命令后，会依次执行它们并返回响应。
Redis的事务
m0_56340064的博客
09-24 3708
Redis事务
【Redis】事务
最新发布
2301_80224556的博客
08-11 1278
🔒1. 悲观锁 (Pessimistic Locking)“先加锁，再操作”。它悲观地认为冲突一定会发生。因此，在访问共享数据之前，必须先获得独占锁，阻止其他所有并发操作访问该数据，直到当前操作完成并释放锁。工作流程：线程/进程 A 在操作共享数据（如数据库记录、内存变量、文件）前，先获取该数据的独占锁。A 独占访问数据，执行读取、计算、修改等操作。在此期间，任何其他线程/进程 B 尝试获取该数据的锁都会被阻塞（Blocked）或失败。A 完成操作后，提交修改（如数据库事务提交），然后释放锁。
Redis 事务有什么缺陷？如何解决？
02-27
### Redis 事务的缺点 Redis 事务通过 `MULTI`、`EXEC`、`WATCH` 等命令实现，虽然提供了原子性的操作集合执行方式，但在实际应用中有一定的局限性和潜在问题。 #### 并发控制不足 当多个客户端尝试同时修改相同键...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值