分布式事务 — 别做，做了也尽量做小2PC / 3PC · Saga (Orchestration vs Choreography) · Transactional Outbox · Idempotency · Why Microservices Avoid Distributed Transactions

问题场景与约束

设计一个跨境电商「下单结账」流程，单次结账要同时完成 5 件事：

1. 订单服务 写订单（自己 Postgres）
2. 库存服务 扣库存（自己 Postgres）
3. 支付服务 调 Stripe 扣款（外部 API，不可回滚）
4. 积分服务 扣减积分抵扣（自己 DynamoDB）
5. 通知服务 发邮件 + Push（外部 SES / FCM）

规模：峰值 5k TPS 下单，单笔结账 P99 ≤ 800ms，0 笔超卖、0 笔重复扣款。5 个服务由 5 个团队拥有，没有共享数据库。任何中间步骤都可能失败：服务挂掉、网络分区、Stripe 504、消息丢失。

问题：这 5 步如何保证『要么都成功，要么都不发生（或可观测地补偿）』？这就是分布式事务。今天讲：教科书的 2PC/3PC 为什么在生产里几乎没人用、Saga 怎么落地、Outbox 怎么解 dual-write、为什么『最佳的分布式事务就是不做』。

高层架构

graph TD
    Client["客户端"]
    Orch["Saga Orchestrator
Temporal / Cadence
持久化每一步状态"]

    subgraph S1["订单域"]
        OrdSvc["Order Service"]
        OrdDB[("Postgres
orders + outbox")]
    end
    subgraph S2["库存域"]
        InvSvc["Inventory Service"]
        InvDB[("Postgres
reservations + outbox")]
    end
    subgraph S3["支付域"]
        PaySvc["Payment Service"]
        Stripe["Stripe API
外部 不可回滚"]
    end
    subgraph S4["积分域"]
        PtsSvc["Points Service"]
        PtsDB[("DynamoDB
+ idempotency table")]
    end
    subgraph S5["通知域"]
        Notify["Notify Service"]
    end

    CDC["Debezium CDC
读 outbox 表"]
    Kafka["Kafka
order.events"]

    Client --> Orch
    Orch -->|1 createOrder| OrdSvc
    Orch -->|2 reserveStock| InvSvc
    Orch -->|3 charge| PaySvc
    Orch -->|4 deductPoints| PtsSvc
    Orch -.->|5 async notify| Kafka
    OrdSvc --> OrdDB
    InvSvc --> InvDB
    PaySvc --> Stripe
    PtsSvc --> PtsDB

    OrdDB -.-> CDC
    InvDB -.-> CDC
    CDC --> Kafka
    Kafka --> Notify

    classDef orch fill:#2a1530,stroke:#ff7ab6,color:#e8eef5
    classDef ext fill:#3a2010,stroke:#ffb450,color:#e8eef5
    class Orch orch
    class Stripe ext

核心思路：用 Saga（Temporal/Cadence 编排）串起 5 步，每步是本地事务 + 失败时反向补偿；事件流走 Outbox + CDC（保证『DB 写成功 ⇒ Kafka 必发』）；通知这类弱事务用最终一致。整个系统没有一个 2PC。

关键技术点

1. 2PC / 3PC：教科书答案，生产负债

原理：两阶段提交（Two-Phase Commit）由一个 coordinator 协调多个 participant：

• Phase 1 (prepare)：coordinator 问所有参与者『能不能提交？』，每个参与者写 prepare log + 锁住资源，返回 yes/no。
• Phase 2 (commit/abort)：全 yes → 全 commit；任一 no → 全 abort。

正确性保证 ACID 的 atomicity 跨节点。问题在于：

# 2PC 灾难场景 — 为什么 Pat Helland 称其为"Maginot Line"
# T = 0   coord -> all: PREPARE
# T = 10ms all -> coord: YES (各自锁住资源, 写 prepare log)
# T = 11ms coord 崩溃 ⚠
# T = ∞   participants 持锁等待 coord 重启
#         其他事务全部阻塞, 业务停摆
#
# 即使 coord 重启, 它必须先恢复 transaction log,
# 期间所有 participant 仍持锁. 这是分布式系统中
# 最糟糕的故障模式: "一个进程的死亡导致整个系统停摆".

2. Saga：把『一个大事务』拆成『N 个本地事务 + N-1 个补偿』

原理：1987 年 Garcia-Molina & Salem 在 SIGMOD 提出 Saga，原本是为『单库内长事务』设计（避免长时间锁）。微服务时代被借用解决跨服务事务：把跨服务事务拆成一串本地事务 T1…Tn；任一 Ti 失败，则按反向顺序执行已完成步骤的补偿事务 C(i-1)…C1。

不再保证 ACID 的隔离性，但保证最终一致 + 业务语义可撤销。两种落地模式：

sequenceDiagram
    participant C as Client
    participant O as Orchestrator (Temporal)
    participant Ord as Order Svc
    participant Inv as Inventory Svc
    participant Pay as Payment (Stripe)
    participant Pts as Points Svc

    C->>O: placeOrder()
    O->>Ord: 1 createOrder (PENDING)
    Ord-->>O: orderId=42
    O->>Inv: 2 reserveStock(sku, qty)
    Inv-->>O: reserved
    O->>Pay: 3 charge($100, idempKey=42)
    Pay-->>O: paid (charge_xyz)
    O->>Pts: 4 deductPoints(user, 50, idempKey=42)
    Pts--xO: 失败! 积分不足
    Note over O: Saga 反向补偿开始
    O->>Pay: C3 refund(charge_xyz, idempKey=42-refund)
    O->>Inv: C2 releaseStock(sku, qty, idempKey=42-rel)
    O->>Ord: C1 markFailed(42, reason="points")
    O-->>C: 失败: 积分不足, 已全部回滚

# Temporal Workflow 风格伪代码 (Python SDK)
@workflow.defn
class PlaceOrderSaga:
    @workflow.run
    async def run(self, req: OrderReq) -> Result:
        compensations = []          # 已成功步骤的补偿动作栈
        try:
            order = await activity.execute(create_order, req)
            compensations.append(lambda: mark_failed(order.id))

            await activity.execute(reserve_stock, req.sku, req.qty)
            compensations.append(lambda: release_stock(req.sku, req.qty))

            charge = await activity.execute(
                stripe_charge,
                amount=req.amount,
                idempotency_key=f"order-{order.id}"   # 关键: 幂等
            )
            compensations.append(
                lambda: stripe_refund(charge.id, key=f"refund-{order.id}")
            )

            await activity.execute(deduct_points, req.user, req.points,
                                   key=f"pts-{order.id}")
            return Result.ok(order.id)

        except ActivityError as e:
            # 反向执行补偿. Temporal 保证每个 activity at-least-once + retry.
            for comp in reversed(compensations):
                await activity.execute(comp, retry_policy=infinite_backoff)
            return Result.fail(reason=str(e))

# 关键性质:
#  - Temporal 把 workflow 状态持久化到 event log, 进程崩了也能 replay 接续.
#  - 每个 activity 必须 idempotent (因为可能重试).
#  - 补偿动作必须 idempotent 且不能再失败 (失败要人工介入).

3. Outbox Pattern：消灭『dual write』，把分布式事务降级为本地事务

问题：服务要『写 DB』+『发 Kafka 事件』。两个动作不在一个事务里，必有不一致窗口：

• DB 成功、Kafka 失败 → 下游永远收不到 → 数据丢失
• Kafka 成功、DB 失败（断电）→ 下游收到不存在订单的事件 → 幽灵订单

这就是 dual write problem，是微服务最常见的事务陷阱。

Outbox 解法：

1. 业务表和 outbox 表在同一个本地 DB 事务里一起写。本地事务 = ACID 保证，要么都成功要么都失败。
2. 独立的 relay 进程（Debezium 类 CDC，读 DB 的 WAL / binlog）异步把 outbox 表的新行发到 Kafka。
3. relay 自带 offset 追踪，at-least-once 投递；消费者用 outbox 行 ID 去重。

graph LR
    App["Order Service"]
    DB[("Postgres
orders + outbox
同一本地事务")]
    Debez["Debezium
读 WAL"]
    K["Kafka
order.events"]
    Cons1["Inventory Consumer"]
    Cons2["Analytics Consumer"]
    Cons3["Notification Consumer"]

    App -- "BEGIN
INSERT orders
INSERT outbox
COMMIT" --> DB
    DB -. WAL .-> Debez
    Debez --> K
    K --> Cons1
    K --> Cons2
    K --> Cons3

# Outbox 落地 — Postgres + Debezium
CREATE TABLE orders (id BIGSERIAL PK, user_id ..., amount ..., status ...);
CREATE TABLE outbox (
    id BIGSERIAL PK,
    aggregate_id BIGINT,        -- order id (做 partition key)
    event_type TEXT,            -- "order.created" / "order.cancelled"
    payload JSONB,
    created_at TIMESTAMPTZ DEFAULT now()
);

-- 业务代码: 写 orders 的同时往 outbox 写事件
BEGIN;
  INSERT INTO orders (...) VALUES (...) RETURNING id;
  INSERT INTO outbox (aggregate_id, event_type, payload)
       VALUES (42, 'order.created', '{"user":7,"amount":100}');
COMMIT;        -- 原子: 两表要么都成功要么都失败

-- Debezium 连接 Postgres replication slot,
-- 读 WAL → 监听 outbox 表的 INSERT → 转换 → 推 Kafka.
-- 关键: 业务代码不需要知道 Kafka 存在, 完全解耦.

# 为什么不直接读业务表的 CDC?
#  - 业务表 schema 变更频繁, 下游强耦合
#  - 一行业务变更可能对应 0 个或多个领域事件 (insert order 可能触发
#    "order.created" + "loyalty.points.eligible"). outbox 让产事件
#    粒度由业务代码控制.

# 为什么不直接 Kafka producer?
#  - Producer.send() 跟 DB COMMIT 不在一个事务里, dual write 问题
#  - 即使有 Kafka transactions, 也不能跨 Postgres + Kafka 两个系统.

4. Idempotency：分布式事务的『最后防线』

原理：分布式系统里所有 RPC、消息、回调都是 at-least-once——网络超时无法区分『请求丢了』还是『响应丢了』，重试是必然。幂等性保证『同一操作执行 N 次的效果等同于执行 1 次』，是 saga 重试、outbox 重投、补偿动作的安全网。

# Stripe 风格 idempotency key 服务端实现 (Postgres)
# 参考: https://stripe.com/blog/idempotency

CREATE TABLE idempotency (
    key TEXT PRIMARY KEY,
    request_hash TEXT NOT NULL,     -- 防 key 重用不同请求体
    response_code INT,
    response_body JSONB,
    status TEXT,                    -- 'in_progress' | 'completed'
    locked_at TIMESTAMPTZ,
    created_at TIMESTAMPTZ DEFAULT now()
);

def handle(key, req):
    h = hash(req.body)
    row = db.fetch_for_update("SELECT * FROM idempotency WHERE key=%s", key)

    if row and row.request_hash != h:
        raise Conflict("idempotency key reused with different body")

    if row and row.status == 'completed':
        return row.response_body                # 直接返回缓存

    if row and row.status == 'in_progress':
        if now() - row.locked_at > LEASE:
            pass                                # lease 过期, 可重试
        else:
            raise Conflict("request in flight")

    # 占位
    db.upsert("idempotency", key=key, request_hash=h,
              status='in_progress', locked_at=now())

    try:
        resp = do_business(req)
        db.update("idempotency", key=key,
                  status='completed', response_code=200,
                  response_body=resp)
        return resp
    except RetryableError:
        # 不更新, 让客户端重试
        raise
    except FatalError as e:
        db.update("idempotency", key=key,
                  status='completed', response_code=500,
                  response_body={"error": str(e)})
        raise

# 过期策略: Stripe 保留 24h, 之后清理. 客户端不应假设 key 永久存在.

扩展与优化

• Saga + 编排引擎是事实标准：超过 3 步的跨服务流程，不要手写状态机。直接上 Temporal / Cadence / AWS Step Functions / Azure Durable Functions，免费拿到持久化、重试、可视化、版本化。
• Outbox 的替代：CockroachDB / TiDB 的 changefeed 直接吐 Kafka，跳过 Debezium；MongoDB / DynamoDB 的 change streams 同理。如果新建项目，优先选自带 CDC 的数据库。
• Semantic Locking：saga 期间数据可能被其他事务看到（违反隔离性）。Chris Richardson 提出 semantic lock（在数据上加业务级 'pending' 标记），其他事务看到 pending 状态自行决定如何处理（拒绝 / 等待 / 强制覆盖）。
• Inbox 模式（outbox 对偶）：消费者也维护 inbox 表记录已处理的 event_id，写业务表 + 写 inbox 同事务。这就把消费端去重也变成本地事务问题。
• 事务 ID 透传与追踪：saga 跨服务时把 saga_id / step_id 作为 trace 头透传，结合 OpenTelemetry 形成完整链路；出问题能秒级定位卡在哪一步。
• 避免分布式事务的根本武器：领域边界。如果你发现 90% 的业务流程都跨同两个服务，它们大概率应该合并成一个服务。微服务边界画错才会逼你做分布式事务。

常见陷阱与面试问题

面试可能追问：

1. 详述 2PC 阻塞场景：coordinator 在 phase 1 ACK 后挂掉，participants 怎么办？3PC 怎么改进、为什么仍不流行？
2. Saga 与 ACID 事务在隔离性上的区别？给一个 Saga 看到中间态导致的业务 bug 例子。
3. Outbox vs 直接 Kafka transactions 区别？为什么生产更多选 Outbox？
4. 设计一个『跨服务转账』：服务 A 扣 100、服务 B 加 100。给 saga 补偿流程 + 失败模式分析。
5. Idempotency key 的过期策略？过期后客户端再用同一 key 重试会发生什么？怎么避免重复扣款？
6. 『微服务要不要避免分布式事务』——你如何回答？给一个『把分布式事务转化为领域重新划分』的例子。

深入资源

• 《Designing Data-Intensive Applications》Ch 7 §Transactions + Ch 9 §Atomic Commit and Two-Phase Commit（Kleppmann）：2PC、分布式事务局限的最完整工业级讨论。
• Pat Helland — Life Beyond Distributed Transactions: An Apostate's Opinion (ACM Queue 2017 / CIDR 2007)：业内共识级文章，论证『大规模系统不能依赖分布式事务』，奠定 saga / messaging / entity 思想基础。
• Garcia-Molina & Salem — Sagas (SIGMOD 1987)：saga 概念的原始论文，14 页读完，理解动机比直接看现代框架更深。
• Chris Richardson — microservices.io: Saga Pattern + 《Microservices Patterns》（Manning）：含 orchestration / choreography 对比、semantic lock、版本化 saga 等工业经验。
• Debezium — Reliable Microservices Data Exchange With the Outbox Pattern (2019)：outbox + CDC 落地范本。
• Stripe — Designing robust and predictable APIs with idempotency (2017) + Brandur Leach: Idempotency keys in Postgres：工程级最佳参考。
• Uber Cadence — Announcing Cadence 1.0 (2024)；DoorDash — Building Reliable Workflows with Cadence (2024)：saga orchestration 在 hyperscale 公司的真实使用。
• Temporal — The definitive guide to Durable Execution：现代『saga + 持久化 workflow』平台的理论与实践。

深入思考