銀行跨行轉賬業務是一個典型分散式事務場景,假設A需要跨行轉賬給B,那麼就涉及兩個銀行的資料,無法通過一個資料庫的本地事務保證轉賬的ACID,只能夠通過分散式事務來解決。
分散式事務
分散式事務在分散式環境下,為了滿足可用性、效能與降級服務的需要,降低一致性與隔離性的要求,一方面遵循 BASE 理論:
- 基本業務可用性(Basic Availability)
- 柔性狀態(Soft state)
- 最終一致性(Eventual consistency)
另一方面,分散式事務也部分遵循 ACID 規範:
- 原子性:嚴格遵循
- 一致性:事務完成後的一致性嚴格遵循;事務中的一致性可適當放寬
- 隔離性:並行事務間不可影響;事務中間結果可見性允許安全放寬
- 永續性:嚴格遵循
SAGA
Saga是這一篇資料庫論文SAGAS提到的一個分散式事務方案。其核心思想是將長事務拆分為多個本地短事務,由Saga事務協調器協調,如果各個本地事務成功完成那就正常完成,如果某個步驟失敗,則根據相反順序一次呼叫補償操作。
目前可用於SAGA的開源框架,主要為Java語言,其中以seata為代表。我們的例子採用go語言,使用的分散式事務框架為github.com/yedf/dtm,它對分散式事務的支援非常優雅。下面來詳細講解SAGA的組成:
DTM事務框架裡,有3個角色,與經典的XA分散式事務一樣:
- AP/應用程式,發起全域性事務,定義全域性事務包含哪些事務分支
- RM/資源管理器,負責分支事務各項資源的管理
- TM/事務管理器,負責協調全域性事務的正確執行,包括SAGA正向/逆向操作的執行
下面看一個成功完成的SAGA時序圖,就很容易理解SAGA分散式事務:
SAGA實踐
對於我們要進行的銀行轉賬的例子,我們將在正向操作中,進行轉入轉出,在補償操作中,做相反的調整。
首先我們建立賬戶餘額表:
CREATE TABLE dtm_busi.`user_account` (
`id` int(11) AUTO_INCREMENT PRIMARY KEY,
`user_id` int(11) not NULL UNIQUE ,
`balance` decimal(10,2) NOT NULL DEFAULT '0.00',
`create_time` datetime DEFAULT now(),
`update_time` datetime DEFAULT now()
);
我們先編寫核心業務程式碼,調整使用者的賬戶餘額
def saga_adjust_balance(cursor, uid, amount):
affected = utils.sqlexec(cursor, "update dtm_busi.user_account set balance=balance+%d where user_id=%d and balance >= -%d" %(amount, uid, amount))
if affected == 0:
raise Exception("update error, balance not enough")
下面我們來編寫具體的正向操作/補償操作的處理函式
@app.post("/api/TransOutSaga")
def trans_out_saga():
saga_adjust_balance(c, out_uid, -30)
return {"dtm_result": "SUCCESS"}
@app.post("/api/TransOutCompensate")
def trans_out_compensate():
saga_adjust_balance(c, out_uid, 30)
return {"dtm_result": "SUCCESS"}
@app.post("/api/TransInSaga")
def trans_in_saga():
saga_adjust_balance(c, in_uid, 30)
return {"dtm_result": "SUCCESS"}
@app.post("/api/TransInCompensate")
def trans_in_compensate():
saga_adjust_balance(c, in_uid, -30)
return {"dtm_result": "SUCCESS"}
到此各個子事務的處理函式已經OK了,然後是開啟SAGA事務,進行分支呼叫
# 這是dtm服務地址
dtm = "http://localhost:8080/api/dtmsvr"
# 這是業務微服務地址
svc = "http://localhost:5000/api"
req = {"amount": 30}
s = saga.Saga(dtm, utils.gen_gid(dtm))
s.add(req, svc + "/TransOutSaga", svc + "/TransOutCompensate")
s.add(req, svc + "/TransInSaga", svc + "/TransInCompensate")
s.submit()
至此,一個完整的SAGA分散式事務編寫完成。
如果您想要完整執行一個成功的示例,那麼參考這個例子yedf/dtmcli-py-sample,將它執行起來非常簡單
# 部署啟動dtm
# 需要docker版本18以上
git clone https://github.com/yedf/dtm
cd dtm
docker-compose up
# 另起一個命令列
git clone https://github.com/yedf/dtmcli-py-sample
cd dtmcli-py-sample
pip3 install flask dtmcli requests
flask run
# 另起一個命令列
curl localhost:5000/api/fireSaga
處理網路異常
假設提交給dtm的事務中,呼叫轉入操作時,出現短暫的故障怎麼辦?按照SAGA事務的協議,dtm會重試未完成的操作,這時我們要如何處理?故障有可能是轉入操作完成後出網路故障,也有可能是轉入操作完成中出現機器當機。如何處理才能夠保障賬戶餘額的調整是正確無問題的?
這類網路異常的妥當處理,是分散式事務中的大難題,異常情況包括三類:重複請求、空補償、懸掛,都需要正確處理
DTM提供了子事務屏障功能,保證上述異常情況下的業務邏輯,只會有一次正確順序下的成功提交。(子事務屏障詳情參考分散式事務最經典的七種解決方案的子事務屏障環節)
我們把處理函式調整為:
@app.post("/api/TransOutSaga")
def trans_out_saga():
with barrier.AutoCursor(conn_new()) as cursor:
def busi_callback(c):
saga_adjust_balance(c, out_uid, -30)
barrier_from_req(request).call(cursor, busi_callback)
return {"dtm_result": "SUCCESS"}
這裡的barrier_from_req(request).call(cursor, busi_callback)呼叫會使用子事務屏障技術,保證busi_callback回撥函式僅被提交一次
您可以嘗試多次呼叫這個TransIn服務,僅有一次餘額調整。
處理回滾
假如銀行將金額準備轉入使用者2時,發現使用者2的賬戶異常,返回失敗,會怎麼樣?我們調整處理函式,讓轉入操作返回失敗
@app.post("/api/TransInSaga")
def trans_in_saga():
return {"dtm_result": "FAILURE"}
我們給出事務失敗互動的時序圖
這裡有一點,TransIn的正向操作什麼都沒有做,就返回了失敗,此時呼叫TransIn的補償操作,會不會導致反向調整出錯了呢?
不用擔心,前面的子事務屏障技術,能夠保證TransIn的錯誤如果發生在提交之前,則補償為空操作;TransIn的錯誤如果發生在提交之後,則補償操作會將資料提交一次。
您可以將返回錯誤的TransIn改成:
@app.post("/api/TransInSaga")
def trans_in_saga():
with barrier.AutoCursor(conn_new()) as cursor:
def busi_callback(c):
saga_adjust_balance(c, in_uid, 30)
barrier_from_req(request).call(cursor, busi_callback)
return {"dtm_result": "FAILURE"}
最後的結果餘額依舊會是對的,原理可以參考:分散式事務最經典的七種解決方案的子事務屏障環節
小結
在這篇文章裡,我們介紹了SAGA的理論知識,也通過一個例子,完整給出了編寫一個SAGA事務的過程,涵蓋了正常成功完成,異常情況,以及成功回滾的情況。相信讀者通過這邊文章,對SAGA已經有了深入的理解。
文中使用的dtm是新開源的Golang分散式事務管理框架,功能強大,支援TCC、SAGA、XA、事務訊息等事務模式,支援Go、python、PHP、node、csharp等語言的。同時提供了非常簡單易用的介面。
閱讀完這篇乾貨,歡迎大家訪問專案github.com/yedf/dtm,給顆星星支援!
本作品採用《CC 協議》,轉載必須註明作者和本文連結