變更追蹤 技術概觀

有數種方式可以變更追蹤機制不同：

• 追蹤變更的範圍：應用程式可以追蹤單一物件之單一屬性的變更、網域中的所有物件等等。 如果機制符合應用程式的需求，則應用程式會收到最少的不相關數據，因而提升效能。

• 時間軸：應用程式會在發生時收到每個變更的通知，或可在幾分鐘或數小時內收到變更的凈影響通知。

  處理較不及時的數據可能會更有效率，因為可能會將數個變更折疊成一個。 例如，如果屬性在一小時內變更三次，應用程式就會只收到一個屬性變更的通知，而不是 3 個。

  考慮時程表時，請考慮復寫延遲的效果。 源自某個域控制器的更新不會立即復寫至另一個域控制器。 要求變更追蹤時間軸比預期的復寫延遲好得多，通常不會對應用程式帶來真正的好處。

• 輪詢與通知：透過輪詢，應用程式會定期向域控制器提出要求，以接收變更追蹤數據。 當通知時，域控制器只會在發生變更時，才會將變更傳送至應用程式。

  輪詢的額外負荷很明顯：當沒有任何重大事件發生時，應用程式可能會要求變更追蹤數據。 通知的額外負荷比較微妙。 伺服器必須維護通知要求的相關數據，而且必須諮詢此數據，以決定是否要傳送通知。 這可能會增加一般更新要求的額外負荷。

• 表達應用程式的知識：持續性與暫時性：每個變更追蹤機制都必須包含一些方法，讓保存追蹤數據的伺服器瞭解應用程式的知識狀態，以便妥善定義「變更」的概念。 例如，應用程式的知識狀態可能會表示為「更新 DC d 之前在 t 時間之前發生的所有變更」。以這種方式表達應用程式知識狀態的機制，可為應用程式取得比指定時間晚發生的變更提供有效率的方式。

  如果可以保存應用程式知識的表達式，也就是可復原地儲存，如同在檔案或資料庫中一樣，應用程式重新啟動會比無法重新啟動的資源少。 在上述範例中，可以藉由記錄DC d和time t來保存應用程式知識的表達式。 某些變更通知機制不允許保存此數據。 伺服器和應用程式必須在應用程式啟動時與一些其他機制同步處理。 如果涉及多個物件，而且可能涉及複雜的程序設計，這會耗用大量資源。

使用下列技術來追蹤 Active Directory 網域服務 中的變更：

• 使用變更通知控制項來起始持續異步搜尋符合指定篩選條件的變更。 如需詳細資訊，請參閱 Active Directory 網域服務 中的變更通知。
• 使用目錄同步處理 （DirSync） 搜尋來擷取自先前 DirSync 搜尋以來發生的變更。 如需詳細資訊，請參閱 使用 DirSync 控件輪詢變更。
• 使用 USNChanged 屬性來搜尋自上一次搜尋後已變更的物件。 如需詳細資訊，請參閱 使用USNChanged輪詢變更。

變更通知控件是專為需要合理提示通知不常變更的應用程式或服務所設計。 例如，服務或程式會將組態數據儲存在 Active Directory 伺服器上，而且在發生變更時必須立即收到通知。 請注意，通知控件有一個限制。

• 通知的提示性取決於復寫延遲，以及發生變更的位置。 當變更復寫到您正在監視的複本時，可能會立即收到通知，但變更可能早於某些其他複本。
• 控件僅限於監視單一物件或容器的直接子系。 必須監視多個容器或不相關的物件的應用程式最多可以註冊五個通知要求。
• 如果太多用戶端正在接聽經常發生的變更，它會影響伺服器的效能。 一般而言，基於伺服器上的效能考慮，應用程式應該限制其使用此控件。 如果您不需要立即知道變更，最好定期輪詢變更，而不是使用變更通知。

DirSync 和 USNChanged 搜尋技術是針對在 Active Directory 伺服器上維護數據與某些其他記憶體中對應數據之間的一致性的應用程式所設計。 這些技術是由定期輪詢變更的應用程式所使用。 DirSync 技術是以您可以透過 ADSI 或 LDAP API 使用的 LDAP 伺服器控制件為基礎。 DirSync 控件的缺點是它只能由高許可權帳戶使用，例如網域管理員。 以下是 DirSync 控制件的限制清單：

• DirSync 控件只能由高許可權帳戶使用，例如網域系統管理員。
• DirSync 控件只能監視整個命名內容。 您無法限制 DirSync 搜尋的範圍，只監視命名內容中的特定子樹、容器或物件。

USNChanged 技術沒有這些限制，不過使用比 DirSync 複雜一些。