Eventual Consistency
最終一致性
最終一致性允許資料變更後，各份副本短暫不同。如果沒有新變更，而且更新流程持續正常運作，副本應該變得一致。
source commit -> event/change -> consumer lag -> projection update -> measured convergencesource commit -> event/change -> consumer lag -> projection update -> measured convergenceJOB另一個例子
商品目錄把產品 `42` 改名為「海洋」。產品頁會立即讀到新名稱。事件消費者追上前，搜尋副本仍會顯示舊名稱三秒。兩邊一致後，延遲指標會回到零。
主要部分
- 01原始資料來源
- 02資料變更事件
- 03非同步通道
- 04消費者檢查點
- 05短暫不同步時間與延遲
- 06收斂或修復
什麼時候用
搜尋副本、分析資料或獨立服務能安全接受一段延遲時，可以採用最終一致性。要量測這段延遲，也要讓人能修復或重新傳送漏掉的變更。
什麼時候不要用
某項決定需要立即取得最新值時，不要採用最終一致性。敏感操作前的權限檢查就是一個例子。要說清楚副本何時應該一致，以及失敗後要怎麼處理。
程式裡的名稱
source commit -> event/change -> consumer lag -> projection update -> measured convergence 上線前要檢查
檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。
預期成果：為這套系統設計或檢查 最終一致性 (Eventual Consistency)，並讓資料保持正確、安全且容易維護。 使用者情境：商品目錄把產品 `42` 改名為「海洋」。產品頁會立即讀到新名稱。事件消費者追上前，搜尋副本仍會顯示舊名稱三秒。兩邊一致後，延遲指標會回到零。 技術概念或控制措施：最終一致性 (Eventual Consistency)。 適用理由：搜尋副本、分析資料或獨立服務能安全接受一段延遲時，可以採用最終一致性。要量測這段延遲，也要讓人能修復或重新傳送漏掉的變更。 不應使用的情況：某項決定需要立即取得最新值時，不要採用最終一致性。敏感操作前的權限檢查就是一個例子。要說清楚副本何時應該一致，以及失敗後要怎麼處理。 工程要求：定義輸入、輸出、介面約定，以及任何情況都不能破壞的規則。說明授權與輸入檢查範圍。定義失敗、逾時、重試和重複執行只生效一次的規則。也要定義資料搬移與相容限制。 營運要求：加入監控訊號與隱藏敏感資料的記錄。設定容量上限並寫好操作手冊。測試復原與回復上一版的流程。 驗收條件：介面約定與失敗路徑測試通過。重試或部分失敗時，資料與授權規則仍正確。效能上限、監控、復原與回復上一版的方法都已驗證。 證據與限制（證據邊界）：沒有一份官方標準能管到全部內容。不同團隊、平台或框架的用法可能不同。 待確認：程式執行環境、資料位置、流量形態、資料一致需求和安全邊界。也要確認相容期間、服務目標（SLO）與回復上一版的限制。
檢查這份需求
請 AI 程式助手檢查目前如何使用 最終一致性 (Eventual Consistency)。 定義：最終一致性允許資料變更後，各份副本短暫不同。如果沒有新變更，而且更新流程持續正常運作，副本應該變得一致。 正式環境檢查：檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。 修改程式前，先列出看到的證據、缺口、嚴重程度，以及最小且安全的修正。