Redis 支持事务，但不支持事务回滚（Rollback），其事务机制的设计与关系型数据库存在显著差异。

Redis 事务的核心特性

• 原子性保证：
  通过 MULTI（开启事务）、EXEC（执行事务）命令实现。事务中的命令会被序列化并按顺序执行，且执行过程中不会被其他客户端命令打断，保证原子性。
• 无回滚机制：
  若事务中的某条命令执行失败（例如语法错误或操作数据类型不匹配），后续命令仍会继续执行，且不会自动撤销已执行的命令。

不支持回滚的设计原因

• 简化实现与提升性能：
  Redis 的设计哲学强调简单性与高性能。引入回滚机制需维护命令执行前的状态快照，显著增加实现复杂度和内存开销，影响吞吐量。
• 错误前置处理：
  Redis 在命令入队时进行语法检查（例如返回 QUEUED）。语法错误的命令会导致整个事务在 EXEC 时拒绝执行（原子性失败），而运行时错误（如对字符串执行 HINCRBY）仅影响当前命令。
• 适用场景定位：
  Redis 主要服务于缓存、分布式锁、计数器等高吞吐场景，对强一致性事务需求较低。牺牲回滚能力以换取更高的性能符合其核心定位。

替代方案

若业务需严格的 ACID 事务支持（尤其跨键操作）：

• 选用关系型数据库（如 MySQL、PostgreSQL）。
• 采用支持 ACID 事务的 NoSQL 数据库（如 MongoDB 4.0+ 的多文档事务、TiDB）。
• 通过 Lua 脚本在 Redis 中实现复杂操作的原子性（单脚本执行具有原子性）。