分佈式系統學習筆記

概念：

分佈式系統：

       組件分佈在網絡計算機上，組件之間僅僅經過消息傳遞來通訊並協調行動。

節點：

       完成一組完整邏輯的程序個體，對應於server上的一個獨立進程。

異常：

       在分佈式系統中還存在着一種狀態：超時，意味着結果徹底不肯定。分佈式協議就是保證系統在各類異常情形下仍能正常的工做。

CAP理論：

1. C（Consistency：一致性）：強一致性，保證數據中的數據徹底一致；
2. A（Available：可用性）：在系統異常時，仍然能夠提供服務，注：這兒的可用性，一方面要求系統能夠正常的運行返回結果，另外一方面一樣對響應速度有必定的保障；
3. P（Tolerance to the partition of network：分區容錯性）：既然是分佈式系統，不少組件都是部署在不一樣的server中，經過網絡通訊協調工做，這就要求在某些節點服發生網絡分區異常，系統仍然能夠正常工做。

 

強一致性和強可用性在實際的系統中每每不能同時兼得，須要根據需求來權衡選擇；

數據存儲系統：

也即數據的分佈式存儲方式，主要有如下幾個方式：

哈希方式：

每條數據經過某種計算方式計算出Hash值並分配到對應的服務器上；

int serverId = data.hashcode % serverTotalNum; 經過這種方式就能夠將數據對應到不一樣的服務器上；

優勢：簡單易用，只須要根據數據的鍵值計算出serverid便可；

缺點：可擴展性不高，當須要增長服務器時會出現大量數據遷移；並且容易形成數據傾斜的問題；

數據範圍分佈方式：

將數據的某個特徵值按照值域分爲不一樣區間。好比按時間、區間分割，不一樣時間範圍劃分到不一樣server上。

優勢：數據區間能夠自由分割，當出現數據傾斜時，即某一個區間的數據量很是大，則能夠將該區間split而後將數據進行重分配；集羣方便擴展，當添加新的節點，只需將數據量多的節點數據遷移到新節點便可。

缺點：須要存儲大量的元信息（數據區間和server的對應關係）。

 

數據量分佈方式：

這樣的存儲方式和數據的特徵類型沒有關係，能夠理解成將一個大的文件分紅固定大小的多個block。

優勢：不會有數據傾斜的問題，並且數據遷移時速度很是快（由於一個文件由多個block組成，block在不一樣的server上，遷移一個文件能夠多個server並行複製這些block）。

缺點：須要存儲大量的meta信息（文件和block的對應關係，block和server的對應關係）。

 

一致性哈希方式：

 

 

把數據用hash函數（如MD5），映射到一個很大的空間裏，如圖所示。數據的存儲時，先獲得一個hash值，對應到這個環中的每一個位置。一致性哈希和哈希的數據分佈方式大概一致，惟一不一樣的是一致性哈希hash的值域是個環。

優勢：集羣可擴展性好，當增長刪除節點，隻影響相鄰的數據節點。

缺點：當一個節點掛掉時，將壓力所有轉移到相鄰節點，有可能將相鄰節點壓垮。

 

副本控制問題：

當某臺服務器出現故障時，這臺服務器上的數據就不可訪問，爲了保證系統仍談能正常運轉，須要對數據存儲多個副本。

引入多個副本後，引來了一系列問題：多個副本之間，讀取時以哪一個副本的數據爲準呢，更新時什麼纔算更新成功，是全部副本都更新成功仍是部分副本更新成功便可認爲更新成功？這些問題其實就是CAP理論中可用性和一致性的問題。其中primary-secondary副本控制模型則是解決這類問題行之有效的方法。

 

副本的更新：

副本更新基本流程：數據更新操做發到primary節點，由primary將數據更新操做同步到其餘secondary副本，根據其餘副本的同步結果返回客戶端響應。

以mysql的master slave簡單說明下，一般狀況下，mysql的更新只須要master更新成功便可響應客戶端，slave能夠經過binlog慢慢同步，這種情形讀取slave會有必定的延遲，一致性相對較弱，可是系統的可用性有了保證；另外一種slave更新策略，數據的更新操做不只要求master更新成功，同時要求slave也要更新成功，primary和secondray數據保持同步，系統保證強一致性，但可用性相對較差，響應時間變長。

根據quorum協議，在保證必定的可用性同時又保證必定的一致性的情形下，設置副本更新成功數爲總副本數的一半（即N/2+1）性價比最高。

副本的讀取：

副本的讀取策略和一致性的選擇有關，若是須要強一致性，咱們能夠只從primary副本讀取，若是須要最終一致性，能夠從secondary副本讀取結果，若是須要讀取最新數據，則按照quorum協議要求，讀取相應的副本數。

副本的切換：

當系統中某個副本不可用時，須要從剩餘的副本之中選取一個做爲primary副原本保證後續系統的正常執行。

存儲模型：

 

 

Client模塊：負責用戶和系統內部模塊的通訊。

Master模塊：負責元數據的存儲以及節點健康狀態的管理。

Data節點模塊：用於數據的存儲和數據查詢返回。

 

數據的查詢流程一般分兩步：

1. 向master節點查詢數據對應的節點信息；

2. 根據返回的節點信息鏈接對應節點，返回相應的數據。

數據計算處理系統：

數據投遞策略：

1. at most once：數據處理最多一次，這種語義在異常狀況下會有數據丟失；
2. at least once：數據處理最少一次，這種語義會形成數據的重複；
3. exactly once：數據只處理一次，這種語義支持是最複雜的，要想完成這一目標須要在數據處理的各個環節作到保障。

如何作到exactly once， 須要在數據處理各個階段作些保證：

1. 數據接收：由不一樣的數據源保證。
2. 數據傳輸：數據傳輸能夠保證exactly once。
3. 數據輸出：根據數據輸出的類型肯定，若是數據的輸出操做對於一樣的數據輸入保證冪等性，這樣就很簡單（好比能夠把kafka的offset做爲輸出mysql的id），若是不是，要提供額外的分佈式事務機制如兩階段提交等等。

異常任務的處理：

由於數據計算的節點都是無狀態的，只要啓動任務副本便可。

其中任務恢復策略有如下幾種：

1. 簡單暴力，重啓任務從新計算相關數據；當某個數據執行超時或失敗，則將該數據從源頭開始在拓撲中從新計算。
2. 根據checkpoint重試出錯的任務，典型應用：mapreduce，一個完整的數據處理是分多個階段完成的，每一個階段（map 或者reduce）的輸出結果都會保存到相應的存儲中，只要重啓任務從新讀取上一階段的輸出結果便可繼續開始運行，沒必要從開始從新執行該任務。

背壓——Backpressure：

在數據處理中，常常會擔憂這樣一個問題：數據處理的上游消費數據速度太快，會不會壓垮下游數據輸出端如mysql等。 一般的解決方案：上線前期咱們會作詳細的測試，評估數據下游系統承受的最大壓力，而後對數據上游進行限流的配置，好比限制每秒最多消費多少數據。

數據處理通用架構：

 

1. client： 負責計算任務的提交。
2. scheduler ： 計算任務的生成和計算資源的調度，同時還包含計算任務運行情況的監控和異常任務的重啓。
3. worker：計算任務會分紅不少小的task， worker負責這些小task的執行同時向scheduler彙報當前node可用資源及task的執行情況。