一、为什么工单系统需要事件驱动一个上门服务订单创建后通常要触发派单、短信或推送通知、服务人员提醒、用户确认、地图轨迹、验收和结算。若这些动作都在一个HTTP请求中同步执行任何外部接口超时都可能导致整单失败系统也难以扩展。事件驱动的做法是订单服务先完成核心数据写入再发布ORDER_CREATED事件派单、通知、风控等模块分别消费。这样可以降低耦合但也引入了消息重复、丢失和乱序问题。二、“至少一次”通常比“恰好一次”更现实在大多数业务系统中追求端到端绝对“恰好一次”成本很高。更常见的策略是保证消息至少投递一次然后让消费端具备幂等能力。比如ORDER_ACCEPTED事件可能因网络重试被消费两次通知服务可以重复判断是否已发送结算服务则必须通过唯一业务键阻止重复入账。对工单系统而言重复通知尚可容忍重复结算则不可接受因此不同消费者需要不同强度的幂等策略。三、幂等表和业务唯一键可以建立event_consume_log表字段包括event_id、consumer_name、status、processed_at并对event_id与consumer_name建立唯一索引。消费者处理前尝试插入记录插入失败说明已经处理过。对于更关键的业务不能只依赖消费日志还应在业务表设置唯一约束。例如结算表以order_id和settlement_type作为唯一键师傅接单以work_order_id唯一绑定staff_id售后赔付以after_sale_id和payment_type限制重复。四、重试、延迟队列与死信队列处理失败不应无限立即重试。可以根据异常类型分类网络超时采用指数退避重试参数错误直接进入死信下游限流进入延迟队列业务条件尚未满足则等待下一次触发。死信队列不是“失败消息垃圾桶”而是人工与自动补偿的入口。后台应展示失败事件、原始载荷、异常堆栈、已重试次数和关联工单并支持重新投递、跳过或执行补偿。五、把可靠性落实到工单栈业务以工单栈类接单工具为例ORDER_CREATED可触发城市与技能匹配ORDER_ACCEPTED触发对用户和服务人员的双向通知ARRIVED触发履约凭证记录COMPLETED触发验收与结算。每个事件都应有唯一ID、发生时间、订单版本号和来源系统。借鉴Kafka可靠性并不是一定要使用Kafka而是采用同样的工程原则核心数据先落库事件可追踪消费端幂等失败可重试长期失败进入死信并可补偿。对于做饭、保洁、维修、安装等高频服务订单这些机制直接决定接单体验和履约稳定性。