分布式锁必须依赖redis等外部系统实现跨进程互斥，async函数本身不提供该能力；核心是用set key value nx px命令原子加锁，配合lua脚本比对value后安全删锁，并需规避单点故障、超时设置不当及非幂等操作等风险。
在 JavaScript 中，async 函数本身不提供分布式锁能力，因为 JS 运行时（如 Node.js 单进程、浏览器）天然是单线程事件循环模型，无法直接跨进程、跨服务、跨机器协调资源。所谓“分布式锁”，必须依赖外部系统（如 Redis、ZooKeeper、etcd 等）来实现多实例间的互斥。下面分场景说明怎么做、关键点在哪、常见坑怎么避。
为什么不能只靠 await + Promise 实现分布式锁
很多人误以为用 let locked = false 配合 async/await 就能锁住——这是本地内存锁，仅对当前进程有效。一旦服务部署多个副本（如 PM2 集群、K8s 多 Pod），每个实例都有独立内存，彼此完全不知情，锁就失效了。
真正需要的是：一个所有服务实例都信任的第三方存储，能原子性地判断“锁是否存在”并“尝试获取锁”（即 SETNX 或类似语义）。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
用 Redis 实现最简可用的分布式锁（推荐 Redlock 变体）
Redis 是最常用选择，核心靠 SET key value EX seconds NX 命令：只有 key 不存在时才设置，且带自动过期，避免死锁。
-
获取锁：生成唯一 client_id（如 UUID），执行
SET lock:order:123 "abc-def-456" EX 10 NX；返回 OK 表示抢锁成功 -
释放锁：不能直接 DEL（怕删了别人持有的锁），要用 Lua 脚本比对 value 再删：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end -
续期（可选）：若任务可能超时，需另起定时器用
PEXPIRE延长 TTL（注意仅限自己加的锁）
Node.js 中封装成易用的 async 工具函数
借助 ioredis 或 redis 客户端，封装成 Promise 化接口：
async function withDistributedLock(lockKey, ttlSeconds = 10, fn) {
const clientId = crypto.randomUUID();
const client = redisClient; // 复用已连接的 Redis 实例
// 尝试加锁
const res = await client.set(lockKey, clientId, 'EX', ttlSeconds, 'NX');
if (!res) throw new Error('Lock not acquired');
try {
return await fn();
} finally {
// 安全释放锁（Lua 脚本）
await client.eval(
'if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end',
1,
lockKey,
clientId
);
}
}
// 使用示例
app.post('/api/order/:id/pay', async (req, res) => {
const { id } = req.params;
try {
const result = await withDistributedLock(
`lock:pay:${id}`,
30,
() => processPayment(id)
);
res.json({ success: true, data: result });
} catch (err) {
res.status(423).json({ error: 'Resource busy' });
}
});
生产环境必须注意的细节
简单 SETNX 不足以应对网络分区、主从切换等真实故障：
- 不要依赖单 Redis 实例：主节点宕机未同步到从节点，新主可能允许重复加锁。建议用 Redis Cluster 或 Redlock（向 ≥N/2+1 个独立 Redis 实例请求锁）
- 锁的 TTL 必须远大于业务平均耗时，但也不能太长（影响故障恢复速度），建议设为「预期最大执行时间 × 2」
- 业务代码必须幂等：即使锁失效导致并发进入，也要保证多次执行结果一致（比如支付接口查订单状态再操作，而非无条件扣款）
- 避免在锁内做不确定耗时操作：如调用第三方 HTTP 接口、大量计算——应尽量缩短临界区，或拆分为“锁内校验 + 异步执行”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
