Go 服务分布式锁 4 方案对比（Redis SETNX / etcd Lease / PG Advisory Lock / 本地文件锁）+ 可运行 benchmark 脚本 + 选型决策矩阵

背景

团队正在做订单服务的分布式锁选型，4 个候选方案（Redis SETNX+TTL、etcd lease+concurrency、PostgreSQL pg_advisory_lock、本地文件锁）各自适用场景不同，但现有资料多为"推荐用 Redis"的结论式文章，缺少同一硬件 + 同一并发模型下的横向 benchmark 数据，也没有把"脑裂窗口期 / 续租失败 / 客户端宕机"等边界场景量化对比。

我需要一个可复现的对比实验，输出一份能直接进设计评审的选型依据。

最终要什么

1. 4 个可独立运行的 Go benchmark 程序（每方案一个 main.go，go run 直接跑）：

   • Redis：SET key val NX PX ttl，Lua 脚本释放
   • etcd：concurrency.NewMutex，lease TTL 10s，keepalive
   • PG：pg_advisory_lock(key) / pg_try_advisory_lock(key)
   • 本地文件锁：flock（对照基线，验证本地锁上限）

2. 统一压测模型（4 方案必须跑同一组参数）：

   • 并发度：1 / 10 / 100 goroutine
   • 持锁时间：10ms / 100ms / 500ms
   • 每组合跑 3 轮，取 P50 / P99 / P999 延迟 + 吞吐（ops/s）
   • 输出格式：CSV 数据表 + 一张 Markdown 汇总表

3. 选型决策矩阵（Markdown 表格，维度：获取延迟 / 释放延迟 / 吞吐上限 / 脑裂风险 / 续租可靠性 / 运维成本 / 适用场景），每项给出"优 / 中 / 差"评级并附一句理由。

4. 一篇 1000–2000 字的对比总结文章，要求：

   • 开头先给结论（哪 2 个方案最值得选、为什么）
   • 中间给 benchmark 数据 + 边界场景分析（续租失败、客户端 OOM、网络分区）
   • 结尾留 2–3 个开放问题引发讨论（例如："etcd 续租失败后已获锁节点是否应主动释放？"）

输入与上下文

• Go 1.21+（go.mod 写死版本）
• Redis 7.2 单节点（localhost:6379）
• etcd v3.5 单节点（localhost:2379）
• PostgreSQL 15 单实例（localhost:5432，需预建 public schema）
• 硬件基线：4 核 8G Docker 容器（脚本里用 runtime.NumCPU() 打印确认）
• 依赖尽量精简：go-redis/v9、go.etcd.io/etcd/client/v3、lib/pq 或 pgx/v5、标准库 os/flock

交付格式

• 一个 GitHub 可 clone 的目录结构（附件打包上传）：

  dist-lock-bench/
  ├── README.md          ← 环境准备 + 一键跑全部 benchmark 的 Makefile
  ├── redis/main.go
  ├── etcd/main.go
  ├── pg/main.go
  ├── flock/main.go
  ├── bench/             ← 公共压测框架（并发模型、计时、CSV 输出）
  ├── report.md          ← 汇总表 + 决策矩阵
  └── summary.md         ← 1000–2000 字对比总结（含开放问题）
  

• 附件上传完整压缩包（.zip 或 .tar.gz）
• 正文里贴出决策矩阵表格 + 3 个最关键的 benchmark 数据点

开放问题（希望总结里能回应）

1. etcd lease 续租失败时，已获锁的节点是"继续持锁等续租恢复"还是"立即释放"？两种策略的代价分别是什么？
2. PG Advisory Lock 在连接池场景下，连接归还后锁是否自动释放？这对"事务内加锁"模式有什么影响？
3. 本地文件锁在容器内（同一 PID namespace）和宿主机上表现是否一致？