34 lines
1.7 KiB
Markdown
34 lines
1.7 KiB
Markdown
# 一致性與交易設計 (Consistency Transaction Design) 知識合約指南
|
||
|
||
## 概述
|
||
`consistency-transaction-design` 是知識合約，用來提供一致性与交易設計的原則與模式。涵蓋 Strong vs Eventual Consistency、Idempotency、Deduplication、Retry、Outbox Pattern、Saga 與 Compensation。供 `design-architecture` 在定義一致性模型時參考。此合約取代了原有的 `idempotency-design`。
|
||
|
||
## 核心原則
|
||
### CAP Theorem
|
||
- Consistency：每次讀取都獲得最新寫入或錯誤
|
||
- Availability：每個請求都獲得回應（不保證是最新寫入）
|
||
- Partition tolerance：網路分割時系統仍可運作
|
||
- 三者無法同時滿足，根據業務需求選擇。
|
||
|
||
### 一致性光譜
|
||
- **Strong Consistency**：讀取永遠返回最新寫入
|
||
- **Eventual Consistency**：讀取可能返回過時資料，最終收斂
|
||
- **Session Consistency**：同一 session 內讀取看到自己的寫入
|
||
- **Causal Consistency**：讀取遵守因果順序
|
||
|
||
## 設計重點
|
||
- **一致性模型選擇**：按資料域選擇，而非按系統選擇
|
||
- **Idempotency 設計**：何時需要、Key 策略、TTL、儲存位置
|
||
- **Deduplication**：Idempotency key、Content hash、Sequence number
|
||
- **Retry**：Fixed interval、Exponential backoff、Circuit breaker
|
||
- **Outbox Pattern**：確保可靠事件發布
|
||
- **Saga Pattern**：跨服務分散式交易的補償機制（Choreography vs Orchestration）
|
||
|
||
## 知識合約職責
|
||
- 提供一致性與交易設計的理論指引
|
||
- 不直接產生一致性模型規格（由 `design-architecture` 的 Consistency Model 章節負責）
|
||
|
||
## 不應做的事
|
||
- 不替系統選擇特定一致性策略
|
||
- 不定義具體的 Idempotency key 格式或 TTL
|
||
- 不產生實作程式碼 |