传奇和分布式交易

传奇是一种长期的业务交易，在不同的服务/存储中分为一系列本地步骤。每个步骤都具有补偿作用，可在部分失败时回滚步骤效果。与2PC/3PC不同，传奇不会阻止全球锁定，并且适用于允许事件一致性的微服务，多区域和高负载。

1）何时选择传奇（何时不选择）

• 冗长/多阶段业务流程（订单→付款→准备→交付）。
• 没有共享事务的不同域和存储。
• 需要高可用性和水平扩展。

• 固体ACID原子性是关键的（例如，在单个注册表内转移大量）。
• 没有明确的可赔偿性（不可能"保留"或取消效果）。
• 法律/监管限制要求严格隔离和"即时"不变性。

2） Sag模型

1.编排（Saga Orchestrator）：中央协调员管理步骤和补偿。

优点：显式流量、误差控制、简化的遥测。
缺点：集中点，"胖"协调员的风险。

2.编舞（Choreography）：没有中心-步骤是由事件引发的（"服务A使X →服务B反应"）。

优点：连接性弱,缩放简单。
缺点：更难跟踪/借记流，规则"蔓延"的风险。

3.TCC （Try-Confirm/Cancel）：每个步骤都是"冗余"（Try）,然后是确认（Confirm）或取消（Cancel）。

优点：更接近伪双相协议,管理资源。
缺点：实现接口的成本更高；要求"Try"持有人的时间。

3）步进和补偿设计

不变式：明确表述步骤"之前/之后"的真实内容（例如"残余≥ 0"）。
补偿≠反向交易：这是取消业务效果的逻辑操作（返还，释放，恢复）。
相等性：步骤和补偿器都必须安全重复（通过"operation_id"）。
Taymauts：每个步骤都有截止日期；迟交会引发赔偿。
不退款效果：将它们单独固定（通知、电子邮件）并允许"best effort"。

4）一致性和顺序

Eventual consistency：用户可以看到时间差异；UX-具有"等待"/旋转器/状态。
按键顺序：交换步骤按业务键（order_id)分组以排序事件。
重复数据消除：使用TTL存储处理日志（'operation_id' →状态）。

5）运输和可靠性

Outbox模式：将事件写入同一事务内的本地"outbox"表格,然后异步发布到总线。
收件箱/Idempotency store：消费者方面-已经处理的消息日志。
Exactly once有效："outbox+idempotent consumer"给出了实际的"恰好一次"。
DLQ：用于具有丰富元信息和安全红土的"有毒"消息。

6）错误策略，retrai，backoff

我们只重复偶数步骤；记录操作-使用"Idempotency-Key"。
指数backoff+jitter；限制尝试和传奇的总截止日期。
当系统降解时-电路断路器和分解分解（例如，取消传奇的次要分解）。
业务冲突（"409"）-同意或补偿并完成后的重复。

7）管弦乐队： 职责和结构

• 传奇状态跟踪："PENDING → RUNNING → COMPENSATING → DONE/FAILED"。
• 计划步骤，截止日期，taymout，retrai。
• 漫游事件并启动补偿。
• 协调员操作的相等性（命令日志）。
• 可观察性：在逻辑/trace/度量标准中 "saga_id"的相关性。

• 表"saga"，"saga_step"，"commands"，"outbox"。
• "saga_id"、"business_key"、"status"、"next_run_at"上的索引。

8）编舞： 针对"雪球"的规则和保护"

活动合同：计划和审查（Avro/Proto/JSON计划）。
清晰的语义："事实事件"vs"命令"。
连锁店：发现不匹配的服务发布了"失败"/"竞争"事件。
警报和Alerta到"无限循环"。

9）TCC： 实用细节

尝试：具有TTL的资源储备。
Confirm：固定,释放临时锁定。
Cancel：储备回滚（无副作用）。
Garbage collection：在TTL（等效癌症）之后自动取消Try。
等效的Confirm/Cancel：重播是安全的。

10）示例（言语方案）-"付款和交付订单"

1.CreateOrder（本地）→ outbox："OrderCreated"。
2.PaymentService："尝试"储备（TCC）；→ "PaymentReserved"成功，"PaymentFailed" →失败。
3.InventoryService：货物储备；缺少"InventoryFailed" →。
4.ShippingService：创建交付插槽（可取消）。
5.如果"失败"的任何举动→乐团将按相反的顺序触发赔偿："CancelShipping" → "ReleaseInventory" → "PaymentCancel"。
6.如果所有人都→ "PaymentConfirm" → "OrderConfirmed"。

11）编曲家的伪代码

pseudo startSaga(saga_id, order_id):
steps = [ReservePayment, ReserveInventory, BookShipment, ConfirmPayment]
for step in steps:
res = execWithRetry(step, order_id)
if!res.ok:
compensateInReverse(steps_done(order_id))
return FAIL return OK

execWithRetry(step, key):
for attempt in 1..MAX:
try:
return step.run(key)    # идемпотентно catch RetryableError:
sleep(backoff(attempt))
catch NonRetryableError:
return FAIL return FAIL

compensateInReverse(done_steps):
for step in reverse(done_steps):
step.compensate()       # идемпотентно

12）可观察性和操作SLO

Tracing：单个"saga_id"，注释"step"，"attempt"，"decision"（运行/compensate/skip）。

• 成功/错误sag（%），平均持续时间，p95/p99。
• 补偿传奇的比例，补偿的最高原因。
• 队列/outbox泻湖，步伐回避。
• Logi/Audit：编排器解决方桉、资源ID、业务密钥。

13）测试和溷乱

在每个步骤中注入错误：taymauts，"5xx"，业务冲突。
出局事件、重复、跳过（drop）。
长尾巴潜伏→测试截止线和补偿。
质量传奇→队列中的WFQ/DRR和caps检查，不存在"线头块"。
在DLQ的步骤和整个传奇中重复。

14）多重性、区域、合规性

事件和sag存储库中的"tenant_id/plan/region"标签。
住宅：数据/事件不会离开该地区；跨区域传奇设计为本地传奇+聚合事件的联合。
优先级：VIP传奇具有更大的配额重量；绝缘的per tenant工人。

15）售前支票清单

• 每个步骤都有明确的补偿器，两者都是相等的。
• 选择模板：编排/编舞/TSS；说明责任范围。
• Outbox/Inbox已实施,通过"operation_id"进行重复数据消除。
• Retrais Policy：背靠背、尝试限制和一般的传奇截止日期。
• 事件合同是经过验证的，有计划的验证。
• DLQ和安全的重新分区配置。
• 遥测：度量,跟踪,相关性'saga_id'。
• 操作剧本：手动cancel/force-confirm,动画"挂起"传奇。
• 混沌和负载测试通过，确定了SLO/错误预算。

16）典型错误

没有补偿剂或"不洁"（有副作用）。
缺少Idementity/dedup-双重和"摇摆"状态。
"传奇中的传奇"没有明显的界限-周期和相互锁定。
没有截止日期→"永恒"的传奇和资源流失。
编曲器将状态"存储在内存中"，而无需稳定的支架。
没有遥测中心的编舞→"隐形"故障。
不透明的UX：用户看不到中间状态。

17）快速食谱

SaaS经典：编排+outbox/inbox，指数反射，DLQ，UI中的传奇状态。
强资源不变量：具有TTL储备和GC癌症的TCC。
高体积/负载：事件编排+严格的幂和按键的度量。
多区域：本地传奇+最终聚合；避免全球封锁。

二.结论

传奇是在没有全球锁定的分布式系统中获得可预测的一致性的方法。清晰的补偿器、等效性、可靠的交付（outbox/inbox）、定时和撤退纪律以及遥测和花花公子是确保复杂的业务流程在负载增加、服务数量和地理位置不断增加的情况下保持可持续和可读性的关键。