如何编写分布式竞争加锁简易脚本

wen 实用脚本 2026-06-24 28

从原理到实战的深度解析

目录导读

分布式锁的核心价值与应用场景
简易脚本设计的三大原则
基于Redis的加锁脚本实现（SETNX + Lua）
避免死锁与自动续期机制
脚本测试与性能压测要点
常见问题QA

分布式锁的核心价值与应用场景

在多服务实例（如微服务、容器化部署）并发访问共享资源时，分布式竞争加锁是保障数据一致性的关键，库存扣减、定时任务防重复执行、分布式事务资源锁定。

如何编写分布式竞争加锁简易脚本

核心问题：传统synchronized或ReentrantLock仅适用于单进程，而分布式环境需要跨节点协调。

简易脚本的设计目标：用最少代码实现可靠加锁、解锁与超时自动释放。

简易脚本设计的三大原则

原子性：加锁与设置过期必须原子操作（如Redis的SET key value NX EX）。
唯一性：每个客户端持有唯一标识（UUID），防止误删其他客户端的锁。
容错性：避免因客户端崩溃导致锁永远不释放（必须设置过期时间）。

基于Redis的加锁脚本实现（SETNX + Lua）

1 基础加锁脚本（Node.js示例）

// 依赖：redis (npm install redis)
const redis = require('redis');
const client = redis.createClient({ url: 'redis://127.0.0.1:6379' });
async function acquireLock(resource, ttl) {
  const lockValue = uuidv4(); // 唯一标识
  const result = await client.set(resource, lockValue, {
    NX: true,    // 仅在key不存在时设置
    EX: ttl      // 过期时间（秒）
  });
  return result === 'OK' ? lockValue : null;
}

2 解锁脚本（使用Lua保证原子性）

解锁时必须检查值是否匹配,避免误删除其他线程的锁：

-- Lua脚本
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end

在Node.js中调用：

const unlockScript = `
  if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
  else
    return 0
  end
`;
async function releaseLock(resource, lockValue) {
  const result = await client.eval(unlockScript, {
    keys: [resource],
    arguments: [lockValue]
  });
  return result === 1;
}

避免死锁与自动续期机制

1 死锁原因分析

客户端崩溃：锁未释放，导致其他客户端永远无法获取。
业务执行时间超过TTL：锁自动释放后，其他客户端获得锁，导致资源混乱。

2 自动续期（Watchdog模式）

参考Redisson的“看门狗”机制，在业务执行期间定期续期：

async function executeWithLock(resource, ttl, bizLogic) {
  const lockValue = await acquireLock(resource, ttl);
  if (!lockValue) throw new Error('获取锁失败');
  const watchdog = setInterval(async () => {
    // 续期脚本：延长TTL
    const renewScript = `
      if redis.call("get", KEYS[1]) == ARGV[1] then
        return redis.call("expire", KEYS[1], ARGV[2])
      else
        return 0
      end
    `;
    await client.eval(renewScript, {
      keys: [resource],
      arguments: [lockValue, String(ttl)]
    });
  }, ttl * 1000 / 3); // 每 TTL/3 秒续期一次
  try {
    await bizLogic();
  } finally {
    clearInterval(watchdog);
    await releaseLock(resource, lockValue);
  }
}

脚本测试与性能压测要点

单元测试：模拟并发请求（使用Promise.all），验证锁的唯一性。
红锁（RedLock）慎用：对大多数场景，单节点Redis加锁已足够；红锁会增加延迟和复杂度。
基准性能：单次加锁+解锁延迟约1-3ms（本地网络），适合高并发下的短锁操作。

压测示例（使用artillery或k6）：

artillery run -n 1000 -c 20 lock-benchmark.yaml

观察QPS与错误率,确保锁脚本不会成为瓶颈。

常见问题QA

Q1：简易脚本是否支持集群模式？
A：支持，但需注意Redis Cluster的KEY路由规则，所有锁操作应当落在同一节点，建议使用{resource}声明hash tag，如lock:data:{order_123}。

Q2：如何应对Redis单点故障？
A：使用哨兵或集群模式提升可用性，若必须强一致，考虑ZooKeeper或etcd。

Q3：业务执行中Redis宕机，锁会立即失效吗？
A：是的，锁有过期时间（TTL），业务需容忍短暂无锁状态（最终一致性），若需要强一致性，建议引入数据库悲观锁作为兜底。

Q4：锁粒度如何选择？
A：按资源ID或用户ID拆分，避免单一热点锁，例如将lock:user:1细化为lock:user:1:action:pay。

Q5：脚本是否可以替代Redisson？
A：简易脚本适合中小型项目（<100个节点），若需要复杂特性（如自动续期、公平锁、可重入），推荐直接使用Redisson。

延伸阅读：

Redis官方文档：SET命令与分布式锁
马丁·克莱普曼（Martin Kleppmann）关于分布式锁的经典论文
生产环境建议：结合日志监控锁获取失败率，设置熔断机制（如失败超过阈值后直接返回降级结果）

最终提示：简易脚本不等于简陋脚本，务必在生产环境加入全链路追踪（Trace ID），记录每次加锁/解锁的耗时与结果，以便排查锁竞争导致的性能瓶颈。