TFS沒有采用目前流行的3副本策略，而是使用集群內(nèi)配置2個副本，并把數(shù)據(jù)同步到一個輔集群，輔集群同樣配置2個副本；這種方式對于實現(xiàn)異地機房容災很方便，輔集群的數(shù)據(jù)同步是由主集群的數(shù)據(jù)服務器在后臺發(fā)起的；目前主集群可讀寫，輔集群只讀，雙集群同時讀寫功能已開發(fā)完成，但沒有在線上使用。

由于數(shù)據(jù)同步到輔集群是異步操作，當某次讀文件的操作落到輔集群上時，可能該文件的同步尚未完成，此時在輔集群上讀不到數(shù)據(jù)，這個問題目前是通過失敗后在集群間重試來避免（迭代）；還有一種方式就是當輔集群發(fā)現(xiàn)文件不存在時，主動去輔集群同步（遞歸），同步完成后向用戶返回數(shù)據(jù)；這樣做邏輯雖然正確，但存在幾個問題：（1）在用戶的一個請求中，遞歸的從主集群同步文件數(shù)據(jù)，如果文件較大，會導致用戶請求超時；（2）將主輔集群間的同步協(xié)議復雜化了，當輔集群指定同步某個文件（而不是按主集群接收到請求的順序），會打亂同步時序邏輯，從而爆發(fā)一些問題；比如文件是經(jīng)過寫（A）、更新(B)等操作才到達目前的狀態(tài)，那么在同步到輔集群后，下次數(shù)據(jù)服務器（DS）重放日志同步時，寫操作（A）實際上變成了更新操作；另外TFS還支持用戶刪除、隱藏文件，這些操作組合跟寫組合到一起時，會產(chǎn)生更多微妙的問題。

主輔集群的所有副本，可能會發(fā)生一些數(shù)據(jù)不一致的問題，先討論下集群內(nèi)的不一致情況

某個數(shù)據(jù)服務器上內(nèi)存、磁盤錯誤可能導致數(shù)據(jù)出現(xiàn)變化，這個問題目前通過寫磁盤前檢查文件crc來避免；

寫多個副本只有master成功，其它slave副本都失敗；由于TFS的集群內(nèi)寫操作是多個副本強一致性的（理論上），出現(xiàn)這種情況，會向用戶返回失敗信息，用戶根本不知道這個文件的存在，這種不一致不會引發(fā)問題；

TFS刪除、隱藏操作在master副本上保證狀態(tài)正確，在slave副本上的狀態(tài)是不保證的；可能某個文件刪除了，但其在某些副本上依然存在；由于文件的更新只會有master完成再同步到slave副本上，所以文件即使在slave上存在但不會被更改了，同時用戶刪除了文件通常不會再訪問了，惡意用戶因為不知道該文件對應的TFS文件名，所以也訪問不到文件。

某個副本丟失，這個會有后臺的復制任務來完成副本的復制，以保證數(shù)據(jù)的安全。

對于集群內(nèi)的數(shù)據(jù)不一致，都有相應的處理措施，但集群間數(shù)據(jù)的維護是獨立進行的，相互間沒有影響，一旦出現(xiàn)主輔數(shù)據(jù)不一致的情況（出現(xiàn)幾率較小），沒有任何措施來處理。集群間數(shù)據(jù)對比工作主要目的在于發(fā)現(xiàn)集群間數(shù)據(jù)的不一致，并進行處理。

集群對比最簡單的方式就是逐個block進行對比（逐個文件的方式不現(xiàn)實），目前最大的集群使用的block數(shù)約為850w，獲取一個block上所有文件的信息（需要遍歷block）約50ms，一次全量對比的時間約5天（持續(xù)不間斷請求的理論值），如果每次都進行全量的對比顯然是不能接受的，必須引入增量式的檢查方案。

數(shù)據(jù)不一致主要出現(xiàn)在數(shù)據(jù)修改時，要實現(xiàn)增量式的對比，只需對比修改過的block即可，主要設計思想如下：

DS記錄修改的block。

增加checkserver收集DS修改的block信息并合并對比。

根據(jù)對比結果進行相應處理。

DS要記錄修改的block，須在改變block內(nèi)容的接口上增加hook，目前只在寫（包括更新）操作、以及塊復制、壓縮完成時增加hook，將修改block的id和修改時間記錄到一個map中（修改block的信息只記錄在內(nèi)存上，它在block副本對應的所有機器上都會記錄一份，這些修改信息即使丟失也不會對系統(tǒng)有影響，故不需要進行持久化存儲），當checkserver（簡稱CS）發(fā)送check請求時，DS將上次檢查到這次檢查間隔內(nèi)修改的block信息（文件數(shù)量、文件總大小等）回復給CS，CS將所有主輔集群上相同block的信息進行匯總并對比。

理論上DS每次返回block信息后，就可以將該段時間內(nèi)修改的block數(shù)據(jù)刪掉，但當集群DS數(shù)量很多時，如果CS在檢查過程中宕機，這個檢查過程是不能重現(xiàn)的(除非CS持久化從DS獲取到的block信息），即使block間有不一致的情況，也只能在block下次被修改的時候發(fā)現(xiàn)。據(jù)不完全統(tǒng)計，2T的盤約有2.3w左右的block，由于每個block的元數(shù)據(jù)只有12B，即使所有block都被修改，總的數(shù)據(jù)占用內(nèi)存也不會超過1M，對系統(tǒng)內(nèi)存使用的影響不大；故為了簡化CS，使其無狀態(tài)，DS hook的block修改數(shù)據(jù)是不刪除的。

CS的檢查是一個周期性執(zhí)行的任務，CS每次檢查從上次檢查后到本次檢查時間間隔內(nèi)的block，為了避免異步同步的影響（主集群上的寫，還沒有同步到輔集群），對每次檢查block的條件再加了一個限制，修改了并且超過指定時間（認為其已經(jīng)穩(wěn)定了，如5min，可配置）沒有修改，CS的檢查間隔、block的穩(wěn)定時間都是在CS上配置的，檢查的目標時間段也在CS上計算好傳至DS，避免修改配置項需要重啟DS。

CS收集到DS上修改的block信息后，對blockid相同的信息進行合并，最后從每個集群選擇version最高的block用于對比，通過對比發(fā)現(xiàn)主輔集群上block數(shù)據(jù)不一致時就需要對該block進行同步（該任務與檢查分開進行）。關鍵問題是如何認定主輔集群上block不同？最簡單的方法是，直接對比block上的文件數(shù)和文件總大小，對于在某一個block上不存在的block，則需要從另一個集群同步過去。但這個策略存在很多問題：

可能某次檢查，某個修改的block在主集群上穩(wěn)定了，在被集群還沒穩(wěn)定（且很快就會變成穩(wěn)定狀態(tài)），這時CS就認為這個block需要同步到備集群，而這個同步過程顯然是多余的。最開始跟@daoan討論的方案是增加一個overlap的檢查時間（2次檢查有一段重疊時間），但這樣就無法區(qū)分block需要同步還是剛好出現(xiàn)上述的臨界狀態(tài)。

針對某個DS的檢查請求，由于網(wǎng)絡等原因失敗，但實際上一切正常，這時CS也會發(fā)現(xiàn)block在某個集群上不存在，認為其需要同步，而這個同步過程同樣是多余的。

block可能在某個集群上發(fā)生了壓縮，或是某個文件在主集群上寫后，在寫同步前又刪掉了，這時直接根據(jù)index中的文件數(shù)和文件總和來對比block是不準確的。

從上面的3點可以看出，通過獲取hook的block，并從index獲取文件信息是不準確；要想真正判定兩個block數(shù)據(jù)不一致，必須排除掉block中被刪除的文件，這就需要遍歷整個block（開銷比遍歷index大很多）；最終的實現(xiàn)方案是：首先CS執(zhí)行一次檢查，收集block信息，并對比進行一次初篩，對于數(shù)據(jù)可能不一致的block，將其加入到一個recheck list中，最后對于recheck list中的所有block，進行更細節(jié)的對比（排除刪除文件的影響），如果發(fā)現(xiàn)block數(shù)據(jù)仍不同，則認為需要同步。

最后，集群同步工具根據(jù)CS的檢查結果，對需要同步的block進行同步，使整個集群達到一致的狀態(tài)。

轉載于:https://www.cnblogs.com/yunnotes/archive/2013/04/19/3032316.html

總結

以上是生活随笔為你收集整理的TFS集群数据对比的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。