Beego 本身不提供分布式锁，需依赖 Redis、ZooKeeper 或数据库手动集成；单机 sync.Mutex 无效，因跨节点不共享；典型场景包括秒杀、定时任务重复执行和配置热更新不一致。
Beego 本身不提供分布式锁组件，所有基于 Beego 的分布式锁实现，都依赖外部服务（Redis、ZooKeeper、数据库）和手动集成。直接在 Beego 控制器里调用 synchronized 或 sync.Mutex 完全无效——它们只在单进程内起作用，跨节点完全失效。
为什么 Beego 项目需要自己集成分布式锁
Beego 是 Go 语言的 Web 框架，运行时默认是多进程（或 goroutine 并发）模型，但部署在多台机器上时，每个实例彼此隔离。典型场景如：
- 秒杀接口：多个 Beego 实例同时收到
/api/kill?goods_id=1001请求，若无分布式锁，库存会超扣 - 定时任务：用
beego.Cron启动的 job 在集群中重复执行（比如清理过期缓存） - 配置热更新：多个节点同时拉取并写入新配置，导致中间态不一致
这些都不是 Beego 框架能自动解决的问题，必须由你显式引入锁机制，并确保加锁/解锁逻辑包裹在业务关键路径中。
Redis 实现最常用：用 redigo 或 go-redis 配合 SET NX + Lua
Go 生态中没有官方 Redisson，但可用 go-redis/redis/v9 自行封装安全锁。核心要点不是“设个 key”，而是解决两个问题：锁被别人释放 和 锁提前过期。
- 加锁必须带唯一标识（如
uuid.NewString()），写入 value；不能只用固定字符串 - 使用
SET key value NX PX 30000命令，NX保证原子性，PX防死锁 - 解锁必须用 Lua 脚本校验 value 是否匹配，否则
DEL会误删别人锁 —— 示例脚本：if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end - 不要依赖客户端续期逻辑；高并发下 goroutine 调度延迟可能导致看门狗失效，建议业务侧控制 lease 时间（如预估操作最长耗时 × 2）
ZooKeeper 实现需注意临时顺序节点生命周期
Beego 项目若已集成 ZooKeeper（例如用于服务发现），可复用连接做分布式锁，但要注意 Go 客户端（如 github.com/samuel/go-zookeeper/zk）对 EPHEMERAL_SEQUENTIAL 节点的管理较底层。
- 创建节点路径应为
/locks/goods_1001/{lock-000000001}，不能硬编码固定路径 - Watch 前一个节点时，必须处理
zk.ErrNoNode（前序节点已消失）和连接断开重试 - ZK 锁释放靠 session 过期，而 Beego 默认不管理 zk session 心跳；需单独启 goroutine 调用
conn.ExistsW()维持活跃 - 不推荐新手直接手写 ZK 分布式锁 ——
go-zookeeper不像 Curator 那样封装好InterProcessMutex，容易漏掉异常分支
数据库方案只适合低频且已有强事务依赖的场景
如果 Beego 项目已重度使用 MySQL，且并发量不高（QPS SELECT ... FOR UPDATE 简单兜底，但必须满足：
- 事务隔离级别为
REPEATABLE READ或更高，否则可能幻读导致锁失效 - WHERE 条件必须命中索引（如对
resource_name建唯一索引），否则会升级为表锁 - 绝不允许在事务外调用
Unlock()；Beego 的orm.Raw().Exec()必须和业务 DB 事务绑定 - 锁表字段建议包含
holder_ip和acquired_at，便于运维排查谁卡住了锁
真正棘手的不是“怎么加锁”，而是“锁粒度是否合理”——用 goods_id 做锁 key 可能导致热点商品锁争抢严重，此时应考虑分段锁（如 goods_id % 16）或读写分离降级策略。这些决策无法靠框架自动完成，得结合你的压测数据来定。
