C++ 本身不提供分布式锁原语，必须依赖 Redis 等外部服务；核心是用 SET key val NX PX ms + 唯一 UUID token 实现加锁，用 Lua 脚本原子校验并删除解锁，严禁 GET+DEL 两步操作，避免死锁和误删。
用 Redis 实现 C++ 分布式锁最实际
直接说结论：C++ 本身不提供分布式锁原语，必须依赖外部服务（最常用的是 Redis），靠 SET 命令的原子性 + 过期时间 + 唯一 token 来实现。别碰 ZooKeeper 或 Etcd 的 C++ 客户端——接口重、依赖多、出错难排查，小项目纯属增加故障面。
核心逻辑就三步：尝试加锁（带 NX/PX/token）、业务执行、解锁（先校验再删）。中间任何一步失败都可能留下死锁，所以 token 必须是客户端生成的随机值（比如 UUID），不能用进程 ID 或时间戳。
-
SET lock:order_123 "8f4e7a2b-1c9d-4e8f-a0b1-c2d3e4f5a6b7" NX PX 30000—— 成功返回OK表示抢到锁，失败返回(nil) - 解锁必须用 Lua 脚本保证“校验+删除”原子性：
EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:order_123 8f4e7a2b-1c9d-4e8f-a0b1-c2d3e4f5a6b7 - 不要用
GET + DEL两步操作解锁——竞态下可能删掉别人刚续上的锁
为什么不用 std::mutex 或 boost::interprocess::scoped_lock
这些是进程内或同一台机器多进程间的同步原语，完全不跨网络。拿 std::mutex 去“锁分布式资源”，就像用自行车锁锁银行金库门——语法上没报错，但根本不起作用。
常见误解是“我用了共享内存 + boost::interprocess，应该能跨进程”。错。共享内存只在单机有效；一旦服务部署在 Kubernetes 多个 Pod，或不同物理机上，这些锁彻底失效。
立即学习“C++免费学习笔记（深入）”；
- 所有本地锁机制（
pthread_mutex_t、std::shared_mutex、boost::interprocess::named_mutex）都只对当前 OS 的地址空间有效 - 所谓“分布式”必须满足：锁状态对所有节点可见、变更操作全局原子、有超时自动释放能力
- 试图自己基于 TCP 实现分布式锁协议？CAP 理论会立刻教你做人——要么牺牲一致性，要么卡住可用性
Redis 加锁失败后怎么重试才不伤业务
轮询重试是最容易写的，也是最容易把 Redis 打挂的。高频 SET ... NX PX 请求在锁竞争激烈时会造成大量无效连接和命令堆积。
正确做法是“指数退避 + 随机抖动”：首次失败等 10ms，下次等 20–40ms（加 ±5ms 抖动），再下次 40–80ms……上限建议设为 500ms。同时必须设总超时（比如 3s），避免无限等待。
- 别用
usleep(10000)硬等——阻塞线程，浪费资源；改用异步等待或协程（如 libco、cppcoro） - 重试期间检查业务是否已超时：比如下单接口 SLA 是 800ms，锁等待超过 600ms 就该直接返回失败，而不是硬扛
- 记录每次重试的耗时和失败原因（
NOAUTH、CLUSTERDOWN、OOM command not allowed），这些比“加锁失败”更有诊断价值
Redlock 算法在 C++ 里基本没必要用
Redlock 是 Redis 官方提的多节点锁方案，理论强一致性，但实际落地问题很多：时钟漂移难校准、网络分区时行为不可控、C++ 客户端几乎没人完整实现过。你真需要它，说明系统规模已经大到该用专门的协调服务了（比如 Consul 的 session + KV 锁）。
对绝大多数 C++ 后端服务（订单、支付、库存），单 Redis 实例 + 正确的 SET 参数 + token 校验 + 合理超时，足够应对 99.9% 场景。Redis 故障时，宁可降级为本地限流（std::atomic_int 计数），也别强行上 Redlock 增加复杂度。
- Redlock 要求同时写多数派节点，C++ 客户端得维护多个
redisContext*并做并发 SET，错误处理路径爆炸式增长 - Redis Cluster 模式下，key hash slot 可能迁移，
SET命令可能被重定向，Redlock 的“同时写”前提直接崩塌 - 真正关键的是锁粒度——与其纠结 Redlock，不如把
lock:order_123拆成lock:order_123:payment和lock:order_123:inventory，减少冲突
最常被忽略的一点：锁的过期时间必须大于业务最大执行时间，但不能大太多。设成 5 分钟，结果某次 GC 卡顿 6 秒，锁自动释放，另一个实例进来执行，数据就乱了。建议用监控埋点统计真实耗时，动态调整 PX 值。
