Redis Cluster 事务与 Lua 脚本：跨槽位原子操作的挑战

同学们，今天咱们聊聊 Redis Cluster 里头那些让人头疼，但又不得不面对的事儿：事务和 Lua 脚本在跨槽位操作时的原子性问题。

Redis Cluster：分家之后的烦恼

首先，得明白 Redis Cluster 为什么要分片。单机 Redis 容量有限，扛不住海量数据，所以得把数据拆开，放到多个节点上，这就是分片（Sharding）。Redis Cluster 采用的是槽位（Slot）的概念，总共有 16384 个槽位，每个 key 通过 CRC16 算法算出哈希值，然后对 16384 取模，决定这个 key 属于哪个槽位。槽位再分配到不同的 Redis 节点上。

这种分片方式的好处是扩展性好，但坏处也很明显：原本在单机 Redis 上唾手可得的原子操作，现在变得困难重重。比如，一个简单的转账操作，A 账户减钱，B 账户加钱，如果 A 和 B 的 key 恰好在不同的槽位上，那就麻烦了。

事务：理想很丰满，现实很骨感

在单机 Redis 里，事务（MULTI, EXEC, DISCARD, WATCH）可以保证一组命令的原子性。简单来说，MULTI 开启事务，之后执行的命令会被放到一个队列里，直到 EXEC 命令执行，队列里的命令才会按顺序执行，要么全部成功，要么全部失败。

但是，在 Redis Cluster 里，事务的原子性只能保证在 单个节点 上。也就是说，如果事务涉及多个槽位，分布在不同的节点上，那原子性就荡然无存了。

举个例子，假设我们有个简单的商品库存管理系统：

# 伪代码，展示逻辑
def 库存扣减(商品ID, 数量):
  redis.decrby(f"库存:{商品ID}", 数量)
  redis.incrby(f"销量:{商品ID}", 数量)

如果 库存:{商品ID} 和 销量:{商品ID} 这两个 key 分布在不同的节点上，那么用 Redis 事务是没法保证原子性的。万一 库存:{商品ID} 扣减成功了，销量:{商品ID} 增加失败了，那数据就乱套了。

Lua 脚本：救星还是鸡肋？

Lua 脚本允许我们将一段 Lua 代码发送到 Redis 服务器执行。Redis 会以原子方式执行整个脚本。这听起来像是解决跨槽位原子性问题的救星，但实际上并非如此。

Redis 限制了 Lua 脚本执行的时间，默认是 5 秒。如果脚本执行时间超过这个限制，Redis 会杀死这个脚本，并返回一个错误。对于复杂的操作，5 秒的时间可能不够用。而且，长时间运行的脚本会阻塞 Redis 服务器，影响其他客户端的请求。

更重要的是，在 Redis Cluster 中，Lua 脚本默认也只能访问 单个节点 上的数据。如果脚本需要访问多个槽位的数据，同样会失败。

eval vs evalsha 的选择

在使用 Lua 脚本时，我们通常会用到 EVAL 和 EVALSHA 两个命令。

EVAL: 直接执行 Lua 脚本。每次都需要将整个脚本发送到 Redis 服务器。
EVALSHA: 执行已经加载到 Redis 服务器的 Lua 脚本。第一次执行时，需要先使用 SCRIPT LOAD 命令将脚本加载到服务器，然后就可以使用 EVALSHA 命令来执行了。

EVALSHA 的好处是减少了网络传输的开销，提高了性能。但是，如果 Redis 服务器重启，或者脚本被手动卸载，那么 EVALSHA 命令就会失败，需要重新加载脚本。

跨槽位原子操作的解决方案：真的有吗？

既然事务和 Lua 脚本都不能完美解决跨槽位原子操作的问题，那我们还有其他办法吗？答案是：有，但都不完美。

尽量避免跨槽位操作: 这是最简单，也是最有效的方法。在设计数据模型时，尽量将相关的数据放在同一个槽位上。比如，可以将 库存:{商品ID} 和 销量:{商品ID} 的 key 进行一定的处理，使它们落在同一个槽位上。例如，使用 Hash Tag。
```
key = "{商品ID}:库存"
key = "{商品ID}:销量"
```
这样，只要 商品ID 相同，这两个 key 就会被分配到同一个槽位。但是，这种方法会牺牲一定的灵活性。

客户端锁: 使用分布式锁（比如 Redlock）来保证原子性。在执行跨槽位操作之前，先获取锁，操作完成后再释放锁。这种方法的缺点是性能较低，因为需要进行额外的网络通信。而且，如果锁的持有者崩溃，可能会导致死锁。

# 伪代码，展示逻辑 (需要引入 Redlock 客户端)
redlock = Redlock(...) # 初始化 Redlock 客户端

try:
    lock = redlock.lock("转账锁", 1000) # 1000 ms 超时时间
    if lock:
        redis.decrby(f"库存:{商品ID}", 数量)
        redis.incrby(f"销量:{商品ID}", 数量)
        redlock.unlock(lock) # 释放锁
    else:
        print("获取锁失败")
except Exception as e:
    print(f"发生异常: {e}")
    if lock:
       redlock.unlock(lock)

手动补偿: 先执行操作，然后检查结果，如果发现数据不一致，则进行手动补偿。这种方法的缺点是实现复杂，容易出错。而且，补偿操作本身也可能失败。

# 伪代码，展示逻辑
库存_原始值 = redis.get(f"库存:{商品ID}")
销量_原始值 = redis.get(f"销量:{商品ID}")

try:
    redis.decrby(f"库存:{商品ID}", 数量)
    redis.incrby(f"销量:{商品ID}", 数量)

    # 检查一致性 (简化示例，实际情况更复杂)
    库存_当前值 = redis.get(f"库存:{商品ID}")
    销量_当前值 = redis.get(f"销量:{商品ID}")

    if int(库存_原始值) - int(库存_当前值) != 数量 or int(销量_当前值) - int(销量_原始值) != 数量:
        print("数据不一致，进行补偿")
        redis.set(f"库存:{商品ID}", 库存_原始值)  # 补偿库存
        redis.set(f"销量:{商品ID}", 销量_原始值)  # 补偿销量
    else:
        print("数据一致")

except Exception as e:
    print(f"发生异常: {e}")
    # 发生异常，进行补偿
    redis.set(f"库存:{商品ID}", 库存_原始值)  # 补偿库存
    redis.set(f"销量:{商品ID}", 销量_原始值)  # 补偿销量

使用 Redis Modules: Redis Modules 允许我们扩展 Redis 的功能。可以编写一个自定义的 Module，来实现跨槽位的原子操作。这种方法的优点是性能高，但缺点是开发成本高，需要熟悉 Redis 的内部机制。
使用第三方库 (比如 Redisson): Redisson 是一个 Java 的 Redis 客户端，它提供了很多高级的功能，包括分布式锁、分布式对象等。Redisson 可以简化跨槽位原子操作的实现。但是，Redisson 也有一定的性能开销。
两阶段提交 (2PC): 这是一个经典的分布式事务解决方案。将事务分为两个阶段：准备阶段和提交阶段。在准备阶段，所有节点都准备好执行事务，如果所有节点都准备成功，则进入提交阶段，所有节点都执行事务。如果任何一个节点准备失败，则进入回滚阶段，所有节点都回滚事务。2PC 的缺点是实现复杂，性能较低。

各种方案对比

为了更清晰地比较这些方案，我们用一张表格来总结一下：

方案	优点	缺点	适用场景
避免跨槽位操作	简单有效，性能高	牺牲灵活性	数据关联性强，对灵活性要求不高的场景
客户端锁	简单易懂，通用性强	性能较低，可能死锁	对原子性要求高，对性能要求不高的场景
手动补偿	灵活性高	实现复杂，容易出错，补偿操作可能失败	允许一定程度的数据不一致，可以容忍补偿失败的场景
Redis Modules	性能高	开发成本高，需要熟悉 Redis 内部机制	对性能要求极高，有足够开发资源的场景
Redisson	简化开发	有一定的性能开销，引入额外的依赖	使用 Java 开发，需要快速实现跨槽位原子操作的场景
两阶段提交 (2PC)	理论上保证强一致性	实现复杂，性能较低	对数据一致性要求极高，可以容忍较低性能的场景

Lua 脚本 + Hash Tag 的一种特殊情况

虽然 Lua 脚本在 Redis Cluster 中默认只能访问单个节点的数据，但如果配合 Hash Tag，也可以实现一定程度上的跨槽位原子操作。

假设我们有以下 Lua 脚本：

local key1 = KEYS[1]
local key2 = KEYS[2]
local amount = tonumber(ARGV[1])

local current_stock = redis.call('GET', key1)
if not current_stock then
  return redis.error('Stock key not found')
end

local current_sales = redis.call('GET', key2)
if not current_sales then
  return redis.error('Sales key not found')
end

current_stock = tonumber(current_stock)
current_sales = tonumber(current_sales)

if current_stock < amount then
  return redis.error('Insufficient stock')
end

redis.call('DECRBY', key1, amount)
redis.call('INCRBY', key2, amount)

return {current_stock - amount, current_sales + amount}

如果我们在调用 EVAL 命令时，传入的 KEYS 参数使用了相同的 Hash Tag，那么这两个 key 就会被分配到同一个槽位，从而保证 Lua 脚本的原子性。

例如：

# 假设商品ID是 "product123"
key1 = "{product123}:stock"
key2 = "{product123}:sales"
amount = 10

script = """
local key1 = KEYS[1]
local key2 = KEYS[2]
local amount = tonumber(ARGV[1])

local current_stock = redis.call('GET', key1)
if not current_stock then
  return redis.error('Stock key not found')
end

local current_sales = redis.call('GET', key2)
if not current_sales then
  return redis.error('Sales key not found')
end

current_stock = tonumber(current_stock)
current_sales = tonumber(current_sales)

if current_stock < amount then
  return redis.error('Insufficient stock')
end

redis.call('DECRBY', key1, amount)
redis.call('INCRBY', key2, amount)

return {current_stock - amount, current_sales + amount}
"""

result = redis.eval(script, 2, key1, key2, amount)
print(result)

在这个例子中，{product123}:stock 和 {product123}:sales 都会被分配到同一个槽位，所以 Lua 脚本可以保证原子性。

总结：没有银弹，只有权衡

总而言之，Redis Cluster 的跨槽位原子操作是一个复杂的问题，没有完美的解决方案。我们需要根据具体的业务场景，选择合适的方案。在大多数情况下，尽量避免跨槽位操作是最好的选择。如果实在避免不了，那就需要权衡各种方案的优缺点，选择一个最适合自己的方案。

记住，架构设计没有银弹，只有权衡。希望今天的讲解能帮助大家更好地理解 Redis Cluster 的跨槽位原子操作问题，并在实际工作中做出更明智的选择。下课！

发表回复 取消回复

发表回复取消回复