Uber 是如何解決數據一致性問題的呢？

Uber 的請求流程非常複雜，如上圖所示，他們使用 Spanner 來存儲大量數據。Spanner 是一個全面託管的、關鍵的關係型數據庫服務，可以在全球範圍內提供事務一致性和高可用性的自動同步複製。

但是，當擴展到數百萬併發請求時，使用 Cassandra 很難保證低延遲的寫入。另一個問題是工程團隊開始注意到複雜的存儲交互，這些交互需要進行多行和多表的寫入操作（具體意義不明）。但無論如何，本地 Cassandra 數據庫變得非常具有挑戰性。

對於 Uber 來說，數據不一致可能導致兩個司機接同一個乘客。

解決方案是構建一個應用層框架，使用 Saga 模式來協調數據庫操作。

Saga 設計模式

Saga 設計模式是一種用於在分佈式事務場景下管理微服務間數據一致性的方式。Saga 是一系列事務，每個事務更新每個服務併發布消息或事件以觸發下一個事務步驟。如果某個步驟失敗，Saga 將執行一系列補償事務來撤銷之前事務所做的更改。

簡單來說，如果在事務期間出現問題（事務是邏輯或工作的單個單元，有時由多個操作組成），則應撤銷之前的更改。

事務是什麼？

事務是一個邏輯或工作的單個單元，有時由多個操作組成。在事務內部，事件是對實體狀態的更改，命令封裝了執行操作或觸發後續事件所需的所有信息。

事務必須具備原子性、一致性、隔離性和持久性（ACID）。單個服務內的事務是 ACID 的，但跨服務的數據一致性需要跨服務事務管理策略。

在多服務架構中：

• 原子性：事務是不可分割的操作集合，要麼全部執行，要麼全部不執行。• 一致性：事務將數據從一個有效狀態轉換爲另一個有效狀態。• 隔離性：保證併發事務產生的數據狀態與按順序執行的事務產生的數據狀態相同。• 持久性：確保已提交的事務即使在系統故障或斷電的情況下仍然保持提交狀態。

解決方案

Saga 模式通過一系列本地事務提供事務管理。本地事務是 Saga 中參與者執行的原子工作任務。每個本地事務都會更新數據庫併發布消息或事件以觸發 Saga 中的下一個本地事務。如果本地事務失敗，Saga 將執行一系列補償事務來撤銷之前的本地事務所做的更改。

有兩種常見的 Saga 實現方法：協作和編排。每種方法都有一套用於協調工作流的挑戰和技術。

協作是一種無需集中控制點的 Saga 協調方式。在協作中，每個本地事務都會發布領域事件，從而觸發其他服務中的本地事務。

編排是一種通過集中式控制器協調 Saga 的方式。編排器告知 Saga 參與者要執行的本地事務。編排器處理所有事務，告知參與者根據事件執行哪些操作。編排器執行 Saga 請求，存儲和解釋每個任務的狀態，並使用補償事務進行故障恢復。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/54vAwtbSVDQ6MA8yfpi7Eg