分布式场景下5个API全部返回后触发目标函数的系统设计咨询

首先要说明，单机flag变量只适用于单进程内的状态同步，跨多服务器的分布式场景下无法共享状态，还存在并发修改冲突、宕机数据丢失、无容错机制的问题，不符合需求要求。

以下是3种适配不同场景的可行实现方案：

方案1：分布式状态计数（实现成本最低，适配绝大多数场景） #

选择支持原子操作的分布式中间件（Redis、etcd均可）做状态存储，核心逻辑如下：

• 任务启动前生成全局唯一的task_id，在中间件中初始化两个关联存储：一个是存已完成子任务标识的Set结构，一个是存任务元信息的KV结构（包含目标函数地址、子任务总数5、超时时间等），给所有关联key设置合理的过期时间避免垃圾数据残留
• 每台发起API调用的服务器拿到对应的子任务ID，待API执行成功后，调用中间件的SADD原子命令将自己的子任务ID加入对应task_id的Set中
• 执行SADD后立刻获取当前Set的大小，如果返回值等于5，直接向第6台服务器发起目标函数的调用请求

注意事项：

• 所有状态修改必须用中间件提供的原子操作，不能用「读-改-写」的非原子逻辑，避免并发下计数错误
• 要补充异常处理逻辑：如果某台服务器的API调用失败，可以上报失败状态，到达失败阈值后直接触发告警流程，避免无限等待
• 要做幂等判断：哪怕同一子任务因为重试重复上报完成，Set结构会自动去重，不会出现计数虚高的问题

方案2：消息队列聚合消费（适合已有MQ基础设施的场景） #

如果团队已经部署了Kafka、RabbitMQ这类消息队列，可以直接用MQ做状态同步，不需要额外引入其他组件：

• 所有发起API调用的服务器，在API执行完成后，往同一个Topic发送一条子任务完成消息，消息携带全局task_id和子任务ID
• 第6台服务器启动一个专属消费者，按task_id分组聚合消息，当收到同一个task_id下的5条不重复的子任务完成消息后，直接执行本地的目标函数

优势是可以直接复用MQ的持久化、重试能力，不会因为某台服务器临时宕机丢失完成消息，可靠性更高。

方案3：分布式工作流编排（适合核心业务链路、未来有扩展需求的场景） #

如果是公司核心业务流程，后续可能会调整并行任务数量、增加依赖逻辑，直接用现成的分布式工作流组件即可，不需要自己手写状态管控逻辑：

• 在工作流组件中将5个API调用定义为并行执行的子任务，目标函数定义为所有子任务执行成功后的下游依赖任务
• 由工作流调度器统一管控所有子任务的执行状态、重试、超时逻辑，待所有子任务成功后自动触发目标函数执行
  常用的可选组件包括Temporal、Airflow、XXL-JOB的并行任务模式等，优势是可扩展性强，原生支持容错、告警、可视化监控能力，不需要重复造轮子。

选型建议 #

• 小项目、需求固定：选方案1，基于Redis实现最快半小时就能完成开发
• 已有MQ基建、对可靠性要求高：选方案2，复用现有组件稳定性更好
• 核心业务链路、后续流程会迭代：选方案3，长期维护成本更低

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