這篇文章主要講解了“Raft算法在分布式存儲系統(tǒng)Curve中的方法教程”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Raft算法在分布式存儲系統(tǒng)Curve中的方法教程”吧！

成都創(chuàng)新互聯(lián)服務項目包括興平網站建設、興平網站制作、興平網頁制作以及興平網絡營銷策劃等。多年來，我們專注于互聯(lián)網行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網行業(yè)的解決方案，興平網站推廣取得了明顯的社會效益與經濟效益。目前，我們服務的客戶以成都為中心已經輻射到興平省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！

Raft一致性算法介紹

Raft算法中，有Leader、Follower、Candidate三種角色，它們之間的轉換關系如下圖：

在同一時刻，只能有一個Leader，當選Leader后到發(fā)起下一次選舉稱為一個任期（term），Leader負責通過心跳向follower保持統(tǒng)治，并同步數據給Follower。Follower發(fā)起選舉的前提是超時未收到Leader的心跳。

Leader競選：RAFT是一種Majority的協(xié)議，即贏得選舉的條件是獲得包括自己以內的大多數節(jié)點的投票。Follower超時未收到Leader的心跳，則會成為Candidate，發(fā)起新一輪的選舉。每個節(jié)點在每個Term內只能投一次票，且服從先到先服務原則。為了避免多個Follower同時超時，raft中的選舉超時時間是一個固定時間加一個隨機時間。

日志復制：在任期內，Leader接收來自client的請求，并將其封裝成一個日志條目（Raft Log Entry）把它append到自己的raft log中，然后并行地向其它服務器發(fā)起AppendEntries RPC，當確定該entry被大多數節(jié)點成功復制后（這個過程叫commit），就可以執(zhí)行命令（這一步叫apply），并返回給client結果。log entry由三個部分組成，分別是：1、log index，2、log所屬的term，3、要執(zhí)行的命令。

配置變更：在Raft中，稱復制組有哪些成員稱為配置，配置并不是固定的，會根據需求增刪節(jié)點或異常情況下需要替換掉有問題的節(jié)點。從一個配置直接切換到另一個配置是不安全的，因為不同的服務器會在不同的時間點進行切換。因此Raft配置變更時，會先創(chuàng)建一個特殊的log entry Cold,new，這條entry被commit后，會進入共同一致階段，即新舊配置一起做決定。這時候，再生成一個Cnew的log entry，等這條entry被commit后，就可以由新配置獨立做決定了。

安裝快照：Raft快照指的是某個時刻保存下來的系統(tǒng)狀態(tài)的集合?？煺沼袃煞矫娴淖饔茫阂粋€是日志壓縮，打了快照之后，在此時刻之前的log entry就可以刪除了。另一個是啟動加速，系統(tǒng)起來的時候不需要重新回放所有日志。當Leader同步日志給Follower的時候，發(fā)現(xiàn)所需的log entry已經被快照刪掉了，即可通過發(fā)送InstallSnapshot RPC給Follower進行同步。

Raft算法在Curve中的應用

Curve系統(tǒng)是一個分布式存儲系統(tǒng)，在Curve系統(tǒng)中，數據分片的最小單位稱之為Chunk，默認的Chunk大小是16MB。在大規(guī)模的存儲容量下，會產生大量的Chunk，如此眾多的Chunk，會對元數據的存儲、管理產生一定壓力。因此引入CopySet的概念。CopySet可以理解為一組ChunkServer的集合，一個Copyset管理多個Chunk，多副本間的同步和管理已Copyset為單位組織。ChunkServer，Copyset和Chunk三者之間的關系如下圖：

Curve copyset選用了braft作為一致性協(xié)議的組件，使用方式為multi-raft，即同一個機器，可以屬于多個復制組，反過來說，一個機器上，可以存在多個raft實例?；赽raft，我們實現(xiàn)了副本間數據同步，系統(tǒng)調度，輕量級raft快照等功能，下面一一詳細介紹。

副本間數據同步

CopysetNode在ChunkServer端封裝了braft node，具體關系如下圖所示：

Curve client發(fā)送一個寫請求時，三副本情況下的具體的步驟如下：

1. Client發(fā)送寫請求給Leader ChunkServer。

2. ChunkServer收到請求，將請求封裝成一個log entry，提交給raft。

3. braft模塊在本地持久化entry的同時發(fā)送entry給其他副本（ChunkServer）。

4. 本地持久化entry成功，且另一個副本也落盤成功則commit。

5. commit后執(zhí)行apply，apply即執(zhí)行我們的寫盤操作。

在此過程中，用戶的數據和操作，通過braft中的log entry的方式在副本間傳遞，進行數據同步。在三副本場景下，向上層返回的時間取決于兩個較快的副本的速度，因此可以減少慢盤的影響。對于較慢的那個副本，leader也會通過無限重試的方式同步數據，因此在系統(tǒng)正常工作的前提下，最終三個副本的數據是一致的。

基于Raft的系統(tǒng)調度

在Curve中，ChunkServer定期向元數據節(jié)點MDS上報心跳，心跳中除了ChunkServer自身的一些統(tǒng)計信息，還包含ChunkServer上面的CopySet的統(tǒng)計信息，包含它的leader，復制組成員，是否有配置變更執(zhí)行中，配置的epoch等。MDS基于這些統(tǒng)計信息，會生成一系列的Raft配置變更請求并下發(fā)給Copyset的leader所在的ChunkServer。

下發(fā)配置變更

Curve ChunkServer會定期向MDS上報心跳。MDS調度下發(fā)配置變更是在心跳的response中完成的。上報心跳的過程如下圖：

心跳是定時任務觸發(fā)的，ChunkServer除了上報一些自己的容量信息等統(tǒng)計信息外，還會上報Copyset的一些信息，比如leader，成員，epoch，是否有進行中的配置變更等。

MDS在心跳response中下發(fā)配置變更的過程如下圖：

ChunkServer收到response后，解析其中的配置變更信息，并下發(fā)給每個Copyset。

Curve epoch

epoch同步配置。MDS生成的調度信息，是由后臺定時任務觸發(fā)，并在ChunkServer下一次請求到來時在response中下發(fā)的，因此MDS下發(fā)的配置變更有可能是過期的。為了實現(xiàn)MDS和ChunkServer之間的配置同步，Curve引入了epoch機制，初始狀態(tài)，epoch初始為0，每進行一次配置變更（包括leader變更），epoch都會加一。當MDS中的epoch等于ChunkServer端的epoch時，即將下發(fā)的配置變更才被認為是有效的。epoch與term有何區(qū)別？term用于表示Leader的任期，即只跟選舉有關，而epoch是與配置變更相關的，也包括了Leader選舉這種情況。

epoch的更新。epoch是在ChunkServer端更新的，braft在實現(xiàn)上提供了一個用戶狀態(tài)機，在braft內部發(fā)生變化，比如apply，出錯，關閉，打快照，加載快照，leader變更，配置變更等時會調用用戶狀態(tài)機中對應的函數。Curve copyset通過繼承的方式實現(xiàn)這個用戶狀態(tài)機來完成與braft的交互，epoch是在on_configuration_committed函數中加一的。在braft中，當Leader變更的時候會把當前的配置再提交一遍，因此在on_configuration_committed中增加epoch即可保證在配置發(fā)生變化或者Leader變更時epoch順序遞增。

epoch的持久化。在MDS端，epoch隨著CopySet的其他信息一起持久化在etcd中。ChunkServer也對epoch進行了持久化，但是ChunkServer中持久化epoch并不是每次epoch發(fā)生變化都需要持久化的。這是利用了raft的日志回放和快照功能?？紤]以下兩種情況：

1. 假設raft沒有打快照，那么就不需要持久化epoch，因為所有操作日志，包括配置變更的entry都已持久化，當服務重啟的時候，回放這些日志的時候會依次再調用一遍on_configuration_committed，最后epoch會恢復到重啟前的值。

2. 當raft有快照時，打快照前的entry都會被刪除，就不能通過上面的方式回放，因此必須要持久化。但我們只需要在打raft快照時持久化epoch的當前值即可。這樣當系統(tǒng)重啟的時候，會先安裝raft快照，安裝后epoch恢復到快照時的值，再通過執(zhí)行后面的log entry，最終epoch恢復到重啟前的值。在打快照時更新epoch是在on_snapshot_save函數中完成的。

Raft輕量級快照

上面介紹Raft算法的時候介紹過，Raft需要定時打快照，以清理老的log entry，否則Raft日志會無限增長下去。打快照的時候需要保存系統(tǒng)當前的狀態(tài)，對于Curve塊存儲場景來說，系統(tǒng)狀態(tài)就是Chunk當前的數據。直觀的方案是將打快照時刻的全部chunk拷貝一遍備份起來。但是這樣有兩個問題：

1. 空間上要多出一倍，空間浪費非常嚴重。

2. Curve默認打快照的間隔是30分鐘一次，這種方案下會有頻繁的數據拷貝，對磁盤造成很大的壓力，影響正常的IO。

因此，Curve中使用的Raft快照是輕量級的，即打快照的時候只保存當前的Chunk文件的列表，不對Chunk本身做備份。具體流程如下：

這樣操作，F(xiàn)ollower下載到的chunk文件不是打快照時的狀態(tài)，而是最新的狀態(tài)，在回放日志的時候，會把這些新數據再寫一遍。但這對于我們的場景是可以接受的，因為底層都是覆蓋寫是冪等的，即寫一次和寫多次結果是一致的。

感謝各位的閱讀，以上就是“Raft算法在分布式存儲系統(tǒng)Curve中的方法教程”的內容了，經過本文的學習后，相信大家對Raft算法在分布式存儲系統(tǒng)Curve中的方法教程這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！

網頁題目：Raft算法在分布式存儲系統(tǒng)Curve中的方法教程
當前路徑：http://aaarwkj.com/article42/ipochc.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供移動網站建設、手機網站建設、服務器托管、網站收錄、小程序開發(fā)、搜索引擎優(yōu)化

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)