ACID Is So Yesterday: Maintaining Data Consistency with Sagas

Chris Richardson

Founder of Eventuate.io
Founder of the original CloudFoundry.com Author of POJOs in Action

本文素材作者  Chris Richardson，由坐館老G先生注解

講義goal：

分布式數(shù)據(jù)管理在微服務(wù)架構(gòu)下的挑戰(zhàn)

Sagas 是一種事務(wù)模型

關(guān)于作者Chris

大大有名

POJO's in action

Microservice Patterns

微服務(wù)enable 持續(xù)部署

架構(gòu),、組織和過(guò)程三角

架構(gòu)：微服務(wù)架構(gòu)

組織：小,、敏捷、自組織功能團(tuán)隊(duì)

過(guò)程：持續(xù)交付/部署

services = testability  and deployability

松耦合,，數(shù)據(jù)封裝

如何維護(hù)數(shù)據(jù)一致性呢,？

由于不在一個(gè)（本地）事務(wù)中......

2PC 不是一個(gè)好的選擇

//

1,、2PC事務(wù)協(xié)調(diào)器單點(diǎn)故障問(wèn)題

2,、通訊：至少有O（4n）條消息，并重試O（n^2）

3,、鎖導(dǎo)致吞吐量降低

4,、許多NoSQL數(shù)據(jù)庫(kù)（或消息代理）不支持

5,、CAP理論 ? 2PC影響可用性

Ebay的Dan Pritchett 提出：

In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability.

并有一個(gè)著名的Base理論,。

Base: An Acid Alternative

Basically Available 

Soft state

Eventually consistent

sagas 可以追溯到1987年的論文

1987年普林斯頓大學(xué)的Hector Garcia-Molina和Kenneth Salem發(fā)表了一篇Paper Sagas，講述的是如何處理long lived transaction（長(zhǎng)活事務(wù)）,。Saga是一個(gè)長(zhǎng)活事務(wù)可被分解成可以交錯(cuò)運(yùn)行的子事務(wù)集合,。其中每個(gè)子事務(wù)都是一個(gè)保持?jǐn)?shù)據(jù)庫(kù)一致性的真實(shí)事務(wù)。

Saga的組成

• 每個(gè)Saga由一系列sub-transaction T_i 組成

• 每個(gè)T_i 都有對(duì)應(yīng)的補(bǔ)償動(dòng)作C_i,，補(bǔ)償動(dòng)作用于撤銷T_i造成的結(jié)果

可以看到,，和TCC相比，Saga沒(méi)有“預(yù)留”動(dòng)作,，它的T_i就是直接提交到庫(kù),。

Saga的執(zhí)行順序有兩種：

• T₁, T₂, T₃, ..., T_n

• T₁, T₂, ..., T_j, C_j,..., C₂, C₁，其中0 < j < n

Saga定義了兩種恢復(fù)策略：

• backward recovery,，向后恢復(fù),，補(bǔ)償所有已完成的事務(wù)，如果任一子事務(wù)失敗,。即上面提到的第二種執(zhí)行順序,，其中j是發(fā)生錯(cuò)誤的sub-transaction，這種做法的效果是撤銷掉之前所有成功的sub-transation,，使得整個(gè)Saga的執(zhí)行結(jié)果撤銷,。

• forward recovery，向前恢復(fù),，重試失敗的事務(wù),，假設(shè)每個(gè)子事務(wù)最終都會(huì)成功。適用于必須要成功的場(chǎng)景,，執(zhí)行順序是類似于這樣的：T₁, T₂, ..., T_j(失敗), T_j(重試),..., T_n,，其中j是發(fā)生錯(cuò)誤的sub-transaction。該情況下不需要C_i,。

Sagas complicate API design （Sagas 使 API 設(shè)計(jì) 復(fù)雜化 ）

Synchronous API vs Asynchronous Saga
Request initiates the saga. When to send back the response? 

Option #1: Send response when saga completes:

+ Response specifies the outcome - Reduced availability

選擇一：saga完成的時(shí)候發(fā)送響應(yīng)

Option #2: Send response immediately after creating the saga

(recommended)

選擇二：創(chuàng)建saga之后馬上發(fā)送響應(yīng)（推薦）

+ Improved availability（提高可用性）

- Response does not specify the outcome. Client must poll or be notified

（響應(yīng)沒(méi)有指定結(jié)果,。必須輪詢或通知Client端）

使用Sagas，可能影響用戶體驗(yàn),。

UI界面向用戶隱藏異步API

如果需要更長(zhǎng)的時(shí)間,， 用戶界面顯示“處理中”彈出窗口

服務(wù)器可以將通知推送到UI

Sagas 擁有 ACD 特性

原子性、一致性,、持久性

缺失隔離性

Commutative updates

e.g. debit account can compensate for a credit account

Version file （版本文件）

Record history of changes （記錄變化歷史）

Use them to make updates commutative

e.g. record cancel reservation（記錄 取消 預(yù)定） so that create/cancel = cancel/ create

Sounds suspiciously like event sourcing

Choreography （編排）: distributed decision making vs.

Orchestration（協(xié)調(diào)）: centralized decision making

方案1:使用事件做基于編排模式的協(xié)作

優(yōu)缺點(diǎn)：

Benefits （好處）

簡(jiǎn)單,，尤其使用事件溯源時(shí)

參與者松耦合

Drawbacks （缺點(diǎn)）

循環(huán)依賴

領(lǐng)域?qū)ο筮^(guò)載，例如訂單和客戶相互知道太多

Events = ndirect way to make something happen to make something happen

選項(xiàng)2：基于編排的saga協(xié)調(diào)

saga（orchestrator ） 是一個(gè)持久性對(duì)象,，跟蹤saga的狀態(tài),，以及調(diào)用參與者

這里有一個(gè)例子，開源的saga 框架

 優(yōu)缺點(diǎn)

Benefits

Centralized coordination logic is easier to understand

Reduced coupling, e.g. Customer knows less

Reduces cyclic dependencies

Drawbacks

Risk of smart sagas directing dumb services

消息必須支持事務(wù)

選擇1:使用數(shù)據(jù)庫(kù)表作為消息隊(duì)列,，ebay的案例

選擇2: 使用事件溯源：以事件為中心的持久化