知识卡片
Saga模式与补偿事件:无法回滚就撤销
内容
Saga模式描述的是分布式系统里长期运行的事务,核心思想很直白:”当你无法回滚任务时,就撤销它们。”BPMN通过补偿事件(compensation event)支持这个模式,把每个正常任务和它对应的撤销任务关联起来——一旦流程中的任何环节出错,工作流引擎会负责执行所有必要的撤销动作,清理所有受影响的、已经执行过的任务。这里的”撤销”未必是彻底回滚:入网流程里SIM卡可能已经真的发运给客户了,撤销只能是停用它,而且一次撤销有时还会涉及多个连带任务(比如同时要通知客户)。引入补偿逻辑一定会让流程模型变得更复杂,这是不可避免的代价——没有ACID事务兜底,业务事务天然更复杂,因为”回滚”这件事被从数据库层转移到了应用层,得靠人为设计好每一步对应的撤销逻辑。实现Saga模式并不是非工作流引擎不可,[[流式处理实现流程自动化的弹球机架构困境]]等章节也提过其他实现路径,但工作流引擎在这里特别有帮助,原因有两点:一是远程通信场景通常本就需要引擎提供的长期运行能力;二是在和业务方讨论业务事务或商定解决不一致的策略时,可视化的图形流程模型能提供比代码更直观的沟通基础。
参考来源
- 位置:《流程自动化实战:系统架构和软件开发视角》第9章《工作流引擎与集成挑战》"9.2.3 Saga模式和补偿"(源文件:_epub-src/EPUB/xhtml/Section0001_0013.xhtml)
- 结论依据:原文明确Saga模式"无法回滚就撤销"的核心思想,用SIM卡已发运只能停用而非彻底回滚的例子说明补偿的实质,并说明补偿逻辑增加的复杂度是回滚职责从数据库层转移到应用层的必然代价,直接支撑本卡片结论。
- 原始内容:其主要思想很简单:当你无法回滚任务时,就撤销它们……这种撤销并不一定意味着完全回滚。SIM卡可能已经发运给客户,因此你只能停用它……没有ACID,业务事务会变得更加复杂,因为回滚基本上被转移到了应用层面。