????前幾天和同事聊天雄驹，同事說(shuō)：

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

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

分布式

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

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

　　剛性事務(wù)：嚴(yán)格遵循ACID原則（原子性、一致性衰琐、隔離性也糊、持久性）的事務(wù)∠壑妫基本上指的是本地?cái)?shù)據(jù)庫(kù)事務(wù)狸剃。根據(jù)CAP原則，分布式下的事務(wù)都不是剛性事務(wù)狗热。

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

　　因?yàn)閯傂允聞?wù)基本上等價(jià)于本地?cái)?shù)據(jù)庫(kù)事務(wù)斗搞，而柔性事務(wù)基本上等價(jià)于分布式事務(wù)指攒。只是一個(gè)是按照事務(wù)嚴(yán)格性來(lái)區(qū)分，一個(gè)是按使用場(chǎng)景來(lái)區(qū)分僻焚。所以平時(shí)除了用來(lái)做對(duì)比允悦，很少直接提剛性事務(wù)和柔性事務(wù)的概念。

分布式事務(wù)理論

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

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

　　　　數(shù)據(jù)一致性（consistency）:這里的一致性是強(qiáng)一致性总珠，又叫線性一致性。即一個(gè)寫操作成功勘纯，而讀出的必須是寫操作后的新數(shù)據(jù)局服。而寫操作失敗讀出的必須是寫操作前的舊數(shù)據(jù)。

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

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

選 ? ?擇說(shuō) ? ?明

AP分隔的節(jié)點(diǎn)同時(shí)對(duì)外服務(wù)但不能相互通信堤结，將導(dǎo)致?tīng)顟B(tài)不一致唆迁，即不能滿足C

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

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

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

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

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

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

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

兩階段提交的優(yōu)點(diǎn)是：原理簡(jiǎn)單、實(shí)現(xiàn)方便渊抄。缺點(diǎn)是同步阻塞惠险、單點(diǎn)問(wèn)題、數(shù)據(jù)不一致抒线。

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

　　三階段提交的優(yōu)點(diǎn)是降低參與者阻塞范圍眨猎，并能夠在出現(xiàn)單點(diǎn)故障后繼續(xù)達(dá)成一致抑进。缺點(diǎn)是因?yàn)閜reCommit階段，在這個(gè)階段如果出現(xiàn)網(wǎng)絡(luò)分區(qū)睡陪，協(xié)調(diào)者無(wú)法與參與者正常通信寺渗，參與者仍然會(huì)進(jìn)行實(shí)物提交，造成數(shù)據(jù)不一致兰迫。

　　TCC(Try-Confirm-Cancel)

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

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

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

　　　　TCC能夠?qū)Ψ植际绞聞?wù)中的各個(gè)資源進(jìn)行分別鎖定涡拘，分別提交與釋放。適用于嚴(yán)格一致据德、執(zhí)行時(shí)間短鳄乏、實(shí)時(shí)性要求高的場(chǎng)景。

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

　　ISR（In-Sync Replicas）機(jī)制：Kafka使用了這個(gè)機(jī)制來(lái)保證數(shù)據(jù)一致性蝌焚。ISR認(rèn)為對(duì)于2f+1個(gè)副本來(lái)說(shuō)裹唆，多數(shù)投票機(jī)制要求最多只能允許f個(gè)副本發(fā)生故障，如果要支持2個(gè)副本的容錯(cuò)只洒，則需要至少維持5個(gè)副本许帐。

通信……