分佈式事務

原創轉載請註明出處：http://www.javashuo.com/article/p-olhwnbzd-n.html

 

CAP定律

Note:

zookeeper是按照CP原則構建的

NoSQL按數據模型存儲性質 分4類

• 鍵值存儲（Key-Value stores） ——  Redis（適合Session信息、用戶配置信息、購物車數據）
• 面向表（Table-oriented） ——  BigTable、Cassandra、HBase（適合事件記錄、CMS、博客平臺、計數器、不適合ACID、查詢模式變化頻繁的場合）
• 面向文本（Document-oriented） ——  MongoDB（適合事件記錄、CMS、博客平臺、網站分析、實時分析、電子商務應用）
• 面向圖（Graph-oriented） ——  Neo4j（適合互聯網數據，推薦引擎，基於位置的服務）

與傳統的關係型數據庫相比，HBase有更好的伸縮能力，跟適合海量數據的存儲和處理，而且HBase可以支持多個Region Server的寫入，併發寫入性能十分出色。可是HBase自己所支持的查詢維度有限，難以支持複雜的條件查詢，如group by、order by、join等，這些特色是它的應用場景受到了限制。

對於Redis來講，它擁有更好的讀寫吞吐能力，可以支撐更高的併發數，而相較於其餘的key-value類型的數據庫，Redis可以提供更爲豐富的數據類型支持，能更靈活地知足業務需求。

 

在分佈式系統中，同時知足「CAP定律」中的「一致性」、「可用性」和「分區容錯性」三者是不可能的，這比現實中找對象需同時知足「高、富、帥」或「白、富、美」更加困難。在互聯網領域的絕大多數的場景，都須要犧牲強一致性來換取系統的高可用性，系統每每只須要保證「最終一致性」，只要這個最終時間是在用戶能夠接受的範圍內便可。

須要明確的一點是，對於一個分佈式系統而言，分區容錯性能夠說是一個最基本的要求。由於既然是一個分佈式系統，那麼分佈式系統中的組件必然須要被部署到不一樣的節點，不然也就無所謂分佈式系統了，所以必然出現子網絡。而對於分佈式系統而言，網絡問題又是一個一定會出現的異常狀況，所以分區容錯性也就成爲了一個分佈式系統必然須要面對和解決的問題。所以系統架構師每每須要把精力花在如何根據業務特色在C（一致性）和A（可用性）之間尋求平衡。

 

BASE理論

BASE是 Basically Available（基本可用）、Soft state（軟狀態）、Eventually consistent（最終一致性）三個 短語的簡寫。BASE是對CAP中一致性和可用性權衡的結果，其來源於大規模互聯網系統分佈式實踐的總結，是基於CAP定理逐步演化而來的，其核心思想是即便沒法作到強一致性（Strong consistency），但每一個應用均可以根據自身的業務特色，採用適當的方式來使系統達到最終一致性（Eventually consistency）。

基本可用

弱狀態

最終一致性

總的說來，BASE理論面向的是大型高可用可擴展的分佈式系統，和傳統的ACID特性是相反的，它徹底不一樣於ACID的強一致性模型，而是經過犧牲強一致性來得到可用性，並容許數據在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分佈式場景中，不一樣業務單元和組件對數據一致性的要求是不一樣的，所以在具體的分佈式系統架構設計中，ACID特性與BASE理論每每又會結合在一塊兒使用。

 

分佈式事務的服務架構部署

以商城爲例，一般，都是基於第二種架構部署實現的

• 同服務不一樣數據庫

• 不一樣服務不一樣數據庫

 

分佈式事務處理模式

涉及分佈式數據庫，則要考慮使用分佈式事務，最多見的如兩階段提交、三階段提交協議，這種方式實現事務回滾難度較低，可是對性能影響比較大，由於在大多數場景中須要的是最終一致性，而不是強一致性。所以，能夠考慮事務表、消息隊列、補償機制（執行/回滾）、TCC模式（預佔/確認/取消）、Sagas模式（拆分事務+補償機制）等實現最終一致性。

 

Reference

https://www.infoq.cn/article/solution-of-distributed-system-transaction-consistency/

https://www.open-open.com/lib/view/open1473404638516.html

https://yq.aliyun.com/articles/599997

https://time.geekbang.org/column/article/127527