3.1 事务 (Transactions)

3.1 事务 (Transactions)

Redis 高级特性：深入理解事务 (Transactions)

1. 什么是事务？

事务（Transaction）是一系列操作的逻辑单元，它具有以下关键特性（通常被称为 ACID 属性，但在 Redis 中，ACID 的实现有所不同，我们稍后会详细讨论）：

• 原子性（Atomicity）： 事务中的所有操作要么全部成功执行，要么全部不执行。不存在部分执行的情况。

• 一致性（Consistency）： 事务执行后，数据库从一个一致性状态转移到另一个一致性状态。这意味着事务应该遵守预定义的规则和约束，不会破坏数据的完整性。

• 隔离性（Isolation）： 并发执行的事务之间应该相互隔离，一个事务的执行不应该受到其他事务的干扰。

• 持久性（Durability）： 一旦事务提交成功，其结果应该永久保存在数据库中，即使系统发生故障也不会丢失。

在传统的关系型数据库（如 MySQL、PostgreSQL）中，事务通常具备完整的 ACID 属性。然而，Redis 的事务实现方式和侧重点有所不同。

2. Redis 事务的特性

Redis 事务并非完全符合传统 ACID 事务的所有属性，它更侧重于 原子性和隔离性，在一致性和持久性方面有所权衡。

• 原子性 (Atomicity): Redis 事务保证 隔离的操作序列 的原子执行。这意味着在 MULTI 和 EXEC 命令之间的所有命令会被当成一个整体顺序执行。然而，需要注意的是，Redis 的原子性是在 命令队列 级别保证的，而不是在单个命令级别。如果在 EXEC 执行之前，队列中的某个命令语法错误，整个事务会被取消执行。但在 EXEC 执行过程中，如果某个命令执行失败（例如类型错误），Redis 不会回滚整个事务，而是会继续执行队列中的后续命令。

• 一致性 (Consistency): Redis 事务尽力维护数据一致性。如果事务在执行前数据库是一致的，并且事务中的命令都是有效的，那么事务执行后数据库仍然会保持一致性状态。但是，Redis 不提供回滚机制 来应对运行时错误。如果在事务执行过程中出现错误（例如类型错误），Redis 会继续执行后续命令，但错误命令本身不会执行，这可能会导致与预期不符的一致性状态。开发者需要仔细处理事务中的命令，避免运行时错误。

• 隔离性 (Isolation): Redis 事务提供了 隔离性，但这种隔离性与关系型数据库的隔离级别有所不同。Redis 事务的隔离性主要是通过 串行化执行 来实现的。当客户端使用 MULTI 命令开启事务后，Redis 会将后续的命令放入队列中，直到遇到 EXEC 命令才开始执行队列中的命令。在 EXEC 执行期间，Redis 不会处理来自其他客户端的命令请求，从而保证了事务执行的隔离性。 然而，需要注意的是，Redis 的事务隔离性是 命令级别的隔离，而不是 行级别的隔离。如果多个事务同时修改同一个 key，Redis 会按照事务提交的顺序依次执行，后面的事务会覆盖前面的事务结果。为了解决并发修改的问题，Redis 提供了 WATCH 命令，来实现乐观锁机制。

• 持久性 (Durability): Redis 的持久性取决于配置的持久化方式（RDB 或 AOF）。如果配置了持久化，那么事务执行的结果最终会被写入磁盘，从而实现一定程度的持久性。但是，Redis 的持久性不是实时的，可能存在数据丢失的风险，尤其是在 Redis 服务崩溃但尚未进行持久化时。对于对数据持久性要求极高的场景，需要根据实际情况权衡 Redis 的持久化配置和性能。

总结 Redis 事务的特性:

• 原子性： 命令队列级别的原子性，保证队列中命令的整体执行。

• 一致性： 尽力维护一致性，但不提供回滚机制，运行时错误需要开发者处理。

• 隔离性： 命令级别的隔离，通过串行化执行实现，但非行级别隔离，需使用 WATCH 处理并发修改。

• 持久性： 取决于持久化配置，非实时持久化，可能存在数据丢失风险。

3. Redis 事务相关命令详解与实践

Redis 提供了几个关键的命令来支持事务操作：MULTI, EXEC, DISCARD, WATCH, 和 UNWATCH。

3.1 MULTI 命令

• 作用: 标记一个事务块的开始。在 MULTI 命令之后，客户端可以发送多个命令到服务器，这些命令会被缓存到一个队列中，而不是立即执行。

• 语法: MULTI

• 返回值: 总是返回 OK。

代码实践 (使用 redis-cli):

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 value1
QUEUED
127.0.0.1:6379> GET key1
QUEUED
127.0.0.1:6379> INCR counter
QUEUED
127.0.0.1:6379> SADD myset item1
QUEUED
​

在上面的例子中，我们使用 MULTI 命令开始了一个事务。之后，我们发送了 SET, GET, INCR, 和 SADD 四个命令。注意，服务器并没有立即执行这些命令，而是将它们放入队列中，并返回 QUEUED 状态。

详细解释:

当客户端发送 MULTI 命令后，Redis 服务器会为该客户端连接设置一个 "事务标志"。之后，服务器接收到来自该连接的命令时，不再立即执行，而是将命令添加到与该连接关联的事务队列中。这个过程会一直持续，直到客户端发送 EXEC 或 DISCARD 命令。

3.2 EXEC 命令

• 作用: 执行所有在 MULTI 和 EXEC 之间缓存的命令队列。

• 语法: EXEC

• 返回值:

  • 如果事务队列中的所有命令都成功执行，EXEC 返回一个命令回复数组，数组中的每个元素都是队列中对应命令的返回值。

  • 如果在 MULTI 之后，EXEC 之前有命令入队失败（例如语法错误），EXEC 会返回 (nil)，并且事务队列中的所有命令都不会被执行。

  • 如果使用了 WATCH 命令，并且被 WATCH 的 key 在 EXEC 执行之前被其他客户端修改过，EXEC 也会返回 (nil)，表示事务执行失败（稍后会详细介绍 WATCH 命令）。

代码实践 (继续上面的例子):

127.0.0.1:6379> EXEC
1) OK
2) "value1"
3) (integer) 1
4) (integer) 1
​

在上面的例子中，我们接着发送了 EXEC 命令。Redis 服务器开始执行事务队列中的命令。EXEC 返回一个数组，数组中的元素分别对应队列中 SET, GET, INCR, SADD 命令的执行结果。

详细解释:

当服务器收到 EXEC 命令时，它会检查事务队列。

• 没有错误: 如果队列中没有命令在入队时发生错误（例如语法错误），服务器会按照命令入队的顺序依次执行队列中的所有命令。执行过程中，Redis 会保持对数据库的独占访问，确保事务的隔离性。执行完成后，服务器会将每个命令的执行结果封装到一个数组中，并作为 EXEC 命令的返回值返回给客户端。

• 入队错误: 如果在 MULTI 和 EXEC 之间，有命令入队时发生错误（例如语法错误），Redis 会立即标记该事务为 "脏事务"。当客户端发送 EXEC 命令时，Redis 会发现事务是 "脏事务"，会拒绝执行队列中的任何命令，并返回 (nil)。这种机制可以防止执行包含语法错误的事务，保证数据的一致性。

• WATCH 冲突: 如果使用了 WATCH 命令，并且被 WATCH 的 key 在 EXEC 执行之前被其他客户端修改过，Redis 会检测到 WATCH 冲突，也会拒绝执行事务，并返回 (nil)。这是 WATCH 命令实现乐观锁的关键机制。

运行时错误处理:

需要特别注意的是，Redis 事务 不提供回滚机制 来处理运行时错误。如果在 EXEC 执行过程中，队列中的某个命令执行失败（例如类型错误），Redis 不会回滚整个事务，而是会 继续执行队列中的后续命令。

例如：

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET mykey "Hello"
QUEUED
127.0.0.1:6379> INCR mykey  // 对字符串执行 INCR，会产生类型错误
QUEUED
127.0.0.1:6379> GET mykey
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (error) ERR value is not an integer or out of range
3) "Hello"
​

在这个例子中，INCR mykey 命令尝试对字符串 "Hello" 执行自增操作，这会导致类型错误。但是，EXEC 命令仍然会执行事务队列中的其他命令。SET mykey "Hello" 命令成功执行，GET mykey 命令也成功执行并返回 "Hello"。只有 INCR mykey 命令执行失败，并返回错误信息。

因此，在使用 Redis 事务时，开发者需要 仔细检查事务队列中的命令，避免运行时错误，并根据实际情况处理可能出现的错误情况。

3.3 DISCARD 命令

• 作用: 取消事务，清空事务队列，放弃执行事务块中的所有命令。

• 语法: DISCARD

• 返回值: 总是返回 OK。

代码实践:

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key2 value2
QUEUED
127.0.0.1:6379> GET key2
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> GET key2
(nil)
​

在这个例子中，我们使用 MULTI 开始事务，添加了 SET 和 GET 命令到队列中，然后使用 DISCARD 命令取消了事务。最后，我们尝试获取 key2 的值，结果是 (nil)，说明事务队列中的命令没有被执行。

详细解释:

当客户端发送 DISCARD 命令时，Redis 服务器会清空与该客户端连接关联的事务队列，并取消 "事务标志"。之后，服务器接收到的命令会立即执行，不再放入事务队列。 DISCARD 命令用于在事务执行之前，客户端决定放弃事务操作，例如在事务构建过程中发现某些条件不满足，或者客户端需要撤销之前的操作。

3.4 WATCH 命令

• 作用: 监视一个或多个 key。如果在 WATCH 之后，EXEC 执行之前，被监视的 key 被其他客户端修改过，那么整个事务会被取消执行。WATCH 命令用于实现乐观锁机制。

• 语法: WATCH key [key ...]

• 返回值: 总是返回 OK。

代码实践 (乐观锁示例 - 库存管理):

假设我们有一个库存系统，使用 Redis 存储商品库存数量。我们需要实现一个原子操作，减少库存并返回剩余库存。

场景: 多个客户端同时尝试购买商品，需要保证库存数量不会出现超卖的情况。

代码示例:

// 客户端 1
127.0.0.1:6379> WATCH inventory:item1  // 客户端 1 监视 inventory:item1
OK
127.0.0.1:6379> GET inventory:item1  // 客户端 1 获取当前库存
"10"
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY inventory:item1 2 // 客户端 1 尝试减少库存 2
QUEUED
127.0.0.1:6379> EXEC  // 客户端 1 执行事务
// 客户端 2 (在客户端 1 执行 EXEC 之前)
127.0.0.1:6379> DECRBY inventory:item1 3 // 客户端 2 尝试减少库存 3 (在客户端 1 执行 EXEC 之前)
(integer) 7
// 客户端 1 的 EXEC 命令返回
127.0.0.1:6379> EXEC
(nil)  // 客户端 1 的事务执行失败，因为 inventory:item1 被客户端 2 修改过
127.0.0.1:6379> GET inventory:item1 // 客户端 1 重新获取库存
"7" // 库存已经被客户端 2 修改为 7
​

详细解释:

1. 客户端 1 使用 WATCH inventory:item1 监视 inventory:item1 这个 key。 Redis 会记录客户端 1 正在监视 inventory:item1。

2. 客户端 1 获取 inventory:item1 的当前值 (假设为 "10")。

3. 客户端 1 使用 MULTI 开始事务，并将 DECRBY inventory:item1 2 命令添加到队列中。

4. 在客户端 1 执行 EXEC 之前，客户端 2 也尝试减少 inventory:item1 的库存，并成功执行 DECRBY inventory:item1 3 命令。 此时，inventory:item1 的值变为 "7"。

5. 客户端 1 执行 EXEC 命令时，Redis 服务器会检查客户端 1 监视的 inventory:item1 是否被修改过。 由于客户端 2 修改了 inventory:item1，Redis 检测到 WATCH 冲突，客户端 1 的事务被取消执行，EXEC 返回 (nil)。

6. 客户端 1 需要重新获取最新的库存值，并重试事务操作。

WATCH 命令的工作原理:

Redis 使用乐观锁机制来实现 WATCH 命令。

• 当客户端使用 WATCH 命令监视 key 时，Redis 会为被监视的 key 维护一个版本号 (也称为 "CAS 令牌" - Compare And Swap Token)。

• 当客户端执行事务时，EXEC 命令会检查被 WATCH 的 key 的版本号是否在 WATCH 之后被修改过。

• 如果版本号没有变化，说明 key 在 WATCH 到 EXEC 期间没有被其他客户端修改，事务可以顺利执行。

• 如果版本号发生了变化，说明 key 被其他客户端修改过，WATCH 冲突发生，事务会被取消执行。

乐观锁 vs. 悲观锁:

• 乐观锁: 假设数据在事务执行期间不会被其他事务修改，只有在提交事务时才检查数据是否被修改过。如果检测到冲突，事务执行失败，需要重试。WATCH 命令实现的是乐观锁。

• 悲观锁: 假设数据在事务执行期间很可能会被其他事务修改，在事务开始时就对数据加锁，防止其他事务修改。关系型数据库通常使用悲观锁。

Redis 使用乐观锁的原因主要是为了保持高性能。悲观锁需要加锁和解锁操作，会降低并发性能。乐观锁避免了加锁操作，只有在冲突发生时才需要重试，通常在读多写少的场景下性能更高。

3.5 UNWATCH 命令

• 作用: 取消对所有 key 的监视。如果在 WATCH 命令之后，客户端决定不再需要监视任何 key，可以使用 UNWATCH 命令取消监视。

• 语法: UNWATCH

• 返回值: 总是返回 OK。

代码实践:

127.0.0.1:6379> WATCH key3
OK
127.0.0.1:6379> UNWATCH
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key3 value3
QUEUED
127.0.0.1:6379> EXEC
1) OK
​

在这个例子中，我们先使用 WATCH key3 监视 key3，然后使用 UNWATCH 命令取消了监视。之后，我们开始一个事务并设置 key3 的值。即使在 EXEC 执行之前，key3 被其他客户端修改，事务仍然会成功执行，因为我们已经取消了对 key3 的监视。

详细解释:

当客户端发送 UNWATCH 命令时，Redis 服务器会清除与该客户端连接关联的所有 WATCH 监视。之后，即使被之前 WATCH 过的 key 被其他客户端修改，事务也不会被取消执行。 UNWATCH 命令通常用于在 WATCH 命令之后，客户端根据某些条件判断，决定不再需要乐观锁机制，或者需要提前结束监视状态。

4. Redis 事务的执行过程

Redis 事务的执行过程可以分为三个阶段：

1. 开始事务 (MULTI): 客户端发送 MULTI 命令，服务器标记客户端连接进入事务状态。

2. 命令入队 (Queueing Commands): 客户端发送多个命令，服务器将这些命令放入事务队列中，并返回 QUEUED 状态。在这个阶段，服务器 不执行任何命令，只是进行简单的语法检查。如果命令有语法错误，服务器会记录错误，并在 EXEC 执行时拒绝执行整个事务。

3. 执行事务 (EXEC): 客户端发送 EXEC 命令，服务器开始执行事务队列中的所有命令。

   • 没有 WATCH 冲突: 如果没有使用 WATCH 命令，或者 WATCH 监视的 key 没有被修改，服务器会按照命令入队的顺序依次执行队列中的所有命令。执行过程中，Redis 会保持对数据库的独占访问，保证事务的隔离性。

   • 有 WATCH 冲突: 如果使用了 WATCH 命令，并且 WATCH 监视的 key 在 EXEC 执行之前被其他客户端修改过，服务器会检测到 WATCH 冲突，取消事务执行，并返回 (nil)。

   • 运行时错误: 如果在 EXEC 执行过程中，队列中的某个命令执行失败（例如类型错误），Redis 不会回滚整个事务，而是会 继续执行队列中的后续命令。 只有入队时发生的语法错误会导致整个事务被取消。

5. Redis 事务与流水线 (Pipelining) 的区别

Redis 流水线 (Pipelining) 也是一种优化 Redis 性能的技术，它允许客户端一次性发送多个命令到服务器，而不需要等待每个命令的响应。Redis 事务和流水线虽然都涉及批量操作，但它们的目的和特性有所不同。

区别:

• 原子性:

  • 事务: 保证事务块中命令的原子性执行，要么全部执行，要么全部不执行（在命令队列级别）。

  • 流水线: 不保证原子性。流水线只是一次性发送多个命令，服务器会依次执行这些命令，但命令之间没有任何原子性保证。

• 隔离性:

  • 事务: 通过串行化执行事务队列中的命令来保证隔离性。在 EXEC 执行期间，Redis 不会处理来自其他客户端的命令请求。

  • 流水线: 不保证隔离性。流水线中的命令与来自其他客户端的命令并发执行，可能会出现竞态条件。

• 错误处理:

  • 事务: 可以检测入队错误（语法错误）和 WATCH 冲突，并取消事务执行。运行时错误不会导致事务回滚，但会返回错误信息。

  • 流水线: 不提供事务的错误处理机制。流水线中的某个命令执行失败，不会影响其他命令的执行。客户端需要解析每个命令的响应来判断是否执行成功。

• 用途:

  • 事务: 用于需要原子性操作的场景，例如转账、库存管理等。可以使用 WATCH 命令实现乐观锁，解决并发修改问题。

  • 流水线: 主要用于批量操作，减少网络 RTT (Round-Trip Time)，提高性能。适用于对原子性和隔离性要求不高，但需要批量处理数据的场景。

总结:

何时使用事务，何时使用流水线？

• 需要保证一组操作的原子性时，使用事务。 例如，需要同时更新多个 key，并确保这些更新要么全部成功，要么全部失败。

• 需要实现乐观锁机制，解决并发修改问题时，使用事务和 WATCH 命令。

• 只需要批量执行命令，提高性能，对原子性和隔离性要求不高时，使用流水线。 例如，批量插入数据、批量读取数据等。

在实际应用中，可以根据具体场景选择合适的方案。有时候也可以将事务和流水线结合使用，例如在一个事务中，使用流水线批量发送命令，进一步提高性能。

6. Redis 事务的使用场景

Redis 事务在以下场景中非常有用：

• 原子性操作: 需要保证一组操作的原子性，例如：

  • 转账操作: 从一个账户扣款，同时向另一个账户存款。

  • 商品秒杀: 检查库存是否充足，减少库存，生成订单。

  • 社交网络: 用户关注另一个用户，需要同时更新关注列表和粉丝列表。

• 乐观锁: 需要使用乐观锁机制解决并发修改问题，例如：

  • 库存管理: 防止超卖，保证库存数量的准确性。

  • 计数器: 防止并发更新导致计数器值不准确。

  • 在线投票: 防止用户重复投票。

• 需要批量执行命令，并确保这些命令在一个原子上下文中执行时，可以使用事务。 虽然流水线也可以批量执行命令，但事务提供了更强的原子性和隔离性保证。

7. Redis 事务的最佳实践

• 保持事务的短小精悍: 事务执行期间，Redis 会保持对数据库的独占访问，长时间的事务会阻塞其他客户端的请求，影响 Redis 的并发性能。应该尽量保持事务的短小精悍，只包含必要的原子操作。

• 谨慎使用 WATCH 命令: WATCH 命令虽然可以实现乐观锁，但过度使用 WATCH 可能会增加事务冲突的概率，导致事务频繁失败和重试，降低性能。只有在确实需要解决并发修改问题时才使用 WATCH 命令。

• 理解 Redis 事务的局限性: Redis 事务并非完全符合传统 ACID 事务的所有属性，它不提供回滚机制，运行时错误需要开发者处理。需要充分理解 Redis 事务的特性和局限性，并根据实际情况选择合适的事务处理策略。

• 合理处理事务失败: 当 EXEC 命令返回 (nil) 时，表示事务执行失败（可能是入队错误或 WATCH 冲突）。客户端需要根据具体情况处理事务失败的情况，例如重试事务操作，或者进行错误日志记录和告警。

• 监控事务性能: 监控 Redis 事务的执行时间、事务冲突率等指标，及时发现和解决事务性能问题。可以使用 Redis 的 INFO 命令或者监控工具来获取事务相关的统计信息。

8. 总结

Redis 事务提供了一种在 Redis 中执行原子操作的机制。通过 MULTI, EXEC, DISCARD, WATCH, 和 UNWATCH 命令，开发者可以构建事务块，实现命令的原子性执行和乐观锁机制。

理解 Redis 事务的特性、执行过程、使用场景和最佳实践，能够帮助开发者更好地利用 Redis 的事务功能，构建更可靠、更高效的应用程序。 然而，也需要注意 Redis 事务的局限性，例如不提供回滚机制，运行时错误需要开发者处理，以及过度使用 WATCH 可能带来的性能影响。

在实际应用中，应该根据具体的业务需求和场景，权衡 Redis 事务的优点和缺点，选择合适的事务处理方案。 掌握 Redis 事务，是深入理解 Redis 高级特性，并将其应用于复杂应用场景的关键一步。