部署生产环境时阻止集群作业运行的高可维护方案咨询

一、锁文件方案的竞态问题 #

你担心的竞态条件确实存在，核心问题在于作业的“检查锁文件+启动执行”不是原子操作：比如某个作业刚检查完锁文件不存在，正准备启动的瞬间，部署进程刚好创建了锁文件，这时候作业还是会正常运行，达不到阻止的目的。

如果只是简单判断文件是否存在，这种竞态几乎无法避免。不过可以通过Linux的flock命令优化，利用它的原子锁机制：部署时用flock创建排他锁并持有，作业启动前尝试获取锁，获取失败则等待。这种方式能把“检查+等待”变成原子操作，大幅降低竞态概率，但前提是锁文件放在所有节点都能访问的共享存储（比如NFS）上，否则集群各节点的锁状态不一致，还是会有问题。

另外你提到的cron清理过期锁是个不错的兜底，但它解决的是部署异常导致锁长期存在的问题，没法解决竞态本身。

二、PostgreSQL数据库锁方案 #

用数据库做锁的核心优势是天生的原子性和集群一致性，完全避免竞态问题。具体可以这么实现：

1. 创建一张专门的锁表，比如deployment_locks，包含is_locked（布尔型）、expires_at（时间型）两个核心字段；
2. 部署开始时，原子更新表：设置is_locked = true，并把expires_at设为当前时间+30分钟；
3. 作业启动前，执行原子查询：如果is_locked为false，或者expires_at已过期（自动重置为false），则启动作业；否则等待到锁释放或超时；
4. 部署完成后，更新表将is_locked设为false。

这种方案不需要共享存储，所有节点共享同一个锁状态，过期处理也可以通过SQL自动完成，不用额外维护cron。

三、Capistrano的相关实现 #

Capistrano本身没有内置阻止作业运行的标准机制，但可以通过自定义任务实现：

• 在deploy:starting钩子中添加任务，创建锁（不管是锁文件还是数据库锁）；
• 在deploy:finished钩子中添加任务，释放锁；
• 如果用锁文件，要确保Capistrano在所有应用节点操作同一个共享存储上的文件；如果用数据库锁，直接在任务里调用SQL或ORM操作即可。

注意：Capistrano自带的deploy:lock是用来防止并行部署的，不是阻止作业运行，别搞混了。

四、可维护性对比 #

锁文件方案 #

• 优势：逻辑简单，不需要额外依赖，代码改动小，运维成本低；
• 劣势：
  • 必须依赖共享存储，否则集群节点锁状态不一致；
  • 即使优化用flock，还是可能受文件系统（比如NFS）的延迟影响；
  • 需要维护清理过期锁的cron，多了一个运维点；
  • 权限问题：部署用户和作业用户必须对锁文件目录有相同的读写权限。

PostgreSQL数据库方案 #

• 优势：
  • 彻底解决竞态问题，集群一致性有保障；
  • 无需共享存储，过期处理自动化，不用额外cron；
  • 可以扩展锁表字段（比如记录部署ID、操作人），方便排查问题；
• 劣势：
  • 依赖现有PostgreSQL实例，代码需要增加数据库操作；
  • 逻辑比锁文件稍复杂，需要写SQL或用ORM操作锁表；
  • 数据库不可用时会影响作业和部署，但生产环境数据库一般都是高可用的，风险可控。

五、总结 #

如果你的生产环境已经在用PostgreSQL，优先选数据库锁方案，它能彻底解决竞态问题，长期维护性更好；如果没有数据库依赖，且作业并发不高（通常4-8个），可以用优化后的锁文件方案（配合flock和共享存储），也能满足需求，但要注意共享存储的可靠性和权限问题。

内容的提问来源于stack exchange，提问作者Timur Shtatland