前幾天和同事聊天,同事說: “業務的服務(相對於我們基礎架構這邊的底層技術)在技術上就需要解決三個問題:分散式、通信和存儲。” 我回憶之前做業務的時光,覺得確實,再加上一個“服務治理”就差不多了。想想“服務設計要解決的問題”這個話題可以把之前靜兒寫的很多文章做一個歸納概括。今天做一個總結。 分散式 ...
前幾天和同事聊天,同事說:
“業務的服務(相對於我們基礎架構這邊的底層技術)在技術上就需要解決三個問題:分散式、通信和存儲。”
我回憶之前做業務的時光,覺得確實,再加上一個“服務治理”就差不多了。想想“服務設計要解決的問題”這個話題可以把之前靜兒寫的很多文章做一個歸納概括。今天做一個總結。
分散式
通常要解決的問題是分散式事務的一致性問題。
剛性事務和柔性事務
剛性事務:嚴格遵循ACID原則(原子性、一致性、隔離性、持久性)的事務。基本上指的是本地資料庫事務。根據CAP原則,分散式下的事務都不是剛性事務。
柔性事務:遵循CAP理論或者其變種BASE理論的事務。分散式事務基本上都是柔性事務。
因為剛性事務基本上等價於本地資料庫事務,而柔性事務基本上等價於分散式事務。只是一個是按照事務嚴格性來區分,一個是按使用場景來區分。所以平時除了用來做對比,很少直接提剛性事務和柔性事務的概念。
分散式事務理論
分散式事務:在分散式環境下,各個操作步驟並不在同一臺機器上,需要保證所有動作都有一個統一的結果的一組操作。
CAP原則(記得在之前的博客中多次寫過):分散式環境下,數據一致性、服務可用性、分區容錯性三者最多只能滿足其中二者。
數據一致性(consistency):這裡的一致性是強一致性,又叫線性一致性。即一個寫操作成功,而讀出的必須是寫操作後的新數據。而寫操作失敗讀出的必須是寫操作前的舊數據。
服務可用性(availability):所有的操作在一定時間內都能得到響應。
分區容錯性(partition-tolerance):在網路分區環境下,被分割的節點仍然能對外提供服務。
選 擇說 明
AP分隔的節點同時對外服務但不能相互通信,將導致狀態不一致,即不能滿足C
CP網路分區的情況下為達成C,請求只能一直等待,即不滿足A
CA在一定時間內要達到節點狀態一致,要求不能出現網路分區,則不能滿足P
BASE理論:這是基於CAP理論權衡之後的結果。核心思想是即使無法做到強一致性,但可以使用一些技術手段達到最終一致。BASE是Basically Available(基本可用)、Soft state(軟狀態)、Eventually consistent(最終一致性)的縮寫。
分散式事務一致性實現方案
為瞭解決分散式一致性問題,前人在性能和數據一致性的權衡過程中總結了許多經典的協議和演算法。比較著名的有:2PC、3PC、TCC、Paxos、Raft、Zab、ISR。除了這些之外,業界用的最多的其實是基於MQ實現的。
2PC(Two Phase Commit)兩階段提交:一般說的兩階段提交是基於XA協議的。另外JTA協議的也比較常見。
XA是一個分散式事務協議。它大致分為兩部分:事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現,比如Oracle、DB2都實現了XA介面。MySQL對XA的支持不是很好。而事務管理器作為全局的調度者,負責各個本地資源的提交和回滾。
兩階段提交的優點是:原理簡單、實現方便。缺點是同步阻塞、單點問題、數據不一致。
3PC(Three Phrase Commit)三階段提交:分為CanCommit、PreCommit、Do Commit 三個階段。就是把兩階段提交的Phase 1分成兩個,預提交的時候如果有參與者返回No或者超時則中斷事務。
三階段提交的優點是降低參與者阻塞範圍,並能夠在出現單點故障後繼續達成一致。缺點是因為preCommit階段,在這個階段如果出現網路分區,協調者無法與參與者正常通信,參與者仍然會進行實物提交,造成數據不一致。
TCC(Try-Confirm-Cancel)
Try:完成所有的檢查,預留必須資源
Confirm:使用Try階段預留的資源執行業務,如果執行出現異常,要重試
Cancel:釋放Try階段預留資源
TCC能夠對分散式事務中的各個資源進行分別鎖定,分別提交與釋放。適用於嚴格一致、執行時間短、實時性要求高的場景。
Paxos演算法:之前看過《從Paxos到Zookeeper》那本書,沒怎麼看明白。實現比較複雜,Zookeeper就是用這個來實現的分散式一致性。Paxos演算法、Raft協議和Zab(Zookeeper Atomic Broadcast)協議都是一種通過多數投票來保證主備數據一致性的。
ISR(In-Sync Replicas)機制:Kafka使用了這個機制來保證數據一致性。ISR認為對於2f+1個副本來說,多數投票機制要求最多只能允許f個副本發生故障,如果要支持2個副本的容錯,則需要至少維持5個副本。
通信……
關於作者
靜兒,20歲時畢業於東北大學電腦系。在畢業後的第一家公司由於出眾的語言天賦,在1年的時間里從零開始學日語並以超高分通過了國際日語一級考試,擔當兩年日語翻譯的工作。後就職於人人網,轉型做互聯網開發。中國科學院心理學研究生。有近百個技術發明專利,創業公司合伙人。有日本東京,美國矽谷技術支持經驗。目前任美團點評技術專家(歡迎關註靜兒的個人技術公眾號:編程一生),心法文章可參考我的《自動化管理之新人培養》
技術交流可關註我的github:https://github.com/xiexiaojing
關註靜兒公眾號,不定期漫畫技術推送~