基于Kafka的时序系统路由滑单与事务补偿最佳实践咨询

MassTransit Routing Slip 适配Kafka的可行性 #

直接给结论：MassTransit的Routing Slip完全可以在Kafka场景下使用，而且刚好匹配你需要的顺序执行、条件路由和补偿回滚需求。

具体实现方式：

• 替换原生Confluent.Kafka组件，改用MassTransit的MassTransit.Kafka包，它封装了Kafka生产消费逻辑的同时，无缝对接Routing Slip的活动编排能力。
• 将每一步操作拆为独立的Activity：
  • 第一个Activity：负责向第一个Kafka主题发送数据（替代自定义生产者）
  • 第二个Activity：监听第一个主题消息，完成校验后向第二个主题发送数据
  • 第三、第四个Activity：根据校验结果做条件路由，满足条件执行第三个，否则执行第四个
• 补偿逻辑自动触发：每个Activity可定义Compensate方法，当后续步骤失败时，MassTransit会自动按逆序调用之前所有Activity的补偿逻辑——比如第三个主题执行失败，先触发第二个Activity的补偿（回滚第二个主题状态），再触发第一个Activity的补偿（回滚第一个主题状态）。

需要注意的细节：

• 为每个Kafka主题配置对应端点，MassTransit会自动处理消息确认、重试及补偿触发时机。
• 条件路由直接通过Routing Slip的AddActivity结合When表达式实现，无需自行编写复杂分支判断。

不用MassTransit的替代方案 #

如果坚持使用原生Confluent.Kafka组件，手动实现也可完成需求，但需自行处理以下核心逻辑：

1. 补偿日志+逆序回滚 #

• 每完成一步操作，向专门的补偿日志主题写入操作记录，包含操作类型、数据唯一标识、当前状态。
• 当某一步失败时，从补偿日志主题读取所有已完成的操作记录，按倒序执行回滚：比如第三个主题失败，先处理第二个主题的回滚（如发送撤销消息给第二个主题的消费者，使其恢复原有状态），再处理第一个主题的回滚。

2. 状态机管控流程 #

• 可使用Automatonymous（MassTransit配套状态机库，也可单独使用）或自定义状态机，全程跟踪流程状态（如「已发主题1」「已验证发主题2」「已发主题3/4」）。
• 状态机监听每个步骤的执行结果，一旦失败就触发状态回退，并调用对应步骤的补偿方法。

3. 依赖Kafka事务保证原子性 #

• 使用Confluent.Kafka的ITransactionalProducer事务生产者，确保每一步的消息发送和补偿日志写入在同一个事务中，避免出现「操作完成但补偿日志未写入」的情况。

选型建议 #

• 优先选择MassTransit Routing Slip：它已封装路由、补偿、重试等复杂逻辑，无需从零搭建，且原生支持Kafka，能大幅减少代码量和出错概率。
• 若必须使用原生组件：重点保障补偿日志的持久化和状态机的状态管理，同时务必依赖Kafka事务保证操作原子性。

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