更改跟踪技术概述

更改跟踪机制有几种不同的方式：

• 应用程序可以跟踪单个对象的单个属性的变化，也可以跟踪域中所有对象的变化，等等。 如果机制符合应用程序的要求，应用程序就会收到最少的无关数据，从而提升性能。

• 及时性：应用程序在每次发生更改时都会收到通知，也可以在几分钟或几小时内收到变化的净影响通知。

  处理不那么及时的数据可能会更有效率，因为多个更改可以被合并为一个更改。 例如，如果一个属性在一小时内发生了三次更改，那么应用程序就只会收到一次属性更改的通知，而不是三次。

  在考虑及时性时，要考虑复制延迟的影响。 源于一个域控制器的更新不会立即复制到另一个域控制器。 如果要求比预期的复制延迟好得多的更改跟踪及时性，这通常不会给应用程序带来真正的好处。

• 轮询与通知：通过轮询，应用程序会定期向域控制器发出请求，以接收更改跟踪数据。 使用通知功能时，域控制器仅在发生更改时才会向应用程序发送更改。

  轮询的开销是显而易见的：应用程序可能会在没有发生重大事件的情况下请求更改跟踪数据。 通知的开销更为微妙。 服务器必须维护有关通知请求的数据，并必须参考这些数据来决定是否发送通知。 这会增大正常更新请求的开销。

• 表达应用程序的知识：持久性与临时性：每一种更改跟踪机制都必须包含某种方法，让保存被跟踪数据的服务器了解应用程序的知识状态，从而明确定义“更改”的概念。 例如，应用程序的知识状态可以表述为“更新了在时间 t 之前于 DC d 上发生的所有更改”。基于这种表达应用程序知识状态的机制将为应用程序提供一种高效的方式，以获取在指定时间之后发生的更改。

  如果应用程序的知识表达可以持久化，即以可恢复的方式存储在文件或数据库中，那么重新启动应用程序所需的资源就会少于不能持久化的情况。 在上面的例子中，可以通过记录 DC d 和时间 t 来持久化应用程序的知识表达。 有些更改通知机制不允许持久保存这些数据。 当应用程序启动时，服务器和应用程序必须与其他机制同步。 如果涉及多个对象，并且可能涉及复杂的编程，则需要耗费大量资源。

使用以下技术跟踪 Active Directory 域服务中的更改：

• 使用更改通知控件启动持续异步搜索，以查找符合指定筛选器的更改。 有关详细信息，请参阅 Active Directory 域服务中的更改通知。
• 使用目录同步 (DirSync) 搜索来检索自上次 DirSync 搜索以来发生的更改。 有关详细信息，请参阅使用 DirSync 控件轮询更改。
• 使用 USNChanged 属性搜索自上次搜索后发生更改的对象。 有关详细信息，请参阅使用 USNChanged 轮询更改。

更改通知控件适用于需要合理及时通知非经常性更改的应用程序或服务。 例如，在 Active Directory 服务器上存储配置数据的服务或程序，在发生更改时都必须及时进行通知。 请注意，通知控件有其局限性。

• 通知的及时性取决于复制延迟和更改发生的位置。 当更改被复制到正在监控的副本时，可能就会立即收到通知，但该变更可能会更早地在其他副本上产生。
• 该控件仅限于监视单个对象或容器的直接子对象。 必须监视多个容器或无关对象的应用程序最多可注册五个通知请求。
• 如果有太多客户端在侦听频繁发生的更改，则会影响服务器的性能。 一般而言，出于对服务器性能的考虑，应用程序应限制使用该控件。 如果不需要立即知道更改，最好定期轮询更改，而不是使用更改通知。

DirSync 和 USNChanged 搜索技术适用于在 Active Directory 服务器上的数据和其他存储中的相应数据之间保持一致的应用程序。 定期轮询更改的应用程序会使用这些技术。 DirSync 技术以 LDAP 服务器控件为基础，可通过 ADSI 或 LDAP API 使用。 DirSync 控件的缺点是只能由高特权帐户（如域管理员）使用。 下面是 DirSync 控件的限制列表：

• DirSync 控件只能由高特权帐户（例如域管理员）使用。
• DirSync 控件只能监视整个命名上下文。 不能将 DirSync 搜索的范围限制为只监视命名上下文中的特定子树、容器或对象。

USNChanged 技术没有这些限制，只是使用起来比 DirSync 复杂一些。