如何快速搭建一个支持分布式事务的Saga模式协调模块-Golang-PHP中文网

dtm是目前最省心的saga协调器选择，支持多语言、开箱即用，docker一条命令即可启动；需严格校验trans_type、steps数组及每个step的action和compensate url，补偿接口必须实现幂等以应对重试。

如何快速搭建一个支持分布式事务的saga模式协调模块

用 DTM 快速启动 Saga 协调器

直接上生产可用的协调模块，DTM 是目前最省心的选择。它不依赖语言栈、不强制改数据库、HTTP/gRPC 接口开箱即用，docker run 一条命令就能拉起协调服务。

常见错误是试图自己写协调器——Saga 的状态机、幂等、悬挂、空补偿、重试退避、事务日志持久化，这些细节加起来远超业务逻辑本身。DTM 已把它们封装成 /api/saga 接口，你只需定义分支和回调地址。

下载并运行 DTM Server：docker run -d --name dtm -p 36789:36789 -p 36790:36790 yedf/dtm:1.22.0
确认服务就绪：curl http://localhost:36789/health 返回 {"status":"success"}
无需配置数据库（默认用内存存储），如需高可用，挂载 -v /path/to/dtm.yaml:/app/dtm.yaml 并启用 store.type = mysql

定义 Saga 分支时必须传哪些参数

调用 /api/saga 提交全局事务时，DTM 不校验业务逻辑，但会严格校验结构。漏掉或错配字段会导致 400 Bad Request 或静默失败。

关键字段只有三个：全局唯一 trans_type（固定填 saga）、steps 数组、每个 step 的 action 和 compensate URL。其余如 gid（建议用 UUID v4）、timeout（单位秒，默认 60）可选但强烈建议显式设置。

action 和 compensate 必须是完整可访问的 HTTP 地址，且服务端要能处理 POST 请求
每个 step 的 action 返回 200 才进入下一步；返回非 2xx 或超时，DTM 立即触发对应 compensate
DTM 默认对所有请求加 X-Dtm-Gid header，你的服务需透传该值用于幂等判断

补偿接口为什么总被重复调用

这不是 DTM 的 bug，而是 Saga 模式下最常踩的坑：补偿操作没做幂等。DTM 在网络抖动、超时、协调器重启时会重发 compensate 请求，这是设计使然，不是异常。

闪光简历

闪光简历是一款用于 AI 生成、排版、测评和优化简历的在线求职工具。

下载

你的 compensate 接口必须能识别重复请求并安全退出。最简单可靠的做法是：查库确认原 action 是否已执行，若未执行则跳过；若已执行，则执行反向操作并记录 compensated = true 标志位。

避免只靠“查当前状态”判断——比如库存服务补偿时查“当前库存是否已回滚”，这在并发下不可靠
推荐方案：在业务表加 compensated_at 字段，补偿接口先 UPDATE ... SET compensated_at = NOW() WHERE gid = ? AND compensated_at IS NULL，再根据影响行数决定是否真正执行回滚逻辑
DTM 会传递 X-Dtm-Trans-Type 和 X-Dtm-Gid，务必在补偿日志里打出来，方便排查重试链路

协调器宕机后事务状态怎么恢复

DTM 默认用内存存事务状态，重启后未完成的 Saga 就丢了——这在开发环境没问题，但生产必须切到持久化存储。

切换方式很简单：改 dtm.yaml 中的 store.type 为 mysql，填好 host/port/user/password/database，然后执行 DTM 提供的建表 SQL（sql/dtm_schema_mysql.sql）。之后所有事务状态都会写入 trans_global 和 trans_branch 表。