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

一、分布式的兩大場景

數據存儲的分布式

服務的分布式

二、數據存儲的分布式

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

數據的分片策略

全局主鍵的實現機制

跨結點數據的聚合

分布式事務

數據容災機制

2.1數據分片策略

2.1.1 基于數據范圍來分

比如庫1,存放id 1到1000w的數據，庫2存放id 1000w到2000w的數據

優點 ：

單庫數據規模提前預估。超規模后，加機器，不需要遷移數據。

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

缺點

容易出現熱點數據，比如項目初期，只有庫1被高頻率訪問

待解決問題 ：業務變更導致部分數據被刪除后，如何做到數據容量的在平衡。一般也不用考慮這個問題。空間不值錢。

2.1.2 基于id hash來分

優點 ：hash分配，數據分布均勻不會出現數據熱點問題

缺點

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

集群擴容時，會導致重新hash?？赡苊媾R部分數據的遷移

2.1.3 怎么解決擴容時，數據重新hash的問題

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

擴容之前的狀態

擴容，將從變主。%2=0的庫，會變為%4=0與%4=2 。%2=1的部分，會變為%4=1與%4=3;

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

2.2全局主鍵的實現機制

snowflake

2.3跨結點數據的聚合

對于跨節點聚合有兩種思路，一是通過現有數據庫，從查詢算法上考慮。第二種，對于過于復雜的聚合統計查詢，使用外置索引來實現，比如elasticsearch

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

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

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

三、服務的分布式

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

服務注冊

服務發現

負載均衡

分布式事務

服務的降級熔斷

3.1服務的注冊

3.2服務的發現

3.3負載均衡

以上三點的大概模式，可以參看之前的筆記微服務的注冊與發現 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實現，該框架實現了服務熔斷、線程隔離等一系列服務保護功能。

對于熔斷機制的實現，Hystrix設計了三種狀態：

1.熔斷關閉狀態（Closed）

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

2.熔斷開啟狀態（Open）

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

3.半熔斷狀態（Half-Open）

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

關系轉換圖如下

四、 分布式事務

4.1 CAP理論

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

Consistency所有分布式節點，對同一份數據，擁有相同的副本。不會出現數據不一致的情況

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

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

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

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

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

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

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

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

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

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

zookeeper就是使用的paxos協議

4.3最終一致性方案——TCC

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

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

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

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

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

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

傳統兩階段提交的特點：

TCC事務的特點：

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

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

4.4.1 使用本地事務

同一個共用的消息表，來協調服務雙方的業務執行狀況

4.4.2 使用MQ

4.4.3 另外一種使用MQ的方式

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