摘要：即服務(wù)不能無響應(yīng)，或出錯分區(qū)的容忍性，這里的分區(qū)不是指數(shù)據(jù)分布式存儲中的分區(qū)。假設(shè)一個分布式系統(tǒng)中，有兩個節(jié)點(diǎn)，處于分區(qū)狀態(tài)。在大多數(shù)的分布式系統(tǒng)設(shè)計(jì)中，人們多會選擇滿足兩點(diǎn)特性。為了解決最終的一致性，這就涉及到分布式事務(wù)。

一、分布式的兩大場景

數(shù)據(jù)存儲的分布式

服務(wù)的分布式

二、數(shù)據(jù)存儲的分布式

比如海量數(shù)據(jù)，單機(jī)存儲不下，需要多機(jī)，以集群的方式存儲，即為數(shù)據(jù)的分布式存儲，數(shù)據(jù)存儲的分布式一般涉及如下幾個方面

數(shù)據(jù)的分片策略

全局主鍵的實(shí)現(xiàn)機(jī)制

跨結(jié)點(diǎn)數(shù)據(jù)的聚合

分布式事務(wù)

數(shù)據(jù)容災(zāi)機(jī)制

2.1數(shù)據(jù)分片策略

2.1.1 基于數(shù)據(jù)范圍來分

比如庫1,存放id 1到1000w的數(shù)據(jù)，庫2存放id 1000w到2000w的數(shù)據(jù)

優(yōu)點(diǎn) ：

單庫數(shù)據(jù)規(guī)模提前預(yù)估。超規(guī)模后，加機(jī)器，不需要遷移數(shù)據(jù)。

且相鄰數(shù)據(jù)大都存放在一個庫上，查詢時，可以減少跨庫聚合。

缺點(diǎn)

容易出現(xiàn)熱點(diǎn)數(shù)據(jù)，比如項(xiàng)目初期，只有庫1被高頻率訪問

待解決問題 ：業(yè)務(wù)變更導(dǎo)致部分?jǐn)?shù)據(jù)被刪除后，如何做到數(shù)據(jù)容量的在平衡。一般也不用考慮這個問題。空間不值錢。

2.1.2 基于id hash來分

優(yōu)點(diǎn) ：hash分配，數(shù)據(jù)分布均勻不會出現(xiàn)數(shù)據(jù)熱點(diǎn)問題

缺點(diǎn)

數(shù)據(jù)的查詢聚合可能需要頻繁跨庫。解決辦法：hash算法和用于計(jì)算hash的key去保證，將業(yè)務(wù)關(guān)心的數(shù)據(jù)分片到同一庫，甚至同一張表

集群擴(kuò)容時，會導(dǎo)致重新hash?？赡苊媾R部分?jǐn)?shù)據(jù)的遷移

2.1.3 怎么解決擴(kuò)容時，數(shù)據(jù)重新hash的問題

方法來至于58沈劍。主要思想：分布式存儲的每個庫，出于數(shù)據(jù)可用性的考慮，設(shè)置一個主從庫，這使得一份數(shù)據(jù)，有兩份存儲。擴(kuò)容時，將每個從庫，變成主庫。于是容量就擴(kuò)容了一倍，修改后的hash算法，依然能正確路由。同時由于新的主庫包含了完整的數(shù)據(jù)，所以不需要做數(shù)據(jù)遷移，只需要做冗余數(shù)據(jù)的清理。圖例如下：

擴(kuò)容之前的狀態(tài)

擴(kuò)容，將從變主。%2=0的庫，會變?yōu)?4=0與%4=2 。%2=1的部分，會變?yōu)?4=1與%4=3;

對擴(kuò)容后的所有主數(shù)據(jù)庫，新增從庫，方便下次的翻倍擴(kuò)容。刪除冗余數(shù)據(jù)

2.2全局主鍵的實(shí)現(xiàn)機(jī)制

snowflake

2.3跨結(jié)點(diǎn)數(shù)據(jù)的聚合

對于跨節(jié)點(diǎn)聚合有兩種思路，一是通過現(xiàn)有數(shù)據(jù)庫，從查詢算法上考慮。第二種，對于過于復(fù)雜的聚合統(tǒng)計(jì)查詢，使用外置索引來實(shí)現(xiàn)，比如elasticsearch

第一種，幾種跨庫分頁的方式

http://www.10tiao.com/html/24...

第二種，索引外置，比如使用elasticsearch。參看elasticsearch 原理

三、服務(wù)的分布式

服務(wù)的分布式，一般涉及如下幾個方面

服務(wù)注冊

服務(wù)發(fā)現(xiàn)

負(fù)載均衡

分布式事務(wù)

服務(wù)的降級熔斷

3.1服務(wù)的注冊

3.2服務(wù)的發(fā)現(xiàn)

3.3負(fù)載均衡

以上三點(diǎn)的大概模式，可以參看之前的筆記微服務(wù)的注冊與發(fā)現(xiàn) https://chen-jun.me/wei-fu-wu...

3.4分布式事務(wù)

3.5服務(wù)的降級熔斷

服務(wù)的降級熔斷，可以在兩方面做文章。比如A服務(wù)調(diào)用B服務(wù)。當(dāng)B服務(wù)處理失敗，導(dǎo)致A服務(wù)故障時。在A端，可以設(shè)置熔斷，當(dāng)故障率達(dá)到一定，A服務(wù)可以有一個默認(rèn)值，不在調(diào)用B服務(wù)。B服務(wù)本身，也可以在A調(diào)用自己出故障時，不走計(jì)算流程，直接返回一個默認(rèn)值。這方面的框架有Spring Cloud Hystrix

Spring Cloud Hystrix是基于Netflix的開源框架Hystrix實(shí)現(xiàn)，該框架實(shí)現(xiàn)了服務(wù)熔斷、線程隔離等一系列服務(wù)保護(hù)功能。

對于熔斷機(jī)制的實(shí)現(xiàn)，Hystrix設(shè)計(jì)了三種狀態(tài)：

1.熔斷關(guān)閉狀態(tài)（Closed）

服務(wù)沒有故障時，熔斷器所處的狀態(tài)，對調(diào)用方的調(diào)用不做任何限制。

2.熔斷開啟狀態(tài)（Open）

在固定時間窗口內(nèi)（Hystrix默認(rèn)是10秒），接口調(diào)用出錯比率達(dá)到一個閾值（Hystrix默認(rèn)為50%），會進(jìn)入熔斷開啟狀態(tài)。進(jìn)入熔斷狀態(tài)后，后續(xù)對該服務(wù)接口的調(diào)用不再經(jīng)過網(wǎng)絡(luò)，直接執(zhí)行本地的fallback方法。

3.半熔斷狀態(tài)（Half-Open）

在進(jìn)入熔斷開啟狀態(tài)一段時間之后（Hystrix默認(rèn)是5秒），熔斷器會進(jìn)入半熔斷狀態(tài)。所謂半熔斷就是嘗試恢復(fù)服務(wù)調(diào)用，允許有限的流量調(diào)用該服務(wù)，并監(jiān)控調(diào)用成功率。如果成功率達(dá)到預(yù)期，則說明服務(wù)已恢復(fù)，進(jìn)入熔斷關(guān)閉狀態(tài)；如果成功率仍舊很低，則重新進(jìn)入熔斷關(guān)閉狀態(tài)。

關(guān)系轉(zhuǎn)換圖如下

四、 分布式事務(wù)

4.1 CAP理論

CAP理論是 Eric Brewer提出的一種分布式狀況下，面臨的三個無法同時兼顧的問題

Consistency所有分布式節(jié)點(diǎn)，對同一份數(shù)據(jù)，擁有相同的副本。不會出現(xiàn)數(shù)據(jù)不一致的情況

Availability對數(shù)據(jù)的更新和讀寫，具有高可用性。即服務(wù)不能無響應(yīng)，或出錯

Partition Tolerance分區(qū)的容忍性，這里的分區(qū)不是指數(shù)據(jù)分布式存儲中的shard分區(qū)。而是指，由于諸如網(wǎng)絡(luò)等原因，導(dǎo)致分布式節(jié)點(diǎn)之間，無法正常同性時，導(dǎo)致的結(jié)點(diǎn)隔離，成為分區(qū)。在分區(qū)時，整個系統(tǒng)還能允許多大程度的對外服務(wù)，成為分區(qū)容忍性。

假設(shè)一個分布式系統(tǒng)中，有兩個節(jié)點(diǎn)，處于分區(qū)狀態(tài)。若允許分區(qū)中節(jié)點(diǎn)可以更新數(shù)據(jù)，那么會喪失一致性 C 。如果要保證一致性 C ，那處于分區(qū)狀態(tài)的節(jié)點(diǎn)將不允許提供服務(wù)，這又會喪失可用性 A 。如果一定要保證 CA ，必須保證節(jié)點(diǎn)之間能夠互相通信，那分區(qū)就不能容忍，就無從談起分區(qū)容忍性 P

Eric Brewer提出，在分布式環(huán)境下，一個系統(tǒng)只能同時滿足以上兩點(diǎn)特性，而無法同時滿足所有特性。在大多數(shù)的分布式系統(tǒng)設(shè)計(jì)中，人們多會選擇滿足 AP 兩點(diǎn)特性。而放棄強(qiáng)一致性，轉(zhuǎn)而追求最終一致性。這種選擇還有另外一個描述叫： B asically A vailable, S oft-state, E ventually consistent 簡稱 BASE

以上CAP理論的簡潔抽象，容易讓人們大概理解分布式系統(tǒng)中的難處，但也容易產(chǎn)生一些誤導(dǎo)。那就是CAP中的3選2，并不是絕對的。所有Eric Brewer后來又做了一次澄清解釋。為什么有誤導(dǎo)？

1、很多時候，如果我們不能保證P，那CA也無從談起

比如用戶是通過html訪問服務(wù)的，這個服務(wù)對應(yīng)的節(jié)點(diǎn)，出現(xiàn)分區(qū)，導(dǎo)致html都無法訪問時。那CA 就不用提了。只有在html能在客戶端緩存，支持用戶離線模式，才可以說系統(tǒng)保證了 P ,同時保證了 A

2、保證AP,并不是完全放棄C，當(dāng)恢復(fù)分區(qū)時，我們依然要采取各種方式解決分區(qū)導(dǎo)致的不一致。

由于網(wǎng)絡(luò)延遲，或網(wǎng)絡(luò)斷連，甚至一個寫請求，同步至所有節(jié)點(diǎn)，由于節(jié)點(diǎn)跨機(jī)房，寫完成的時間不同步，都可能導(dǎo)致分區(qū)。只是分區(qū)的時間長短不一而已。為了解決最終的一致性，這就涉及到分布式事務(wù)。對于分布式數(shù)據(jù)庫中，某個值的寫，保證其一致性，可以使用paxos,raft協(xié)議算法。對于業(yè)務(wù)類型的事務(wù)?？梢允褂肨CC或者消息通知的模式來進(jìn)行事務(wù)管理

4.2 最終一致性方案——paxos,raft

zookeeper就是使用的paxos協(xié)議

4.3最終一致性方案——TCC

分為 T ry , C onfirm, C ancel ，簡稱TCC。

Try:嘗試鎖定事務(wù)涉及的資源，進(jìn)行資源預(yù)留

Confirm:對預(yù)留的資源做確認(rèn)提交

Cancel:如果confirm失敗，則進(jìn)行補(bǔ)償操作，回滾業(yè)務(wù)處理，解鎖預(yù)留資源

可以看到這種，try , confrm/cancel。也是兩階段。那跟傳統(tǒng)JAT支持的兩階段事務(wù)有什么區(qū)別？

JTA支持的傳統(tǒng)兩階段事務(wù)，需要涉及的資源支持XA協(xié)議標(biāo)準(zhǔn)，但TCC則需要遵循什么工業(yè)標(biāo)準(zhǔn)，可以是完全的業(yè)務(wù)實(shí)現(xiàn)。傳統(tǒng)的兩階段提交，任然要求滿足事務(wù)的ACID，這導(dǎo)致資源的可用性很差。

傳統(tǒng)兩階段提交的特點(diǎn)：

TCC事務(wù)的特點(diǎn)：

4.4 最終一致性方案——消息通知

這類事務(wù)的特點(diǎn)是，需要借助消息通知，來使得事務(wù)涉及的多個分布式服務(wù)能夠協(xié)調(diào)，完成業(yè)務(wù)期望。這種方式，也有幾種細(xì)分的設(shè)計(jì)。

4.4.1 使用本地事務(wù)

同一個共用的消息表，來協(xié)調(diào)服務(wù)雙方的業(yè)務(wù)執(zhí)行狀況

4.4.2 使用MQ

4.4.3 另外一種使用MQ的方式

想要了解更多分布式知識點(diǎn)的，可以關(guān)注我一下，我后續(xù)也會整理更多關(guān)于分布式架構(gòu)這一塊的知識點(diǎn)分享出來