1、raft協議原理
raft
2、單個shard的複製
raft-single
3、raft group組
在一定情況下，copyset的數量不是越多越好，在恢復時間確定的情況下，找到合適的copyset的數量可以降低資料丟失的概率。為了提高儲存系統資料可靠性，首先在系統允許的成本範圍內選擇合適的副本數，再次在系統設計中我們首先優先考慮加快資料恢復時間，在此基礎上減小系統的copyset數量。使得在既定的成本下達到盡可能高的可靠性。參考**《copysets:reducing the frequency of data loss in cloud storage》，該**中的實驗資料顯示，在facebook hdfs集群上作實驗，為了有效降低資料丟失概率，資料放置演算法，從原來的random replicaiton更改為copyset replication 演算法，實驗結果說明可 將facebook hdfs集群1%節點故障時的資料丟失概率從22.8%降低道0.78%。
在大型集群中，多個節點的同時丟失具有很高的資料丟失概率。例如，考慮使用副本數為3的100個節點的群集，其shard數範圍約為10k。同時丟失2個或更多節點具有很高的資料丟失概率，因為可能存在10k shard之外的shard，而該shard在2個丟失的節點上具有3個副本中的2個。在存在多節點故障的情況下，copyset演算法可以顯著降低了資料丟失的可能性。
根據系統節點數，和副本數量，進行多個輪次的計算，每一輪次把所有節點按照副本數劃分為 n／r 個copyset。每次確保其中的copyset 不與當前和之前所有輪次中已經產生的copyset相同，最後資料寫入的時候，選擇乙個copyset 寫入即可。 由於每個排列會吧s(scatter width) 增加r-1,所以 演算法執行p = s/（r-1） 次， k(copyset數量) = p (n/r) = s/(r-1) (n/r)。
複製集將群集分為不相交的節點集。每組的大小將基於使用的副本數。為每個副本建立單獨的副本集。shard應該更喜歡在副本集中分配其副本，而不是在副本集中散布其副本。
1.管理副本集（哪個節點屬於哪個副本集）
副本集分配應考慮節點的位置，以便不會丟失位置容錯能力。將節點分配給副本集時，應考慮新增/刪除/損壞的節點。
2.重新平衡範圍中的所有副本，以盡最大努力將其駐留在單個副本集中。
將副本重新平衡到副本集很重要，但是某些屬性（如使用者設定的約束）應優先於副本集。
副本集最初將是乙個選擇加入功能（基於群集設定），並且實現為分散寬度為replication_factor - 1。
該集群將被分為多個副本集。對於群集中的每個副本，將生成單獨的副本集。
副本的副本集的要求是
1.對於rf -1的散布寬度，副本集之間的節點應該沒有重疊，並且對於散布寬度》 = rf（其中rf是複製因子），應使重疊節點最小化。
2.副本集應具有本地容錯能力
3.副本集應重新平衡節點的新增/刪除/故障。
為系統中使用的每個副本生成副本集。如果對齊了不同副本的副本集，則可以提供更好的容錯能力。
副本分配策略採用最佳副本集分割分配演算法。
特定的副本的副本集的最佳分配可以如下進行：
1.計算 num_copysets = floor(num_stores/replication_factor)
2.基於機架等特定配置進行儲存排序
3.分配副本集到儲存，採用輪詢排程方案（round-robin）
例如，有如下儲存情況：
rack1：s1 s2 s3
rack2: s4 s5 s6
rack3: s7 s8 s9 s10
複製因子是3的副本集將建立：
num_copysets = 10/3 = 3
cs1: s1 s4 s7 s10
cs2: s2 s5 s8
cs3: s3 s6 s9
swap
在源副本集和目標副本集之間進行交換，以確保源副本集的多樣性增加，而目標副本集的多樣性確實減少（或者如果減少，它仍然》複製因子）。
基於源副本集和目標副本集中存在的位置，在源副本集和目標副本集之間進行儲存交換。交換所需的條件是：
1.源副本集的多樣性《複製因子。這意味著源副本集在特定位置具有兩個儲存。這些付出之一將是源交換候選者。
2.目標副本集具有源副本集中不存在的區域性性（我們稱此目標區域性性）。來自該地區的商店將成為目標交換候選人。
3.以下之一是正確的
4.目標副本集中不存在源交換候選的位置。
1.在目標位置有兩個儲存。
2.具有多樣性》複製因子。
上面的多樣性是指副本集中的位置數量。
上面的要點3確保目標副本集的多樣性不會減少（或者如果減少，它就不會低於複製因子）。
進行交換的單個迭代會考慮所有(n choose 2)副本集組合，其中副本集n的數量為。這些迭代將繼續進行，直到無法進一步改善所有副本集的多樣性之和為止（整個迭代都沒有找到交換物件）。
例如，考慮以下我們擁有儲存的情況：
rack1: s1 s2 s3
rack2: s4 s5 s6
rack3: s7 s8 s9
rack4: s10 s11 s12 s13
最初副本集的分配：
cs1: s1 s5 s9
cs2: s2 s6 s10
cs3: s3 s7 s11
cs4: s4 s8 s12 s13
如果儲存s6被刪除，步驟2之後（將儲存分配到相同的副本集id，直到大小達到rf），我們有了
cs1: s1 s5 s9
cs2: s2 s10
cs3: s3 s7 s11
cs4: s4 s8 s12
再通過新增剩餘儲存來填充空白點之後
cs1: s1 s5 s9
cs2: s2 s10 s13
cs3: s3 s7 s11
cs4: s4 s8 s12
交換之後（由於cs1和cs2之中cs2有兩個儲存來自與rack4）
cs1: s1 s5 s13
cs2: s2 s10 s9
cs3: s3 s7 s11
cs4: s4 s8 s12
這種交換策略可能無法實現最佳的多樣性，但會嘗試確保副本集中的每個位置都不同。
考慮用於副本集分配的儲存列表將是當前的實時儲存。實時儲存的計算方式與分配器檢測實時儲存的方式相同（但不會排除受限制的儲存。）如果儲存列表穩定且未更改3個心跳數（每個心跳聲都有），則會重新生成副本集。間隔10秒）。
副本集分配可以作為原型保留在分布式儲存層中。最小化資料移動的副本集策略要求保留副本集（它要求先前的狀態為全域性狀態並在重新啟動後仍然有效）。群集中最低的活動節點id將是管理（持久）副本集。其他節點將定期（每10s）快取持久化的副本集，並將其用於重新平衡。
僅當儲存列表更改時，副本集才會重新生成（並保留）。在穩定狀態下，所有節點將定期讀取持久化的副本集，而無需重新生成並持久化新的副本集。
對於rf = 3，群集可以容忍每個副本集中乙個節點的故障。例如，在最佳情況下（對於rf = 3），乙個100個節點的群集可以承受33個節點的同時故障，而不會造成任何資料丟失。
範圍需要重新平衡以包含在副本集中。
hubble目前使用兩種範圍再平衡器：
1.複製對略
2.儲存池管理器
1.確定範圍內要用於新副本的儲存
2.當範圍超過所需副本數時要刪除的副本
3.副本必須從乙個儲存移動到另乙個儲存，該範圍的結果得分將更高
1.區域約束：在某些區域中具有某些表的約束
2.磁碟已滿：檢查儲存是否太滿
3.多樣性分數差異：多樣性分數與該範圍內存在的副本數所處機架的數量成正比。它基於地點的nc2多樣性分數，其中n是副本的數量。
4.收斂分數差異：收斂分數用於避免移動shard，移動shard的移動會導致shard的統計資訊偏離全域性平均值。
5.平衡分數差異：平衡分數是節點的標準化利用率，當前它考慮範圍的數量，平衡分數較低的節點是首選。
6.範圍計數差異：範圍計數較低的儲存是首選。
為了將shard重新平衡到副本集中，新的副本評分將新增到分配器中。區域約束和磁碟填充比副本集得分具有更高的優先順序。
由於副本集分配考慮了多樣性，因此可以將其優先順序置於多樣性得分之上。
如果滿足一下條件，則該副本集得分較高：
1.shard完全包含在副本集中
2.shard所在的副本集未得到充分利用。我們希望每個副本集均被載入。如果shard在拷貝集中完全包含x我們應該完全移動到副本集y中。如果副本集y的節點有更低的負載，更多的可用磁碟空間等情況。
分布式專題 分布式鎖
在傳統的單體應用架構中,遇到併發安全性問題時我們可以通過同步鎖synchronized,同步 塊,reentrantlock等方式都可以解決,但隨著業務的發展，單體應用架構不能滿足龐大的使用者請求量，於是分布式系統應用而生，在分布式系統中,由於每個系統都執行在不同的伺服器上，有著不同的jvm,所以j...
HDFS技術之副本機制（五）
hdfs上的檔案對應的block儲存了多個副本，且提供容錯機制，副本丟失或者宕機都會自動恢復，預設儲存3份副本，下面給出乙個副本擺放的架構圖。第一副本 放置在上傳檔案的datanode上 如果是集群外提交，則隨機挑選一台磁碟不太慢 cpu不太忙的節點。第二副本 放置在與第一副本不同的機架的節點上。第...
分布式技術
資料分布式模式 利用多台計算機並行處理多個請求，在相同的時間內完成更多的請求，解決單機效率瓶頸問題。多集群出現的問題如下 資源 乙個系統提供正常能力需要占用的硬體資源 可用性和可擴充套件性 不同分布式系統的指標 選舉流程 優點 演算法複雜度低，選舉快，簡單易實現 缺點 每個節點需要儲存全域性節點訊息...