为什么最终一致性优于分布式事务 (Why Eventual Consistency Beats Distributed Transactions)

在这八章中，我们从提供者抽象开始，然后进展到语义事件、错误分类、重试算法、租赁、协调和孤儿费用优化。现在可以清楚地提出所有这些问题背后的共同问题：为什么我们要忍受所有这些复杂性？为什么我们不将 PSP、订单和财务记录合并到单个交易中并立即解决所有这些问题？

答案很简单，也是最终的：PSP 永远无法参与您的交易。```text 2PC'nin gerektirdiği Coordinator ←→ Participant 1 (Order DB) Coordinator ←→ Participant 2 (Finance DB) Coordinator ←→ Participant 3 (PSP??)

Gerçek dünyada PSP Kendi transaction protokolünü çalıştırmaz Kendi ağ sınırında, kendi tutarlılık modeliyle yaşar Sizin 'prepare' veya 'commit' sinyalinizi anlamaz

## 第一次提到的概念```text
📦 Two-Phase Commit (2PC)
Birden fazla katılımcının bir işlemi ya tamamen kabul (commit) ya da tamamen reddetmesini (rollback) sağlayan protokol.

📦 Saga
Tek bir ACID transaction'a sığmayan bir iş akışını, her adımın kendi telafi (compensation) adımına sahip olduğu bir dizi yerel işleme bölen desen.

📦 Eventual Consistency
Sistemin her an tutarlı olmayabileceğini, ama belirli bir süre içinde tutarlı bir duruma yakınsayacağını kabul eden model.

📦 Reconciliation olarak backstop
Saga'nın telafi adımları başarısız olduğunda veya atlandığında, sistemi gerçek duruma geri getiren son güvenlik ağı.
```2PC 要求所有参与者具有相同的协调器、相同的协议和相同的网络可靠性假设。 PSP 不接受任何这些假设——它是一个不受您控制的系统，运行在它自己的 SLA、它自己的 API 和它自己的错误模型上。

## 为什么PSP无法加入2PC

即使您想向 PSP 发送“准备”请求，然后发送“提交”或“回滚”，PSP 也不支持这种两阶段协议 - 因为卡本身、银行网络和欺诈检查已经做出自己的（大多是单阶段）决定。 PSP 的 API 不会告诉你“等等，我稍后再决定”；它说“它发生了”或“它没有发生”。如果您的系统上的第二阶段（提交）失败，则不存在 PSP 回滚事务的概念；然而，有一个单独的退款请求——它本身是一个异步、无保证的操作。```text
2PC'nin varsaydığı dünya
  Prepare → tüm katılımcılar 'hazırım' der → Commit → hepsi aynı anda kabul eder

PSP'nin gerçek dünyası
  Charge isteği → PSP kendi kararını anında verir → sonuç kesindir
  Geri almak istersen → ayrı bir Refund isteği, ayrı bir asenkron süreç
```## Saga：本地决策链

取代 2PC 的方法是每个系统执行自己的本地事务，并且仅在事件发生时才进行下一步。如果某个步骤失败，之前的步骤不会撤消；每一个都通过自己的补偿行为来纠正。```text
Charge PSP'de başarılı
  → sipariş oluştur (yerel transaction)
  → finans kaydı oluştur (yerel transaction)

Finans kaydı başarısız olursa
  → sipariş için telafi: siparişi iptal et
  → PSP için telafi: refund isteği gönder
```这是我们在本系列前面看到的“捕获容易，最终确定很难”真理的直接结果：最终确定的困难正是设计传奇补偿步骤的困难。

## 契约：传奇的安全网

Saga 不保证补偿步骤始终有效——补偿请求也可能失败，网络可能瘫痪，worker 可能崩溃。因此，我们在前几章中建立的所有内容（租赁、共识工作人员、孤儿费用改进）都是第二层，它消除了仅 saga 不够的时刻。```text
Saga (birincil yol)
  → adım adım ilerler, her adım kendi telafisine sahiptir

Reconciliation (ikincil güvenlik ağı)
  → saga'nın atladığı veya başarısız olduğu durumları periyodik olarak tarar ve düzeltir
```## 事件一致性的真正成本：窗口，而不是一致性

最终一致性并不意味着“数据在某些时候可能不准确”；它的意思是“数据在一段时间内可能不完整或过时，但这个时期是可测量和有限的”。这个窗口需要在产品端可见：客户付款后需要多少秒/分钟才能出现订单状态？这是一个产品决策，而不是技术细节，也是我们从本系列开始以来一直倡导的精髓：分布式支付系统中完美的瞬时一致性是一种幻想；真正的目标是一个短暂的、可衡量的、可观察的差异窗口。

|方法|保修|真的可以吗 |
| --- | --- | --- |
| 2PC（包括 PSP）|即时、完全一致性 |不——PSP 不能参加 |
|传奇+补偿|一步步进步，追溯修正 |是的 |
|传奇+和解|适度、有限的不一致窗口 |是的——本系列推荐的型号|

## 经常混淆的区别```text
❌ Eventual consistency = tutarsız sistem
✓ Eventual consistency = ölçülü, sınırlı bir pencere içinde tutarlılığa yakınsama

❌ Saga, 2PC'nin daha basit bir versiyonudur
✓ Saga farklı bir modeldir: geri alma yoktur, telafi vardır

❌ Mutabakat, saga'nın tasarım hatasını gösterir
✓ Mutabakat, dağıtık sistemin doğasında olan kalıcı bir güvenlik ağıdır, saga'nın eksikliği değil
```## 2PC 与 Saga+Reconciliation 的比较

|标准| 2件 |传奇+和解|
| --- | --- | --- |
| PSP 参与 |必要但不可能|不需要|
|锁定时间|贯穿所有参与者|无 |
|部分容错 |低|高|
|运营复杂性 |理论上低，实践上不可能|高而真实|

## 评估此模型时的清单

1. 系统中的每个外部依赖项（包括PSP）是否可以参与相同的事务协议？如果无法参加 2PC 则不可行。
2. 每个 saga 步骤是否都有明确定义的补偿操作？
3. 当补救措施失败时会发生什么——它会悄无声息地消失还是被共识所捕获？
4. 是否测量最终一致性窗口并与产品团队共享？
5. 系统的目标是否是“短时间内一致”的现实，而不是“始终一致”的幻想？

## 这八章中你应该记住什么

1. PSP是一个外部系统，永远不能参与你的交易协议；这就是为什么 2PC 是一个陷阱。
2. Saga 是一个现实的替代方案，其中每个步骤都执行自己的本地事务和自己的补偿操作。
3、共识不是saga的缺点，而是分布式系统固有的永久安全网。
4、最终一致，而不是不一致；它是一个可测量的、可观察的收敛窗口。

> 分布式支付系统追求的不是完美的瞬时一致性；我们所寻求的是准确地知道这种差异将持续多久。

这是从提供者抽象开始的八部分路径的结论：防止 SDK 泄漏、生成语义事件、正确分类错误、严格重试、通过租约安全地拥有工作、通过共识捕捉偏差、通过证明解决孤儿费用——所有这些都服务于同一个真理：分布式支付系统的目标不是完美，而是可控和可观察的不一致。