多机器人系统如何避免重复执行：Webhook、分区队列与 Outbox

机器人变多以后，脚本式处理会失控

一个 Telegram Bot 可以把所有逻辑写进单个 Webhook，但当机器人、群组、规则和账务同时增长后，重复投递、消息失序、外部 API 超时和权限差异会迅速把简单脚本拖入不可维护状态。

真正需要解决的不是“怎么回复一条消息”，而是如何让每个动作都有明确来源、幂等身份、执行顺序、权限边界和失败结果。

Webhook 只承担快速且确定的工作

Webhook 的职责应该收敛为验签、标准化、去重和入队。任何需要查大量业务数据、调用 Telegram API、解析图片或执行规则的慢操作，都应交给异步 Worker。这样既能快速响应平台，也能避免某个慢请求拖住所有更新。

• 验证每个 Bot 独立的 Webhook Secret。

• 将 update_id、bot_id 和来源群组组合成幂等键。

• 保存标准化事件，不直接相信外部传入的身份与权限字段。

• 完成可靠入队后立即返回，慢业务异步执行。

同一群组有序，不同群组并行

全局单队列虽然简单，却会让一个消息量大的群组遮住其他群组；完全并行又会造成入群、验证、记账和处置动作乱序。更合理的方式，是以群组作为分区键：同一群组保持顺序，不同群组并行消费。

分区策略不仅用于入站事件，也应该延伸到出站动作。删除消息、限制成员、批准入群和回复回调都要保持可追踪的执行次序。

为什么需要数据库 Outbox

如果业务数据已经提交，但发送 Telegram 动作之前进程崩溃，就会出现“账已经记了，消息没发”的不一致；反过来先调用外部 API，再提交数据库，也可能产生重复执行。

Outbox 模式把业务修改和待执行动作放在同一个数据库事务里。事务成功后，Action Worker 再读取 Outbox、调用 Telegram、记录结果并按策略重试。数据库因此成为事实来源，外部调用失败不会丢失业务意图。

幂等、重试和死信要一起设计

• 消费前检查幂等键，重复投递直接返回既有结果。

• 短暂网络错误采用指数退避，明确区分永久错误。

• 失败次数达到阈值后进入可人工复核的死信状态。

• 定期任务使用数据库锁或唯一约束，避免多实例重复执行。

• 运行表设置归档与清理策略，避免状态数据无限增长。

最终得到的是运营平台，而不是一组机器人

当 Webhook、分区队列、Outbox、RBAC 和审计共同工作时，多机器人系统才具备长期运营能力：动作可以重试、问题可以追溯、权限可以复核、群组可以扩展，部署也能从依赖个人经验变成可重复的生产流程。