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

一、分布式的兩大場景

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

服務的分布式

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

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

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

全局主鍵的實現(xiàn)機制

跨結點數(shù)據(jù)的聚合

分布式事務

數(shù)據(jù)容災機制

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

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

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

優(yōu)點 ：

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

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

缺點

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

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

2.1.2 基于id hash來分

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

缺點

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

集群擴容時，會導致重新hash。可能面臨部分數(shù)據(jù)的遷移

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

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

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

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

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

2.2全局主鍵的實現(xiàn)機制

snowflake

2.3跨結點數(shù)據(jù)的聚合

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

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

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

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

三、服務的分布式

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

服務注冊

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

負載均衡

分布式事務

服務的降級熔斷

3.1服務的注冊

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

3.3負載均衡

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

3.4分布式事務

3.5服務的降級熔斷

服務的降級熔斷，可以在兩方面做文章。比如A服務調用B服務。當B服務處理失敗，導致A服務故障時。在A端，可以設置熔斷，當故障率達到一定，A服務可以有一個默認值，不在調用B服務。B服務本身，也可以在A調用自己出故障時，不走計算流程，直接返回一個默認值。這方面的框架有Spring Cloud Hystrix

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

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

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

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

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

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

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

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

關系轉換圖如下

四、 分布式事務

4.1 CAP理論

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3最終一致性方案——TCC

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

Try:嘗試鎖定事務涉及的資源，進行資源預留

Confirm:對預留的資源做確認提交

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

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

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

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

TCC事務的特點：

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

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

4.4.1 使用本地事務

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

4.4.2 使用MQ

4.4.3 另外一種使用MQ的方式

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