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

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

主輔集群的所有副本，可能會發生一些數據不一致的問題，先討論下集群內的不一致情況

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

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

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

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

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

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

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

DS記錄修改的block。

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

根據對比結果進行相應處理。

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

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

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

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

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

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

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

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。