2PC的時代即將結束,但是圍繞2PC仍存在許多誤解,2PC只是提供原子性而不是事務 · Exactly Once
如果有分散式事務協議,那麼每個軟體工程師都知道它:“兩階段提交”,也稱為2PC。儘管使用了幾十年,但是由於缺乏雲環境的支援,它卻一直在穩步下降。
過去在相當長的一段時間裡,它是構建企業分散式系統的實際標準。也就是說,隨著雲成為預設的部署模型,設計人員需要學習如何在沒有云的情況下構建可靠的系統。
回答如何替換2PC的問題首先需要了解協議的含義。儘管它曾經很受歡迎,但圍繞2PC仍存在許多誤解。這篇文章旨在澄清其中至少一些。
2PC不提供“事務”
2PC是原子提交協議,這意味著如果所有參與者都投票“是”,則所有參與者最終都將提交,否則將使系統保持不變。當使用者觸發了提交操作完成後,要麼應用了所有本地修改,要麼都沒有應用。提交可能要花很長時間才能完成,在某些失敗情況下,它將永遠掛起。
讓我們看一個例子,看看“不提供事務”的含義。在我們的場景中,我們有兩個參與者:資料庫和訊息佇列。該圖顯示了兩個參與者都投票“是”並且協調者正在提交。
我們的示例假定佇列事務首先提交,但是2PC並沒有說明參與者提交的順序。它是不確定的,每次執行時可以針對同一組參與者進行更改。
最有趣的是外部觀察者,即客戶。它向兩個參與者發出讀取請求。訊息佇列的讀取請求在協調器提交之後到達。這意味著讀取操作將返回寫入剛剛提交的事務中的佇列的訊息。
對於資料庫,讀取請求在提交之前到達。這將是什麼結果?2PC對此行為一無所知- 不在協議定義的系統模型之內。讀取行為不是由協議定義的,而是部署配置。
讀取操作可以至少有兩種可能的行為:
- 阻塞直到提交本地事務-當本地事務以Serializable隔離級別執行時,將發生這種情況。這是Microsoft分散式事務處理協調器和Microsoft SQL Server 的預設配置,但是可以基於每個事務進行更改,
- 返回最後的提交值(與本地事務寫入的值不同)-當本地事務Snapshot隔離執行時,會發生這種情況。
總而言之,當存在使用2PC提交的事務以及在每個參與者級別執行的其他本地事務時,2PC不會提供系統中原子的原子可見性。確切的行為不是由2PC定義的,而是取決於協議的具體實現,所涉及的資源以及部署和執行時配置。
2PC實現高可用
任何不平凡的協議都定義了它可以容忍的故障條件,而2PC也不例外。2PC特有的是,某些型別的故障會使參與者“卡住死鎖”。只要參與者投票“是”,就無法取得任何進展,直到協調員返回響應。
參與者卡住的原因可能是什麼?首先,協調員的失敗。其次,協調者和參與者之間的網路分割槽腦裂。卡住的可能性取決於協調器的可用性和網路故障的可能性。通過減少故障的可能性,我們可以使2PC的可用性更高。
這涉及已經提到的實現和配置方面。例如,在MSDTC中,協調器是單個程式,但可以在故障轉移群集模式下部署。那是部署決定。2PC中也沒有任何東西可以阻止將協調器實現為法定人數的流程。
最後,如果所有各方(協調者和所有參與者)都在同一本地網路上,單個群集上或單個VM內執行,那麼網路分割槽的可能性是多少?
一如既往,環境為王。
提交延遲不是最大的問題
在2PC中進行提交需要協調者和每個參與者之間進行2次往返,並且生成了4n訊息,其中n參與者的數量是多少。有時,這被認為是協議中許多實際問題的根本原因。這不是理想的選擇,但只能解決其他更大的問題。
問題是鎖定導致參與者級別的潛在爭用,尤其是在處理關聯式資料庫時。持有鎖意味著處理給定狀態的其他事務需要等待該事務提交才能取得任何進展。
這種情況在沒有2PC的情況下就存在,但是協議使得情況總是最糟糕的,因為在2PC中,最慢的參與者定義了持有鎖的時間。
2PC非常適合雲端?
眾所周知,雲端計算供應商在其服務內部使用2PC,並且在IaaS級別執行時使用者可以使用2PC 。也就是說,沒有任何一個雲供應商在本地雲服務級別上支援MSDTC和/或XA,即本地服務不能參與2PC。
通常,可用性和效能被認為是造成這種情況的原因。儘管這不是2PC的強項,但可以說安全(或缺乏安全性)更為重要。
2PC假定參與者和協調者之間高度信任。可以想象一個邪惡的使用者操作特製的協調器,通過故意使事務掛起在“阻塞狀態”來耗盡參與者的資源。
從雲供應商的角度來看,這可能會帶來非常有害的後果。根據協議,參加者在投票“是”後不得取得任何進展。因此,在惡意協調員的情況下,他們將不得不中斷協議或允許其資源被阻止。
即使雲供應商將他們的協調器作為唯一有效的選擇,惡意的參與者仍然可能造成很大的傷害。使雲服務能夠充當2PC參與者有效地為拒絕服務(DoS)攻擊開啟了大門。
(單點風險)
2PC不是唯一的提交協議
2PC只是原子提交的一種可能解決方案。它在某些情況下工作良好,但在違反其假設的環境中使用時效能較差。
實際上,很少有2PC對參與者的假設。圍繞事務確定性設定更多約束條件允許使用其他方法來最大程度地減少鎖保持時間。
當我們認識到缺乏原子可見性時,會採取一些具體措施,例如根據訊息佇列的性質,確保一次性提交提交成功,也有可能最終要求一種對每個參加者實現一次性順序寫入的提交協議。
總結
希望這篇文章對2PC以及我們從協議中得到的內容有更多的瞭解。儘管2PC的時代即將結束,但是很高興知道我們需要在構建的系統中通過其他方式提供什麼保證。
相關文章
- Flink 如何通過2PC實現Exactly-once語義 (原始碼分析)原始碼
- 2pc
- 分散式事務-2PC和3PC分散式
- PHP分散式事務-兩段式提交 2PC(二)PHP分散式
- Oracle Gateway for SQL Server時2PC分散式事務異常處理OracleGatewaySQLServer分散式
- 分散式事務(1)---2PC和3PC理論分散式
- 分散式場景之剛性事務-2PC詳解分散式
- 分散式理論(三) - 2PC協議分散式協議
- 揭祕GBase 8c分散式事務處理核心技術之2PC協議分散式協議
- 分散式一致性協議之2PC和3PC分散式協議
- 獨佔時代或將結束,跨平臺時代即將到來?
- 分散式架構,剛性事務-2PC必須注意的問題及3PC詳細解分散式架構
- 兩階段提交2PC 和 三階段提交3pc
- 關於2PC(二階段提交)和3PC(三階段提交)的理解
- 圍繞低程式碼應用程式開發存在的三個誤解
- CentOS時代即將結束 國產系統能否避免“受限”覆轍?CentOS
- 併發程式設計的原子性 != 事務ACID的原子性程式設計
- 區塊鏈共識演算法(6)分散式一致性演算法2PC和3PC區塊鏈演算法分散式
- 不支援原子性的 Redis 事務也叫事務嗎?Redis
- Flink Kafka Connector與Exactly Once剖析Kafka
- 讀Flink原始碼談設計:Exactly Once原始碼
- Flink Exactly-once 實現原理解析
- 面試官:Redis的事務滿足原子性嗎?面試Redis
- Flink 是如何保證 Exactly-once 語義的?
- JavaScript即將迎來第三個時代或為終結時代? - swyxJavaScript
- 俄羅斯公司提出為小米即將到來的IPO提供代幣化業務
- 【408】21考研已結束,新的征程即將開始
- JAMA:研究發現EHR在許多醫院仍存在重大安全風險
- Ubuntu 14.04 即將結束支援,你該怎麼辦?Ubuntu
- 2019即將結束進入2020:微軟也即將迎來Win10 2004微軟Win10
- 關注已經存在的人工智慧,而不是未來可能存在的人工智慧
- 資料庫事務,原子性、一致性、隔離性、永續性資料庫
- 微服務不是全部,只是特定領域的子集微服務
- 《植物大戰殭屍3》即將推出,你的青春結束了...
- 直播回顧 | Flink Exactly Once & Kafka-connector 運算元Kafka
- 區塊鏈“撒幣時代”結束,“價值時代”到來區塊鏈
- Strategy Analytics:消費者寬頻網際網路流量的爆炸性增長即將結束
- 請多討論問題,而不是解決方案 - frankel