Redlock在C++中无现成库，需基于hiredis或redis-plus-plus实现：用CLOCK_MONOTONIC计时、并发向≥5个独立Redis节点SET随机值、多数派成功才加锁、Lua脚本安全解锁、禁用续期依赖超时兜底。
Redlock在C++里没有现成库，得自己拼装
别指望 std::mutex 或 Boost 里有 Redlock——它本质是 Redis 客户端 + 时钟 + 网络重试的组合逻辑，C++ 生态没标准实现。主流方案是用 hiredis 或 redis-plus-plus 做底层通信，再按 Redlock 论文（Antirez 提出）补上租约、时钟漂移校正、多数派确认这些环节。
最容易踩的坑是直接拿单个 Redis 实例的 SET key value NX PX 30000 当 Redlock 用——那只是普通分布式锁，不是 Redlock。Redlock 要求至少 5 个独立 Redis 主节点（推荐奇数），客户端必须向大多数（N/2+1）成功写入才算加锁成功。
加锁流程必须严格遵循「获取时间戳→并发请求→检查成功数→计算剩余租期」
Redlock 的核心不是“能不能设值”，而是“有没有在合理时间内拿到多数节点的确认”。关键步骤不能省：
- 调用
clock_gettime(CLOCK_MONOTONIC, &ts_start)获取单调时钟起点（不用std::chrono::system_clock，避免 NTP 调整干扰） - 对每个 Redis 节点并发执行：
SET key {random_value} NX PX {ttl_ms}，带唯一随机值（推荐std::random_device+std::mt19937_64生成 128bit hex 字符串） - 统计返回
OK的节点数；若< (N/2 + 1)，立即释放所有已成功的节点（用EVAL脚本比GET+DEL安全）并返回失败 - 计算实际耗时：
elapsed = now() - ts_start；若elapsed > ttl_ms / 2，认为网络延迟过大，锁不可靠，主动放弃
解锁必须用 Lua 脚本，且只删自己设的 value
解锁不是简单 DEL key，否则可能误删别人持有的锁。必须用原子 Lua 脚本验证 value：
立即学习“C++免费学习笔记（深入）”；
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
这个脚本要对每个 Redis 节点都执行一次。别漏掉——Redlock 解锁不要求多数派成功，但漏掉任意一个，就可能留下残留锁，导致后续加锁失败或死锁。
常见错误：用 C++ 字符串拼接 Lua 脚本，没转义 {random_value} 中的特殊字符（比如 \0 或引号），导致 EVAL 报 ERR Error running script。
租期续期（renew）没法原子化，得靠外部心跳+超时兜底
Redlock 规范本身不支持续期。实践中如果业务操作可能超时，只能另起线程定期调用 SET key {same_random_value} XX PX {new_ttl_ms}（XX 确保只更新已存在 key）。但这不是原子的：万一续期请求刚发出去，主节点宕机切从，而从还没同步该 key，续期就失败了。
更稳妥的做法是：锁内操作自带超时控制（如 std::future::wait_for），并在加锁时预留足够 buffer（比如预估操作 5s，设 ttl=30s），同时依赖 Redis 的过期自动清理作为最终保障。别把续期当成可靠机制。
真正难的是时钟漂移——如果某台 Redis 服务器系统时间快了 2 秒，而你的客户端按本地时间算租期还剩 1 秒，其实锁已在服务端过期。生产环境必须用 chrony 同步所有节点时钟，并监控 clock_gettime(CLOCK_REALTIME) 与 CLOCK_MONOTONIC 的差值漂移量。
