Microsoft Sync Framework 系列（六）：微软同步框架中的知识（Knowledge）

在上一部分，我们说过 Knowledge 是 Microsoft Sync Framework 中的元数据（Metadata），该元数据用于描述应用到复本（replica）的所有更改，这些更改要么是直接的，要么通过同步。
MSF 使用 Knowledge 来枚举更改和冲突检测。
change enumeration 和 conflict detection 一般是通过比较两个复本中的同一item的版本，典型的做法是destination将所有需要同步的item的版本信息发送到source。这样需要维护和传输的元数据是与复本中要同步的item成比例的（例如，数据库表中所有记录的版本信息都要维护并传递）。MSF 引入 Knowledge 的概念，它将一个复本的当前更改信息以十分压缩的形式保存在内部数据结构中。（这里比较难于理解，后面会通过例子说明）。
Knowledge最大的特点是它用尽可能紧凑的数据来支持更改枚举和冲突检测，因此提升同步效率；当然针对于个体的同步元数据也是必需的，per-item 同步元数据用于记录item什么时间在什么地方被修改（per-item sync metadata - when and where a given item was changed. ）。

知识操作（Knowledge Operations）

为了支持更改枚举、冲突检测等功能，MSF API提供了对知识的操作（Knowledge Operations），基本上这些Operation是一些离散数学的概念，这里介绍主要的四个：

包含（Contains）- Change containment check

确定一个具体 Knowledge 中是否包含指定的 Version（replica key 和 tick count）。也就是确定拥有该知识的复本是否应用了该更改（whether the replica that owns this knowledge has applied this change）。

确定给定的Knowledge是否知道该更改（whether a given knowledge instance knows about this change ）。

联合（Union）- Knowledge combining
从两个知识对象中构造一个新的Knowledge，新构造的Knowledge至少包含了原先任何一个knowledge中的所有更改。（merges information from another sync knowledge into the current one。）
投影（Project）- Subset
获取原knowledge中特定item set的knowledge（取出特定的子集形成新的knowledge）。
排除（Exclude）- Item exclusion

Project的非操作，去除item set对应的knowledge后形成新的knowledge。（indicate in the sync knowledge that it doesn't know anything about the item specified. This operation is used during change application to create exceptions in the knowledge.）

更改枚举（Change Enumeration）

利用 Knowledge 枚举更改（Change Enumeration）的过程是确定原复本（source replica）的哪些更改是目标复本（destination replica）所不知道的。

1. destination Provider 将其当前知识（current Knowledge）发送到 Source provider，因此源（source）获得了目标（destination）的 Knowledge（destination的当前状态）；

2. Source Provider 遍历 Source replica 中的所有 items ，并且执行下列操作：

a. 利用Contains操作判断从 destination 发送过来的 knowledge 信息里是否包含从 source 中枚举出的当前 item 的版本信息。

b. 如果没有，该 item 就要被发送到 destination provider。

也就是说，对于 source 中的每一个 item ，利用 Contains 操作如果 destination 的 Knowledge 中没有 contains 该 item 的版本信息，则认为该 item 在 source 已经修改需要发送到destination。

For the purposes of the change enumeration the sync solution should return a change to the sync destination when destination's knowledge doesn't contain the change.

change enumeration 举例：

假设一个文件同步的例子，A 是 source （初始化同步的一方），B 是 destination 。

目录中的每个文件都是一个被跟踪的数据项（item），用In来表示（例如I1，I2，I3等），根据我们前面元数据部分介绍的，一个文件被创建时（I1），I1 的元数据如下：

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I1	1	A	1	A

复习一下上节的 Version 元数据：

创建复本号（Creation Replica ID） + 创建计数器（Creation Tick Count） = 创建版本（create version）

更新副本号（Update Replica ID） + 更新计数器（Update Tick Count） = 更新版本（updated version）

当该文件被修改时，新的元数据（Metadata）会是如下样子：

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I1	5	A	1	A

这就是所谓的 per-item sync metadata ，记录了该文件(I1)在逻辑时钟 5 时（when）在 Replica A （where）被修改。
我们可以看到更新计数器（Update Tick Count）由 1 变到了 5 ，这可以让我们更加清楚的认识 tick count ，tick count 在一个 replica 中是正态递增的（不会重复的），它代表了修改的逻辑时间，例如从 1 变到 5 可能说明中间有其他文件被修改，它们被修改时的 tick count 可能是 2，3，4 。

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I2	3	A	2	A
I3	4	A	4	A
I1	5	A	1	A

tick count 是 Knowledge 的核心，在 MSF 中，在一切良好的情况下 Knowledge 只需要记录 replica ID 与 当前最大的 tick count （replica knew changes up-to）就可以，因此现在：

A （source）的 Knowledge = A5 。
对于 destination Replica B 来说，元数据可能是这个样子：

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I104	2	B	1	B
I105	4	B	3	B

B （destination）的 Knowledge = B4 。
如果此时进行同步， destination（B）将它的 Knowledge （B4）发送到 source（A），因为 B 中的 Knowledge 没有包含任何 A 的信息，所以 source 判断出 destination 一点也不知道 A 的存在，因此 source 应该把所有的文件的版本信息都发送到 destination 。

Replica A’s Change Batch

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I2	3	A	2	A
I3	4	A	4	A
I1	5	A	1	A

注：对于 change enumeration 也可以通过直接执行查询得到，但是 Knowledge 使 change enumeration 更快捷。

变化发送（Change Sending）

Change Sending 是分批把 source 的更改发送到 destination 的过程，对每一批（batch）都发送下列信息：

变化本身（The changes themselves）
made-with knowledge：source replica 构建完 change batch 后的 knowledge，made-with knowledge 用于检测冲突，它代表了完成这些改变后 source 的 knowledge（What did you know when you made these changes）。 【The made-with knowledge is the knowledge of the source replica when the change batch was made】
learned knowledge：source replica 当前的 Knowledge 与本批已经发送的 item 的投影（project），同时还有记录下来的冲突。Learned knowledge 回答了：当我应用这些更改时我学到了什么（What will I learn when I apply these changes）。 【The learned knowledge is the knowledge that must be combined with the destination replica's knowledge and saved on the destination replica after the changes are applied】

发送例子：

对于上面例子，当 source （Replica A） 接收到 destination （Replica B） 的 knowledge 后利用这些 knowledge 确定哪些 verions 需要发送到 destination （B），所以现在的 made-with knowledge 如下：
当 destination 接受到这些 versions 信息并确定哪些 item 应该从 source 发送过来（注意 versions 和 items 的不同，首先发送的是 versions）。destination 同时利用这些信息（made-with knowledge）来判断是否有异常发生。确定以后，destination 请求 source 发送那些已经修改的 itmes ，在我们的例子中就是 I1，I2和I3。

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I2	3	A	2	A
I3	4	A	4	A
I1	5	A	1	A

接受到这些文件后，destination 把它们添加到自己的文件夹中，destination 从 source 的同步完成。B 现在的样子：

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I104	2	B	1	B
I105	4	B	3	B
I2	3	A	2	A
I3	4	A	4	A
I1	5	A	1	A

然后，source 和 destination 互换后再次执行这个过程，整个同步完成，同步完成后，source 和 destination 的文件一致，A 的版本信息与 B 一样，如上。

同时它们的 knowledge 也同步更新：

A （source）的 Knowledge = A5 ，B4。

B （destination）的 Knowledge = A5，B4 。

这时它们的 knowledge 也都是一样的，而且可以看出 knowledge 的数目是正比于参与同步的 replica 的数目的，例如这里是两个 replica ： A 和 B，knowledge 就有两个，如果还有一个 C，那同步后的 knowledge 就是三个了。

冲突检测（Conflict detection）

冲突检测的过程是找出那些对一个复本的操作（修改或删除）没有被及时的通知另一个复本，因此导致两个复本对同一条目都进行了本地更改。

也就是说一个程序在一个复本上进行修改后并没有及时同步到另一个复本，这时如果另一个复本也对该条数据进行修改，下次同步时就会发生冲突。

利用 knowledge 进行冲突检测：

如果 destination replica 中某个 version 没有包含在 source replica 的 knowledge 中（通过下面介绍的Contains操作）。（A change conflicts with the current state when the version on the destination replica is not contained in the knowledge of the source replica.）

if a destination version for an item or change unit whose change we're trying to apply is not contained by the source's made-with knowledge, this indicates that we have an independent update to an item or change unit done both on source and destination otherwise known as a conflict.
冲突例子：
继续前面的例子，如果这时 replica A 更新了 I2，这时 replica B 在没有与 A 同步前也修改了 I2，这时 A 和 B 的 version 信息和 knowledge 信息分别是：

On Replica A the item version table is updated to:

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I104	2	B	1	B
I105	4	B	3	B
I2	6	A	2	A
I3	4	A	4	A
I1	5	A	1	A

On Replica B the item version table is updated to:

Item	Update Tick Count	Update Replica ID	Creation Tick Count	Creation Replica ID
I104	2	B	1	B
I105	4	B	3	B
I2	5	B	2	A
I3	4	A	4	A
I1	5	A	1	A

A （source）的 Knowledge = A6，B4。

B （destination）的 Knowledge = A5，B5。
这时 A （作为 source） 与 B （作为 destination） 进行同步，略过上面例子里提到的一些过程，当 source 把 item versions 和 knowledge 发送到 destination 时，将在 I2 文件上执行下列步骤：

1. B （destination） 从 A 的 knowledge 中发现了 I2 被 A 修改：



2. B （destination） 同时发现 B 本身也修改了 I2 ，但是 A 不知道（not aware of）：



3. 冲突被检查了出来并应该被应用程序或者 provider 处理。
参考定义：

The knowledge encompasses all changes (in other words, versions of all items) which a particular sync endpoint knows about.

Knowledge is the metadata that describes all the changes that have been applied to a replica, either directly or though synchronization.

Sync knowledge is the compact representation of all the changes which a particular sync endpoint knows about which is used during change enumeration and conflict detection phases of the sync process.

we compress all sync versions in the sync endpoint into the single compact data structure which we call knowledge.The knowledge encompasses all changes (in other words, versions of all items) which a particular sync endpoint knows about.

参考：
Microsoft Sync Framework, Part 3: Sync Knowledge

Understanding Synchronization Knowledge

FLYabroad 标签: 微软同步框架, MSF, SyncFramework, 同步服务