Redis分布式锁SETNX与EXPIRE组合的缺陷与解决

Redis 分布式锁 SETNX 与 EXPIRE 组合的原理

在分布式系统中，为了保证在多节点环境下数据的一致性和避免并发操作带来的问题，常常需要使用分布式锁。Redis 由于其高性能和丰富的数据结构，成为实现分布式锁的常用选择。

使用 SETNX（SET if Not eXists）和 EXPIRE 组合来实现分布式锁的基本原理如下：

SETNX：SETNX key value 命令用于将键 key 的值设为 value ，当且仅当键 key 不存在。若键 key 已经存在，该操作无效果。返回值为 1 表示设置成功，0 表示设置失败。在分布式锁场景中，我们可以将锁的标识（例如一个唯一的客户端 ID）作为 value ，锁的名称作为 key 。如果 SETNX 返回 1 ，则表示当前客户端成功获取到了锁。
EXPIRE：EXPIRE key seconds 命令用于为键 key 设置过期时间，单位为秒。在获取锁之后，我们通过 EXPIRE 命令为这个锁设置一个过期时间，以防止在某些异常情况下（例如持有锁的客户端崩溃），锁一直被持有而无法释放，导致其他客户端永远无法获取锁。

以下是一个简单的示例代码（以 Python 和 Redis - Py 库为例）：

import redis
import time

r = redis.Redis(host='localhost', port=6379, db = 0)

def acquire_lock(lock_key, client_id, lock_timeout=10):
    result = r.setnx(lock_key, client_id)
    if result:
        r.expire(lock_key, lock_timeout)
        return True
    return False

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

SETNX 与 EXPIRE 组合的缺陷

命令非原子性问题
- 在上述实现中，SETNX 和 EXPIRE 是两条不同的命令。虽然 SETNX 成功获取锁后紧接着执行 EXPIRE 设置过期时间看起来逻辑合理，但在 Redis 多节点或者网络不稳定的情况下，这两条命令之间可能会出现问题。例如，在执行 SETNX 成功后，由于网络故障或 Redis 节点故障，EXPIRE 命令未能成功执行。这样一来，这个锁就没有设置过期时间，一旦持有锁的客户端出现异常（如崩溃），这个锁将永远无法释放，其他客户端也永远无法获取该锁，导致死锁。
- 从 Redis 的执行机制来看，Redis 是单线程处理命令，但在分布式环境下，网络等因素可能导致部分命令无法按预期执行。在主从复制架构中，如果主节点在执行 SETNX 后还未将数据同步到从节点就发生故障，新的主节点可能没有这个锁的信息，从而导致锁的状态不一致。
锁误释放问题
- 假设锁的过期时间设置为 10 秒，客户端 A 获取锁后开始执行任务，但是任务执行时间超过了 10 秒。在 10 秒后，锁自动过期被释放。此时客户端 B 获取到了这个锁。而紧接着客户端 A 完成了任务，执行释放锁的操作（通常是删除锁对应的键），但此时它删除的是客户端 B 的锁，这就导致了锁的误释放，破坏了分布式锁的正确性。
- 这种情况发生的根本原因是锁的持有者在释放锁时，没有对锁的归属进行有效的验证。在分布式环境中，不同客户端获取锁的时间和锁的过期时间是相互独立的，当任务执行时间不可控时，就容易出现锁误释放的问题。
性能问题
- 网络开销：每次获取锁需要执行两条命令，SETNX 和 EXPIRE ，这增加了客户端与 Redis 服务器之间的网络往返次数。在高并发场景下，频繁的网络交互会成为性能瓶颈。
- 锁竞争开销：在多个客户端同时竞争锁的情况下，大量的 SETNX 失败请求会增加 Redis 服务器的处理压力。而且由于 SETNX 和 EXPIRE 非原子性，可能导致部分客户端获取锁成功但未设置过期时间，使得后续的锁竞争更加混乱，进一步降低系统性能。

解决 SETNX 与 EXPIRE 组合缺陷的方法

使用 SET 命令的原子操作
- 从 Redis 2.6.12 版本开始，SET 命令增加了一系列选项，使其可以实现原子性的获取锁并设置过期时间。语法为 SET key value [EX seconds] [PX milliseconds] [NX|XX] 。其中 EX seconds 表示设置键的过期时间为 seconds 秒，PX milliseconds 表示设置键的过期时间为 milliseconds 毫秒，NX 表示只有键不存在时才设置键值，这与 SETNX 的功能类似。
- 示例代码如下（仍以 Python 和 Redis - Py 库为例）：

import redis
import time

r = redis.Redis(host='localhost', port=6379, db = 0)

def acquire_lock(lock_key, client_id, lock_timeout=10):
    result = r.set(lock_key, client_id, ex=lock_timeout, nx=True)
    return result

def release_lock(lock_key, client_id):
    pipe = r.pipeline()
    while True:
        try:
            pipe.watch(lock_key)
            if pipe.get(lock_key) == client_id.encode('utf - 8'):
                pipe.multi()
                pipe.delete(lock_key)
                pipe.execute()
                return True
            pipe.unwatch()
            break
        except redis.WatchError:
            continue
    return False

- 在这个实现中，`acquire_lock` 函数使用 `SET` 命令的 `ex` 和 `nx` 选项，原子性地获取锁并设置过期时间，避免了 `SETNX` 和 `EXPIRE` 非原子性带来的问题。`release_lock` 函数使用 `WATCH` 机制来确保只有锁的持有者才能释放锁，避免了锁误释放的问题。`WATCH` 命令用于监视一个或多个键，当被监视的键在事务执行之前被其他客户端修改时，事务将被打断。

2. 使用 Lua 脚本 - Lua 脚本在 Redis 中可以保证原子性执行。我们可以将获取锁和设置过期时间的逻辑封装在一个 Lua 脚本中。以下是一个示例 Lua 脚本：

if (redis.call('SETNX', KEYS[1], ARGV[1]) == 1) then
    redis.call('EXPIRE', KEYS[1], ARGV[2])
    return 1
else
    return 0
end

- 在 Python 中调用这个 Lua 脚本的代码如下：

import redis
import time

r = redis.Redis(host='localhost', port=6379, db = 0)

def acquire_lock(lock_key, client_id, lock_timeout=10):
    script = """
    if (redis.call('SETNX', KEYS[1], ARGV[1]) == 1) then
        redis.call('EXPIRE', KEYS[1], ARGV[2])
        return 1
    else
        return 0
    end
    """
    result = r.eval(script, 1, lock_key, client_id, lock_timeout)
    return result == 1

def release_lock(lock_key, client_id):
    script = """
    if (redis.call('GET', KEYS[1]) == ARGV[1]) then
        return redis.call('DEL', KEYS[1])
    else
        return 0
    end
    """
    result = r.eval(script, 1, lock_key, client_id)
    return result == 1

- 这里的 `acquire_lock` 函数通过 `r.eval` 方法执行 Lua 脚本，保证了获取锁和设置过期时间的原子性。`release_lock` 函数同样通过 Lua 脚本确保只有锁的持有者才能释放锁。

3. 改进锁释放逻辑 - 除了使用 WATCH 机制或 Lua 脚本来确保只有锁的持有者才能释放锁外，还可以在锁的 value 中设置一个唯一的标识（如 UUID）。在释放锁时，先获取锁的 value 并与自己设置的标识进行比较，只有一致时才执行删除操作。 - 示例代码如下：

import redis
import uuid
import time

r = redis.Redis(host='localhost', port=6379, db = 0)

def acquire_lock(lock_key, lock_timeout=10):
    client_id = str(uuid.uuid4())
    result = r.set(lock_key, client_id, ex=lock_timeout, nx=True)
    if result:
        return client_id
    return None

def release_lock(lock_key, client_id):
    stored_client_id = r.get(lock_key)
    if stored_client_id and stored_client_id.decode('utf - 8') == client_id:
        r.delete(lock_key)
        return True
    return False

- 在这个实现中，`acquire_lock` 函数生成一个唯一的 `client_id` 并设置到锁中，`release_lock` 函数在释放锁前先验证 `client_id` ，从而避免了锁误释放的问题。

4. 优化性能 - 减少网络开销：可以采用连接池来复用 Redis 连接，减少每次获取锁时建立连接的开销。同时，尽量将获取锁和释放锁的操作合并在少量的网络请求中，例如使用 Lua 脚本将多个操作合并为一个原子操作，减少网络往返次数。 - 降低锁竞争压力：可以采用一些策略来减少锁竞争，例如在客户端获取锁失败后，采用随机退避算法等待一段时间后再重试，避免大量客户端同时重试导致的高负载。还可以考虑使用分布式缓存的分片技术，将不同的锁分布在不同的 Redis 节点上，降低单个节点的锁竞争压力。

实际应用中的注意事项

锁的粒度
- 在设计分布式锁时，需要考虑锁的粒度。如果锁的粒度太粗，会导致并发性能下降，因为大量的操作都需要竞争同一个锁。例如，在一个电商系统中，如果对整个订单处理流程使用一个锁，那么所有的订单处理操作都将串行化，严重影响系统的并发处理能力。相反，如果锁的粒度太细，又会增加锁的管理成本和死锁的风险。例如，在一个库存管理系统中，如果对每一个商品的库存操作都使用一个单独的锁，当多个商品库存操作相互依赖时，可能会因为锁的获取顺序不当而导致死锁。
- 因此，在实际应用中，需要根据业务场景合理地设计锁的粒度。一般来说，可以将相关的操作划分为不同的业务单元，为每个业务单元设置一个锁。例如，在电商系统中，可以为订单创建、订单支付、订单发货等不同的业务流程设置不同的锁，这样既能保证数据的一致性，又能提高系统的并发性能。
锁的过期时间
- 锁的过期时间设置需要谨慎。如果过期时间设置过短，可能会导致任务还未完成锁就过期被释放，从而出现并发问题。例如，在一个数据同步任务中，如果锁的过期时间设置为 1 分钟，但数据同步可能需要 2 分钟，那么就会出现同步过程中锁过期，其他客户端获取锁并开始同步，导致数据同步混乱。
- 另一方面，如果过期时间设置过长，在持有锁的客户端出现异常时，会导致其他客户端长时间等待锁的释放，降低系统的可用性。例如，在一个分布式爬虫系统中，如果某个爬虫节点获取锁后崩溃，但锁的过期时间设置为 1 小时，那么在这 1 小时内其他爬虫节点都无法获取锁去爬取相同的页面，影响爬虫的效率。
- 为了解决这个问题，可以根据任务的平均执行时间来合理设置锁的过期时间，并在任务执行过程中定期延长锁的过期时间（例如使用 EXPIRE 命令）。例如，在数据同步任务中，可以根据历史数据同步时间估算出平均执行时间为 3 分钟，然后将锁的过期时间设置为 5 分钟，并在同步过程中每 2 分钟延长一次锁的过期时间。
高可用与容灾
- 在分布式系统中，Redis 可能会出现节点故障等问题。为了保证分布式锁的高可用性，需要采用一些容灾策略。常见的做法是使用 Redis 的主从复制和 Sentinel 机制或者 Cluster 模式。
- 在主从复制和 Sentinel 机制中，Sentinel 可以监控主节点的状态，当主节点出现故障时，Sentinel 会自动将一个从节点提升为主节点，保证系统的可用性。但是在主从切换过程中，可能会出现短暂的数据不一致，例如在主节点获取锁后还未同步到从节点就发生故障，新的主节点可能没有这个锁的信息。为了避免这种情况，可以采用 Redlock 算法。
- Redlock 算法通过使用多个独立的 Redis 节点来获取锁。客户端需要在大多数（超过一半）的 Redis 节点上成功获取锁，才算真正获取到锁。这样即使个别节点出现故障，也不会影响锁的正常使用。但是 Redlock 算法也存在一些争议，例如在网络分区等极端情况下，可能会出现多个客户端同时获取到锁的情况。因此在实际应用中，需要根据具体的业务场景和对一致性的要求来选择合适的高可用方案。
锁的监控与报警
- 在实际应用中，对分布式锁进行监控和报警是非常重要的。通过监控可以了解锁的使用情况，例如锁的竞争程度、锁的持有时间等。如果发现锁的竞争过于激烈或者持有时间过长，可能意味着系统存在性能问题或者死锁风险。
- 可以通过 Redis 的 INFO 命令获取 Redis 的运行状态信息，包括键空间的使用情况等，来间接监控锁的使用。同时，可以自定义一些监控指标，例如在获取锁和释放锁时记录时间戳，计算锁的持有时间，并将这些指标发送到监控系统（如 Prometheus）进行展示和分析。
- 当监控到异常情况时，需要及时报警。可以通过邮件、短信或者即时通讯工具等方式通知相关的开发人员或运维人员，以便及时处理问题，保证系统的稳定性。

案例分析

电商库存扣减场景
- 在电商系统中，库存扣减是一个典型的需要使用分布式锁的场景。假设一个电商平台有多个订单处理服务同时处理订单，每个订单处理服务在扣减库存时都需要获取库存锁。
- 如果使用 SETNX 和 EXPIRE 组合的方式实现分布式锁，可能会出现以下问题。例如，订单处理服务 A 获取锁后执行 SETNX 成功，但在执行 EXPIRE 时由于网络故障未能成功设置过期时间。此时服务 A 开始扣减库存，在扣减库存过程中服务 A 崩溃，由于锁没有过期时间，其他订单处理服务永远无法获取锁，导致库存无法继续扣减，影响正常的订单处理流程。
- 采用 SET 命令的原子操作或者 Lua 脚本实现分布式锁可以有效解决这个问题。以 Lua 脚本为例，将获取锁、验证库存、扣减库存等操作封装在一个 Lua 脚本中，保证这些操作的原子性。示例 Lua 脚本如下：

-- KEYS[1] 为库存锁的键
-- KEYS[2] 为库存数量的键
-- ARGV[1] 为客户端标识
-- ARGV[2] 为锁的过期时间
-- ARGV[3] 为扣减数量
if (redis.call('SETNX', KEYS[1], ARGV[1]) == 1) then
    redis.call('EXPIRE', KEYS[1], ARGV[2])
    local stock = redis.call('GET', KEYS[2])
    if (stock and tonumber(stock) >= tonumber(ARGV[3])) then
        redis.call('DECRBY', KEYS[2], ARGV[3])
        return 1
    end
    redis.call('DEL', KEYS[1])
    return 0
else
    return 0
end

- 在这个脚本中，首先尝试获取锁并设置过期时间，然后获取库存数量并验证是否足够扣减。如果库存足够，则扣减库存并返回成功；如果库存不足，则删除锁并返回失败。这样就保证了库存扣减操作的原子性和一致性。

2. 分布式任务调度场景 - 在分布式任务调度系统中，多个调度节点可能会同时尝试调度同一个任务。为了避免重复调度，需要使用分布式锁来保证只有一个节点能够调度任务。 - 假设使用 SETNX 和 EXPIRE 组合实现分布式锁，在任务调度过程中，如果任务执行时间较长，超过了锁的过期时间，就可能出现锁误释放的问题。例如，调度节点 A 获取锁后开始调度任务，任务执行时间为 15 分钟，但锁的过期时间设置为 10 分钟。10 分钟后锁过期被释放，调度节点 B 获取到锁并开始调度同一个任务，导致任务被重复调度。 - 为了解决这个问题，可以在锁的 value 中设置一个唯一标识，在释放锁时验证标识。同时，可以采用动态调整锁过期时间的方法。例如，在任务调度开始时，根据任务的预估执行时间设置一个较长的锁过期时间，并在任务执行过程中定期检查任务进度，如果任务执行进度正常，则延长锁的过期时间。示例 Python 代码如下：

import redis
import uuid
import time

r = redis.Redis(host='localhost', port=6379, db = 0)

def acquire_lock(lock_key, lock_timeout=10):
    client_id = str(uuid.uuid4())
    result = r.set(lock_key, client_id, ex=lock_timeout, nx=True)
    if result:
        return client_id
    return None

def release_lock(lock_key, client_id):
    stored_client_id = r.get(lock_key)
    if stored_client_id and stored_client_id.decode('utf - 8') == client_id:
        r.delete(lock_key)
        return True
    return False

def schedule_task(task_key, client_id, estimated_runtime=15):
    lock_key = f'task:{task_key}:lock'
    lock_timeout = estimated_runtime + 5
    lock = acquire_lock(lock_key, lock_timeout)
    if lock:
        try:
            # 模拟任务执行
            time.sleep(estimated_runtime)
            # 任务执行过程中定期延长锁的过期时间
            for _ in range(3):
                time.sleep(5)
                r.expire(lock_key, lock_timeout)
            return True
        finally:
            release_lock(lock_key, lock)
    return False

- 在这个代码中，`acquire_lock` 函数获取锁并返回唯一标识，`release_lock` 函数在释放锁时验证标识。`schedule_task` 函数在任务执行过程中定期延长锁的过期时间，避免了锁误释放和任务执行过程中锁过期的问题。

不同解决方案的对比与选择

性能对比
- SET 命令原子操作：使用 SET 命令的原子操作，相比 SETNX 和 EXPIRE 组合，减少了一次网络往返，性能有所提升。在高并发场景下，网络开销的减少对系统性能的提升较为明显。但是，在释放锁时，如果不采用额外的机制（如 WATCH 机制），可能会出现锁误释放问题，这可能需要额外的操作来保证释放锁的正确性，从而增加一定的性能开销。
- Lua 脚本：Lua 脚本将获取锁、设置过期时间以及释放锁等操作都封装在一个原子操作中，减少了网络往返次数，性能较好。而且通过 Lua 脚本可以更灵活地实现复杂的逻辑，例如在获取锁时同时验证一些其他条件。然而，Lua 脚本的编写和维护相对复杂，需要开发人员对 Lua 语言有一定的了解。
- 改进锁释放逻辑：单纯改进锁释放逻辑，如在释放锁前验证 client_id ，对获取锁的性能影响较小。但这种方式主要是解决锁误释放问题，对于获取锁时的原子性问题并没有直接优化，在高并发场景下，SETNX 和 EXPIRE 非原子性带来的问题仍然可能影响性能。
复杂性对比
- SET 命令原子操作：使用 SET 命令的原子操作实现分布式锁相对简单，只需要熟悉 Redis 的 SET 命令选项即可。在释放锁时，如果采用 WATCH 机制，虽然增加了一定的复杂性，但整体实现仍然相对清晰。
- Lua 脚本：Lua 脚本的编写需要掌握 Lua 语言的语法和 Redis 的命令调用方式，对于不熟悉 Lua 语言的开发人员来说，学习成本较高。而且在调试和维护过程中，由于 Lua 脚本的执行逻辑相对集中，定位问题可能会相对困难。
- 改进锁释放逻辑：改进锁释放逻辑，如在锁的 value 中设置唯一标识并在释放锁时验证，实现起来相对简单，只需要在获取锁和释放锁的代码中添加少量逻辑即可。这种方式对开发人员的技术要求较低，易于理解和维护。
可靠性对比
- SET 命令原子操作：通过 SET 命令原子性地获取锁并设置过期时间，解决了 SETNX 和 EXPIRE 非原子性带来的死锁问题。同时，结合 WATCH 机制可以有效避免锁误释放问题，可靠性较高。
- Lua 脚本：Lua 脚本将多个操作封装为原子操作，从根本上解决了命令非原子性问题。在释放锁时，通过 Lua 脚本内部逻辑验证锁的归属，避免了锁误释放问题，可靠性也很高。
- 改进锁释放逻辑：改进锁释放逻辑主要解决了锁误释放问题，但对于 SETNX 和 EXPIRE 非原子性带来的死锁等问题并没有彻底解决。在网络不稳定或 Redis 节点故障的情况下，仍然可能出现锁无法正确设置过期时间的问题，可靠性相对较低。
选择建议
- 如果项目对性能要求较高，开发人员对 Lua 语言有一定的掌握，且对代码的复杂性有较好的承受能力，那么使用 Lua 脚本实现分布式锁是一个不错的选择。它可以在保证可靠性的同时，最大程度地提升性能。
- 如果项目对简单性和可维护性要求较高，对性能提升的要求不是特别苛刻，那么使用 SET 命令的原子操作结合 WATCH 机制实现分布式锁是比较合适的。这种方式既解决了主要的问题，又相对容易理解和维护。
- 如果项目主要关注锁误释放问题，且对现有代码的改动尽量小，那么改进锁释放逻辑的方式可以作为一种临时的解决方案。但在高并发和复杂的分布式环境下，这种方式可能不足以保证系统的稳定性，需要进一步考虑更完善的方案。

在实际应用中，需要根据项目的具体需求、技术团队的能力以及系统的性能和可靠性要求等多方面因素，综合选择合适的分布式锁解决方案。同时，无论选择哪种方案，都需要对分布式锁进行充分的测试和监控，确保其在各种情况下都能正确工作，保障分布式系统的稳定性和一致性。