多Kubernetes Pod场景下如何确保条件触发的任务仅执行一次

你的场景本质是分布式环境下的定时任务互斥执行问题，针对Java应用部署在K8s的现状，以下是可直接落地的方案，按改造成本从低到高排序：

方案1：基于K8s原生Leader Election选主，无额外组件依赖 #

直接利用K8s原生的Lease资源实现选主，不需要引入任何第三方中间件：

• 核心逻辑：所有service A的Pod启动后自动参与选主，只有成功持有Lease的Leader节点才会执行每5分钟一次的service B状态检查与task T触发逻辑，非Leader节点仅正常处理业务流量、维持Lease探针即可，不运行定时检查逻辑
• 配置建议：Lease续期周期设置为10-15s，远小于5分钟的检查间隔，避免Leader节点宕机后锁长时间不释放导致任务漏跑；选主逻辑可直接使用K8s官方Java客户端的client-java-extended选主组件实现，不需要自己重复造轮子
• 优势：除了能保证任务唯一执行，还能避免4个Pod同时请求service B造成的无效流量压力

方案2：基于分布式锁做执行互斥，最小化代码改动 #

不需要调整现有所有Pod定时检查service B的逻辑，仅在执行任务前加一层互斥判断即可，改造成本极低：

• 核心逻辑：保留现有每Pod每5分钟检查service B状态的逻辑，当Pod检测到触发条件满足时，先尝试抢占一个绑定当前检查周期的分布式锁，抢锁成功才执行task T，抢锁失败直接跳过本次周期即可
• 锁实现参考：如果现有技术栈已经用Redis，直接用Redisson的带过期时间可重入锁即可；如果已有etcd/ZooKeeper，用其临时节点实现互斥锁即可，不需要额外引入新组件
• 锁配置注意：锁key必须绑定当前5分钟的时间窗口，例如key格式为lock:svc-a:task-t:${System.currentTimeMillis() / 300000}，锁过期时间设置为60s（覆盖task T的最大执行时长即可），避免上一周期任务执行超时占锁导致下一周期任务无法执行
• 适用场景：原有检查逻辑改动成本高，团队已经有成熟分布式锁组件的场景

方案3：定时逻辑与业务Pod解耦，从架构上规避多副本冲突 #

如果定时检查逻辑和service A的在线业务逻辑耦合度低，可以直接把定时逻辑拆分出来独立部署：

• 核心逻辑：把内嵌在service A里的5分钟检查、任务执行逻辑抽成独立组件，有两种部署方式：
  • 用K8s原生CronJob资源配置5分钟调度一次，将并发策略设置为Forbid，从平台层保证同一时间只有一个任务实例运行
  • 将抽离的任务组件部署为1副本的独立Deployment，配置节点故障自动漂移、反亲和策略避免单点故障
• 优势：业务Pod完全不需要感知定时任务逻辑，职责拆分清晰，不会因为业务Pod扩缩容影响定时任务的执行规则

通用兜底要求：无论选择哪种方案，task T的业务逻辑必须实现幂等，作为极端场景（网络分区、锁过期、选主脑裂）下的最后一道防线，避免重复执行造成业务脏数据。

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