在本篇博客中，我們將詳細的了解和學習通用的元數據模型以及它的組件，當然，我們也會討論Sync Framework如何使用元數據來同步不同的數據存儲和副本。并以一個文件同步實例來講述了Microsoft Sync Framework的同步流程。

Microsoft Sync Framework元數據和同步流程

元數據(Metadata)

Microsoft Sync Framework為脫機和協作的應用程序、數據存儲和設備提供了一個完整的同步平臺，而不用考慮如下限制：

• 同步的數據類型
• 數據存儲的類型
• 傳輸協議
• 網絡拓撲比如點對點或客戶端-服務器拓撲

相反，Sync Framework通過一個通用的元數據模型來允許Sync Framework完成下面的工作：

• 實現同步過程的互操作性
• 減少在兩個參與同步的data stores之間的數據傳輸量
• 使同步獨立于任何網絡拓撲、數據類型、數據存儲和傳輸協議

在本篇博客中，我們將詳細的了解和學習通用的元數據模型以及它的組件，當然，我們也會討論Sync Framework如何使用元數據來同步不同的數據存儲和副本。

什么是元數據

從字面意義上看，元數據是“關于數據的數據”。而Microsoft Sync Framework中使用的元數據包含兩種類型：

• 副本元數據（Replica metadata）
• 項目元數據（Item metadata）

在Sync Framework中，副本通常是指真正的數據存儲。比如，如果我們在同步兩個數據庫，那么每個數據庫都是一個副本，副本可以包含項目。比如，對于數據庫，一個項目可以是表中的一條記錄。

要同步兩個副本， Sync Framework要求同步提供程序使用通用的元數據模型，這也是Sync Framework的核心所在。Sync Framework提供程序使用元數據來檢測副本的更新，但是提供程序本身并不要求理解同步元數據（這是Sync Framework運行時的職責所在，它會幫助提供程序來解析同步元數據）。

同步提供程序通過運行時來查詢元數據，以發現某個副本自上一次同步以來所作的數據更新。同步元數據還幫助完成對沖突的檢測和處理。沖突是指在同步過程中，同一項目在兩個副本中被同時修改。同步提供程序使用元數據來判斷一個項目是否處于沖突狀態并使用元數據來解決沖突。同步元數據還會被Sync Framework運行時使用，以解決通常的同步問題比如網絡失敗、沖突數據和應用程序錯誤。

元數據存儲（Metadata Store）

你可能會對元數據存放在何處感到好奇，實際上，元數據可以存放在任何地方：一個文件、一個單獨的數據庫或參與同步的副本上。我們唯一需要保證的就是該元數據存儲是可以通過編程來進行訪問的。Sync Framework通過調用同步提供程序的不同方法來獲取和更新元數據。在實現自己的元數據存儲時，我們需要在相應方法被執行時返回和修改我們的元數據。

但多數情況下，我們會把對元數據進行操作的任務托管給Sync Framework運行時，這是因為Microsoft Sync Framework 提供一個以 SQL Server Compact Edition 為基礎的完整元數據存儲實現，如下圖所示。該存儲并非必要，但使用它意味著您不必擔心如何存儲同步元數據。

使用內置的元數據存儲還是自定義的元數據存儲，取決于創建同步程序的開發人員。但使用內置的元數據存儲意味著您不必擔心如何存儲同步元數據。

同步元數據組件

用于數據存儲的元數據可以分為三個主要組件：

• 版本（Version）
• 知識（Knowledge）
• Tombstones

版本（Version）

同步版本和副本中的項目相關聯：該信息記錄了項目在何時何處被創建和發生的變化，以及與該項目關聯的項目ID。比如在數據庫同步中，同步的數據庫可以成為副本A和副本B。一個項目可能是數據庫中的一個表，或表中的以條記錄，甚至是表中某行的一列。

當項目發生更改時，存儲的有關該更改的信息將包括創建版本和更新版本。這些版本包含兩個組件：

• 滴答計數 ：它是一個在整個源副本范圍內使用以唯一標識一個更改的邏輯時鐘
• 副本ID：它用于唯一標識發生更改的數據存儲。

當首次創建項目時，創建版本與更新版本相同。對該項目的后續更新修改的只是更新版本。

舉個例子，假如參與同步的副本A中Customer表的數據如下：

假設我們使用表中ID字段作為項目ID，那么表中記錄的版本信息可以用下表來表示：

記錄項目版本的過程也叫更改跟蹤（change tracking）。要實現更改跟蹤，同步提供程序需要為副本中任何時候的修改項目更新其同步版本。更改跟蹤（版本）的實現主要有兩種方式：

• 內聯跟蹤：

在這種方法中，版本的修改在副本中的項目被修改時發生。這種方法通常用在我們可以將修改版本信息的方法嵌入到副本本身時，以數據庫為例，我們可以使用觸發器在更新行之后立即更新更改跟蹤表。

• 異步跟蹤：

在這種方法中，將運行外部進程來掃描更改。發現的任何更新將添加到版本信息當中。該進程可能是定期執行進程的一部分，或者它可能在同步之前執行。該進程通常用于當沒有內部機制能夠在項目更新時自動更新版本信息的情況中（例如，無法在更新流程中增加版本更新邏輯）。檢查更改的常用方式是存儲項目的狀態，并將存儲的狀態與項目當前狀態進行比較。例如，可檢查從上次同步起，最后寫入時間或文件大小是否發生變化。

知識（Knowledge）

知識是副本能夠感知的數據更改的精簡表示。版本和項目相關聯，而知識則是和sync scope（同步作用域）相關聯。知識包含了在一個副本上直接或間接所作修改的信息。同步提供程序通常不會直接使用知識，取而代之的是，Sync Framework運行時會調用提供者的方法來操作副本的知識。知識的目的在于使同步更加有效，因為它有助于限制在副本之間發送的信息量。當版本信息更新時，用于數據存儲的知識也隨之更新。

提供程序使用副本知識的目的有：

1. 枚舉更改：確定另一個副本沒有感知的更改。
2. 檢測沖突：確定哪項操作是在不了解彼此知識的情況下做出的。

一個副本的知識由副本ID和副本中最大的滴答計數組合而成，以上面的數據庫同步為例，包含Customer表的副本A的知識為A2。

Tombstones

每個副本還必須為每個刪除的項目維護tombstone 信息。如果不跟蹤刪除信息，提供程序將無法告知某個項目（如文件）已被刪除。在這種情況下，提供程序無法將更改版本信息發送至其他提供程序。Tombstone 必須包含以下信息：

• 全局 ID： 用于在所有副本中唯一確定 tombstone 項目的副本 ID 和滴答計數。
• 刪除版本： 與 tombstone 項目關聯的更新版本
• 創建版本： 最初創建項目時關聯的副本 ID 和滴答計數

因為 tombstone 日志中的信息將隨時間增加，所以有必要創建一個進程定期清理該存儲。清理 tombstone 數據能夠節省空間并且有助于改善同步性能。Microsoft Sync Framework 支持對tombstone 信息的管理。

 

同步流程

了解了同步元數據，我們就可以來學習同步流程了。發起同步的副本稱為源 而源所連接的副本稱為目標。本文接下來的部分將介紹下圖所示的同步流程。對于雙向同步，將執行此進程兩次，第二次迭代時會交換源和目標。

1. 發起同步會話

在這一階段將建立同步會話，從而創建了從源到提供程序的鏈接。

2. 目標準備并發送知識

如前所述，每個副本都會存儲其自身的知識。存儲在目標端的知識將傳遞到源。

3. 目標知識用于確定要發送的更改

在源端，會將剛剛收到的知識與本地項目版本進行比較，以確定目標端尚不了解的項目。值得注意的是，發送的版本并不是實際的項目，而是每個項目上次發生更改的位置摘要。

4. 更改版本和源知識發往目標端

當源準備好所需的更改版本列表之后，這些版本將傳輸到目標端

5. 檢索更改項目的本地版本并與源版本和知識進行比較

目標端使用這些版本準備源需要發送的項目列表。目標還使用該信息檢測是否存在限制沖突。限制沖突是指違反了項目限制，如文件夾關系或文件系統中同名數據的位置。

6. 檢測并解決或推遲沖突

基本上，如果在兩次同步期間對兩個副本上的相同項目進行更改就會發生沖突。在 Microsoft Sync Framework 運行時中，當其中一個副本的更改版本不包含另一個副本更改的知識時便會檢測到沖突。   將在下面的“沖突示例”部分中介紹了說明該檢測過程如何工作的更加詳細的示例。

副本可以自由實施各種策略，解決同步拓撲間發生沖突的項目。下面列舉了一些常用的沖突解決策略：

• 源獲勝： 當檢測到沖突時，總是采用源副本所做的更改。
• 目標獲勝： 總是采用目標副本所做的更改。
• 合并： 將源副本和目標副本所做的更改合并在一起。庫存統計可能是一個您希望將兩個副本的值合并（求和），而不是選取其中一個作為正確值的例子。
• 記錄沖突： 記錄或推遲沖突。

7. 目標向源請求項目數據

在這一階段，目標已經確定需要在源中檢索的項目，并將請求發送到源。

8. 源準備并發送項目數據

源接收到項目數據請求，并準備要傳輸到目標的實際數據。如果要跟蹤的項目是數據庫中的一行，則將發送該行。如果項目是文件夾中的文件，則將傳送該文件。

9. 項目應用到目標中

目標接收并應用項目。如果在此過程中出現任何錯誤（如網絡斷開），則該項目將被標記為異常，并在下次同步期間進行更正。從源接收的知識將添加到目標知識。

 

同步示例

通過使用前面介紹的同步流程，我們將實際操作一次文件同步示例，該示例將說明 Microsoft Sync Framework 如何通過元數據來枚舉更改并最終應用項目數據。在本例中有兩個副本：副本 A 和副本 B。副本 A 啟動與副本 B 的同步（即副本 A 是源而副本 B 是目標）。假定我們希望同步兩個副本間的文件。要跟蹤的項目是文件夾中的一個文件，表示為 In （例如，I1, I2, I3…）。創建新文件時 (I1) 與該文件相關聯的元數據應更新如下：

如果文件再次更新，版本表應如下所示：

在上述示例中，更新滴答計數設置為 5，這是由于用于滴答計數的邏輯時鐘在整個源內發揮作用，即：滴答計數 2-4 已用于副本中其他項目的更改。

例如，在下面的圖例中，跟蹤的副本中有兩個附加的項目 I2 和 I3 。您可以看到，隨著創建更多的項目，版本信息將變得越來越多。Microsoft Sync Framework 不要求存儲以前的更新版本。它只需要了解最新的更新版本。

如果采用該副本的當前項目狀態，我們可以把副本 A 的知識表示為：

副本 A 知識 = A5

如前所述，知識是副本能夠感知的數據更改的簡約表述。在本例中，A 是分配給該副本的唯一 ID，而 5 是當前滴答計數，它使副本能夠了解當前的最大變化個數。如果該副本已經與任意其他副本進行同步，則我們還將在該列表中看到這一知識。

在副本 B 上可能也有很多文件。該副本如下所示：

副本 B

副本 B 的當前知識為：

副本 B 知識 = B4

此時我們選擇開始在兩個副本之間進行同步。副本 A 將成為源（啟動同步的副本），副本 B 將成為目標。

同步過程中，目標向源發送其知識。如前所述，兩個副本的知識如下：

副本 A 知識 = A5

副本 B 知識 = B4

源（副本 A）收到該知識并使用它來確定將哪個版本發送到目標。由于副本 B 不了解在副本 A 中的任何項目，所以它將發送所有內容。在本例中，副本 A 將包含以下版本。

副本 A 的更改批次

目標接收這些版本并對其進行枚舉以確定需要從源請求哪些項目。它還使用該信息確定是否存在任何沖突（例如，在兩個副本上更新了相同的文件）。

完成后，目標請求源發送它沒有感知的項目。在本例中，副本 A 將發送與 I1、 I2 和 I3。

目標收到這些文件并將其添加到自己的文件夾中。副本 B 的項目現在將包含從副本 A 接收到的項目。

副本 B – 已更新項目表

本次同步結束后，該過程將再執行一遍，這次源將成為目標而目標成為源。這使得副本 A 能夠接收到在副本 B 上創建或更改的任何文件（I104 和 I105）。

同步完成后，兩個副本上都應包含以下更新知識。

副本 A 知識 = A5， B4

副本 B 知識 = A5， B4

沖突示例

繼續前面的示例，兩個副本現在已經“同步”，并且每個項目標版本如下：

  

類似地，兩個副本的知識如下：

副本 A 知識 = A5， B4

副本 B 知識 = A5， B4

此時，兩個副本都決定更新相同的文件（項目 I2）。

在副本 A 上，該項目標版本表更新為：

在副本 B 上，該項目標版本表更新為：

兩個副本的知識也更新為：

副本 A 知識 = A6， B4

副本 B 知識 = A5， B5

此時，副本 A 啟動與副本 B 的同步。跳過源向目標發送項目版本和知識這一步，為項目 I2 執行下列步驟。

1. 副本 B 看到項目 I2 新更改，其為：

2. 副本 B 查看從副本 A 收到的知識（A6、B4）并確定副本 A 不了解由副本 B 對相同項目所做的更改：

3. 將檢測到沖突并傳給應用程序或提供程序進行處理。

如前所述，應用程序能夠選擇如何處理沖突或延后處理。如果沖突延后處理，則在其解決之前它將在每次同步時重復出現。一旦沖突得到解決，則下一次同步時，原始副本將接收更新后的值。

在系列博客的第一部分基礎篇中，通過3篇文章我們了解了同步的背景知識、同步的優點以及Microsoft Sync Framework對同步的實現；講述了Sync Framework的核心組件和系統架構、各種同步參與方類型；詳細的討論了Sync Framework元數據的作用、同步流程，并實例展示了運行時是如何使用元數據來完成同步的。至此，我們對于Sync Framework的理論基礎應該有了一個比較好的理解和掌握，接下去，我們將會詳細的討論使用具體的同步提供程序(Synchronization Providers)來同步各種數據，如數據庫、文件、Web Feeds...