Redis事务机制、乐观锁详解

Redis事务

Redis事务（Transactions）机制允许一次性执行一组命令，但它与传统的关系型数据库中的事务有一些显著的不同。

Redis事务的特点

1. 原子性：事务中的所有命令都会被序列化，按顺序执行，不会被其他客户端发出的命令插入。
2. 单独执行：事务内的所有命令都会一个接一个地执行，中间不会被其他命令打断。
3. 不支持回滚：如果事务中某个命令执行失败（例如，语法错误），Redis不会回滚整个事务。这意味着成功的命令依然会生效。

Redis事务不支持隔离级别控制，这意味着事务中的命令执行时并不会阻塞其他客户端的读写操作。

事务命令

1. MULTI：标记事务的开始。
2. EXEC：执行所有在MULTI之后发出的命令。
3. DISCARD：取消事务，放弃在MULTI之后发出的所有命令。
4. WATCH：监视一个或多个键，如果在事务执行前任何一个被监视的键发生变化，事务将中止。为确保事务的完整性，通常需要结合WATCH命令，以防止并发修改引起的数据不一致问题。

事务使用示例

• Redis使用 MULTI 命令标记事务开始，它总是返回OK。
• MULTI执行之后，客户端可以发送多条命令，Redis会把这些命令保存在队列当中，而不是立刻执行这些命令。
• 所有的命令会在调用EXEC 命令之后执行。

• 当Redis连接执行MULTI 命令后，之后所有的命令返回字符串 QUEUED 。入队的命令将在 EXEC 命令被调用时执行。

• EXEC 返回一个应答数组，数组中的每个元素对应着事务中的一个命令，和命令发送的顺序一致。

---

• DISCARD 可用于中止事务。在这种情况下，不执行任何命令，连接状态恢复正常。
• 如果不调用EXEC，调用 DISCARD 会清空事务队列并退出事务。

事务中的错误处理（回滚的特性）

在Redis事务中，不同类型的错误有不同的处理方式：

• 命令排队错误：在MULTI之后命令被放入事务队列时，如果有语法错误或其他原因导致的错误，这些错误会立即被报告且事务执行时会失败。
  

• 运行时错误：如果事务执行时某个命令由于数据类型错误或其他运行时错误引发，其他命令仍会继续执行，事务不会自动回滚。
  

---

Redis乐观锁

哈哈哈哈哈 有没有想过 为啥叫乐观锁呢？那有没有悲观锁呢？

1. 乐观锁：

   • 思想：乐观锁的基本思想是假设并发冲突不经常发生，因此在操作开始时并不会对共享数据加锁，而是直接去尝试修改数据。在修改完成后，会检查在此期间数据是否被其他进程修改过，通常是通过版本号或时间戳来实现。
   • 适用场景：适用于读操作频繁、冲突较少的场景，避免了频繁加锁和解锁的性能开销。

2. 悲观锁：

   • 思想：悲观锁则是假设并发冲突经常发生，因此在操作开始前会先加锁，确保在整个操作过程中数据不会被其他进程修改。只有当操作完成后才会释放锁。
   • 适用场景：适用于写操作频繁、冲突较多的场景，可以有效地避免数据的并发修改问题，但会带来额外的性能开销和系统开销。

---

在 Redis 中，乐观锁通常是通过 WATCH 命令和事务（MULTI/EXEC）来实现的一种并发控制机制。

基本思想

在执行事务之前，先监视一个或多个键的值，然后在事务执行期间，如果这些键的值发生了变化，Redis 将取消事务的执行。

这种方式可以用来确保在多个客户端同时操作同一组数据时，不会产生冲突或者数据不一致的情况。

实现步骤

1. 使用 WATCH 命令监视键：

   • 使用 WATCH 命令可以监视一个或多个键，一旦某个监视的键被修改，之后的事务操作就会被 Redis 取消。

   WATCH key1 key2 ...
   

Tips：

• 也可以使用不带参数的 UNWATCH 取消对所有 key 观察行为。
• 有时我们乐观地锁定了一些键，可能需要执行事务来修改这些键，但在读取键的内容后又不想继续修改，这时，只需调用 UNWATCH。

2. 开启事务：

   • 在使用 WATCH 命令后，将所有要执行的命令放入 MULTI 和 EXEC 命令之间，这些命令将作为一个事务一起执行。

   MULTI
   command1
   command2
   ...
   EXEC
   

3. 检查事务执行结果：

   • 在 EXEC 命令执行后，Redis 会检查在执行事务期间被监视的键是否被修改过。如果有任何被监视的键被修改过，那么整个事务将被取消执行，否则事务将按顺序执行。

乐观锁示例

假设有一个库存系统，每个商品记录包含商品ID、库存数量和版本号。多个用户同时尝试购买同一件商品，使用乐观锁来控制库存的并发修改。

1. 乐观锁操作步骤：

   • 用户 A 和用户 B 同时查询商品的库存信息，假设初始库存为 100，版本号为 version = 1。
   • 用户 A 先于用户 B 完成购买操作，减少库存为 99，并将版本号更新为 version = 2。
   • 用户 B 在其读取的时候还是版本号 version = 1，因此以为库存仍然是 100，并尝试将库存减少为 98，同时将版本号更新为 version = 2。

2. 乐观锁冲突：

   • 当用户 B 提交更新请求时，数据库执行乐观锁检查发现，版本号已经被更新为 version = 2，而不是用户 B 最初读取的 version = 1。
   • 因此，数据库会拒绝用户 B 的更新操作，并返回失败或者冲突信息。

3. 失败示例：

   • 用户 A 更新成功后，用户 B 的更新操作因为版本号不匹配而失败。
   • 用户 B 可能会收到一个异常或者错误信息，通知他们库存不足或者操作失败，需要重新尝试购买或者根据实际情况进行处理。

---