????前幾天和同事聊天，同事說：

“業(yè)務(wù)的服務(wù)（相對于我們基礎(chǔ)架構(gòu)這邊的底層技術(shù)）在技術(shù)上就需要解決三個問題：分布式、通信和存儲。”

我回憶之前做業(yè)務(wù)的時光，覺得確實，再加上一個“服務(wù)治理”就差不多了。想想“服務(wù)設(shè)計要解決的問題”這個話題可以把之前靜兒寫的很多文章做一個歸納概括。今天做一個總結(jié)。

分布式

通常要解決的問題是分布式事務(wù)的一致性問題。

剛性事務(wù)和柔性事務(wù)

　　剛性事務(wù)：嚴格遵循ACID原則（原子性、一致性、隔離性、持久性）的事務(wù)。基本上指的是本地數(shù)據(jù)庫事務(wù)。根據(jù)CAP原則，分布式下的事務(wù)都不是剛性事務(wù)。

　　柔性事務(wù)：遵循CAP理論或者其變種BASE理論的事務(wù)。分布式事務(wù)基本上都是柔性事務(wù)。

　　因為剛性事務(wù)基本上等價于本地數(shù)據(jù)庫事務(wù)，而柔性事務(wù)基本上等價于分布式事務(wù)。只是一個是按照事務(wù)嚴格性來區(qū)分，一個是按使用場景來區(qū)分。所以平時除了用來做對比，很少直接提剛性事務(wù)和柔性事務(wù)的概念。

分布式事務(wù)理論

　　分布式事務(wù)：在分布式環(huán)境下，各個操作步驟并不在同一臺機器上，需要保證所有動作都有一個統(tǒng)一的結(jié)果的一組操作。

　　CAP原則（記得在之前的博客中多次寫過）：分布式環(huán)境下，數(shù)據(jù)一致性、服務(wù)可用性、分區(qū)容錯性三者最多只能滿足其中二者。

　　　　數(shù)據(jù)一致性（consistency）:這里的一致性是強一致性，又叫線性一致性。即一個寫操作成功，而讀出的必須是寫操作后的新數(shù)據(jù)。而寫操作失敗讀出的必須是寫操作前的舊數(shù)據(jù)。

　　　　服務(wù)可用性（availability）:所有的操作在一定時間內(nèi)都能得到響應(yīng)。

　　　　分區(qū)容錯性（partition-tolerance）:在網(wǎng)絡(luò)分區(qū)環(huán)境下，被分割的節(jié)點仍然能對外提供服務(wù)。

選 ? ?擇說 ? ?明

AP分隔的節(jié)點同時對外服務(wù)但不能相互通信，將導(dǎo)致狀態(tài)不一致，即不能滿足C

CP網(wǎng)絡(luò)分區(qū)的情況下為達成C，請求只能一直等待，即不滿足A

CA在一定時間內(nèi)要達到節(jié)點狀態(tài)一致，要求不能出現(xiàn)網(wǎng)絡(luò)分區(qū)，則不能滿足P

　　BASE理論：這是基于CAP理論權(quán)衡之后的結(jié)果。核心思想是即使無法做到強一致性，但可以使用一些技術(shù)手段達到最終一致。BASE是Basically Available(基本可用)、Soft state(軟狀態(tài))、Eventually consistent(最終一致性)的縮寫。

分布式事務(wù)一致性實現(xiàn)方案

　　為了解決分布式一致性問題，前人在性能和數(shù)據(jù)一致性的權(quán)衡過程中總結(jié)了許多經(jīng)典的協(xié)議和算法。比較著名的有：2PC、3PC、TCC、Paxos、Raft、Zab、ISR。除了這些之外，業(yè)界用的最多的其實是基于MQ實現(xiàn)的。

　　2PC（Two Phase Commit）兩階段提交:一般說的兩階段提交是基于XA協(xié)議的。另外JTA協(xié)議的也比較常見。

　　XA是一個分布式事務(wù)協(xié)議。它大致分為兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫實現(xiàn)，比如Oracle、DB2都實現(xiàn)了XA接口。MySQL對XA的支持不是很好。而事務(wù)管理器作為全局的調(diào)度者，負責(zé)各個本地資源的提交和回滾。

兩階段提交的優(yōu)點是：原理簡單、實現(xiàn)方便。缺點是同步阻塞、單點問題、數(shù)據(jù)不一致。

　　3PC(Three Phrase Commit)三階段提交：分為CanCommit、PreCommit、Do Commit 三個階段。就是把兩階段提交的Phase 1分成兩個，預(yù)提交的時候如果有參與者返回No或者超時則中斷事務(wù)。

　　三階段提交的優(yōu)點是降低參與者阻塞范圍，并能夠在出現(xiàn)單點故障后繼續(xù)達成一致。缺點是因為preCommit階段，在這個階段如果出現(xiàn)網(wǎng)絡(luò)分區(qū)，協(xié)調(diào)者無法與參與者正常通信，參與者仍然會進行實物提交，造成數(shù)據(jù)不一致。

　　TCC(Try-Confirm-Cancel)

　　　　Try:完成所有的檢查，預(yù)留必須資源

　　　　Confirm:使用Try階段預(yù)留的資源執(zhí)行業(yè)務(wù)，如果執(zhí)行出現(xiàn)異常，要重試

　　　　Cancel:釋放Try階段預(yù)留資源

　　　　TCC能夠?qū)Ψ植际绞聞?wù)中的各個資源進行分別鎖定，分別提交與釋放。適用于嚴格一致、執(zhí)行時間短、實時性要求高的場景。

　　Paxos算法：之前看過《從Paxos到Zookeeper》那本書，沒怎么看明白。實現(xiàn)比較復(fù)雜，Zookeeper就是用這個來實現(xiàn)的分布式一致性。Paxos算法、Raft協(xié)議和Zab（Zookeeper Atomic Broadcast）協(xié)議都是一種通過多數(shù)投票來保證主備數(shù)據(jù)一致性的。

　　ISR（In-Sync Replicas）機制：Kafka使用了這個機制來保證數(shù)據(jù)一致性。ISR認為對于2f+1個副本來說，多數(shù)投票機制要求最多只能允許f個副本發(fā)生故障，如果要支持2個副本的容錯，則需要至少維持5個副本。

通信……