Percolator 中的分布式事務

2021-06-26 14:28:44 字數 3339 閱讀 6396

percolator 對外提供兩個主要的功能, 乙個是分布式事務, 另外乙個是 observers, 這裡簡單介紹一下 percolator 中分布式事務的實現方法. 以下內容都出自對 google ** large-scale incremental processing using distributed transactions and notifications 的學習. 這裡介紹的內容只是**中的乙個小部分, 涉及實現分布式事務的核心思想, 目的是幫助大家理解原文.

在乙個分布式系統中, 實現對事務的支援是一件蠻有挑戰的事情. 分布式系統的巨大併發量,  高錯誤容忍性, 物理上的分散, 都為事務的實現埋下重重障礙.  percolator 實現在 bigtable 的基石上, 充分利用了 bigtable 的特性, 巧妙的實現了對事務的支援.  

在實現分布式事務的時候, percolator 使用了兩個基本的服務, 乙個提供精確時間用來產生timestamp, 另外乙個提供一種簡單的分布式鎖, 用來檢查乙個程序是否還活著. 這兩個服務這裡不做介紹了.  我們集中精力來看 percolator 是如何充分利用 bigtable 的單行原子性以及多版本這兩個特性來實現自己的分布式事務的. 簡單來說, 就是把多列, 多表的事務的提交和回滾變成乙個個單行事務. 我們看**中的具體例子.

這個例子是從bob的賬戶中轉7美金到joe的賬戶. 這是乙個涉及到兩個 row 的事務.

下面的表示中, 冒號前面的部分是乙個版本號, 可以通過時間服務來解決其取值問題, lock 這個列用來放鎖的情況. write 這個列放最終的資料寫入情況.

下面的敘述中請大家注意, 單行的操作是有原子性的( bigtable 的保證).

key     bal:data            bal:lock             bal:write

bob     6:                  6:                   6: data @ 5

5: $10              5:                   5:

joe     6:                  6:                   6: data @ 5

5: $2               5:                   5:

1 這個是初始狀態, bob 賬戶有10美金, joe 有2個美金.   write 列中的 6:data @ 5 表示 當前的資料是 version 為 5 的(感謝 bigtable 的多版本支援)

bob     7:$3                7: i am primary      7:

6:                  6:                   6: data @ 5

5: $10              5:                   5:

joe     6:                  6:                   6: data @ 5

5: $2               5:                   5:

2 事務的第乙個階段, bob的賬戶變成3美金了. 注意 lock 列被加鎖, 並且標明自己是 primary. 沒個事務中, 只有乙個primary, 也正是這個primary的存在, 使得我們能夠用行原子性來實現分布式事務.

bob     7: $3               7: i am primary      7:

6:                  6:                   6: data @ 5

5: $10              5:                   5:

joe     7: $9               7: [email protected]   7:

6:                  6:                   6: data @ 5

5: $2               5:                   5:

3 現在給joe加上7美金, 所以joe是10美元了, 注意 joe 這一行的 lock 是指向 primary 的乙個指標.

bob     8:                  8:                   8: data@7

7: $3               7:                   7:

6:                  6:                   6: data @ 5

5: $10              5:                   5:

joe     7: $9               7: primary @ bob.bal 7:

6:                  6:                   6:data @ 5

5: $2               5:                   5:

4 事務提交的第一階段, 提交 primary, 移除lock 列的內容 在 write 列寫入最新資料的 version 

bob     8:                  8:                   8: data @ 7

7: $3               7:                   7:

6:                  6:                   6: data @ 5

5: $10              5:                   5:

joe     8:                  8:                   8: data@7

7: $9               7:                   7:

6:                  6:                   6: data @ 5

5:$2                5:                   5:

5 事務提交的第二階段, 提交除 primary 之外其它部分. 提交的方式也是移除 lock, 同時在 write 列寫入新資料的 version

從這個講述我們看到是怎麼把兩行的事務用單行原子性搞定的了. 事務是否提交完全取決於 primary. 如果 primary 提交了, 則lock列被清空, write列標識了正確的版本號. 反之就是未提交. 這種方式可以用來處理多列, 多表, 的事務, 而且可以併發執行的事務數量幾乎是無限的. 因為沒有任何全域性鎖.

這個分布式協議下, 如果出現了乙個執行緒執行了事務的一部分crash掉, 或者出現衝突時如何解決, 大家可以自己推演一下或者去讀原**, 這裡不再詳述.

0

給主人留下些什麼吧!~~

Percolator與分布式事務思考(三)

percolator的事務實現依賴乙個全域性的時間戳服務來生成嚴格遞增的時間戳,因為每個事務需要連線時間戳服務2次,這個服務必需能夠很好的擴充套件.這個預報服務通過寫乙個最高可分配的時間戳到持久儲存中週期性的分派乙個範圍的時間戳段 給乙個已分配時間戳段,那麼預報服務能夠在記憶體中嚴格按增量給請求分配...

分布式系統中的分布式事務

分布式事務中可以借助mq訊息系統來進行事務控制,這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中,扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案,它本質上就是通過定期校對,實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣,怎麼保證兩個伺服器的...

分布式 分布式鎖

本質是利用redis的setnx 方法的特性來加鎖,setnx 即key不存在則設定key,否則直接返回false,要求在分布式系統中使用同乙個redis服務,以下提供兩種解決方案 1 直接使用redistemplate 這其實並不能完全保證高併發下的安全問題,因為可能在鎖過期之後該執行緒尚未執行完...