Обзор методов Отслеживание изменений

Существует несколько способов, которые могут отличаться механизмы отслеживания изменений:

• Область отслеживания изменений: приложение может отслеживать изменения одного атрибута одного объекта, всех объектов в домене и т. д. Если механизм соответствует требованиям приложения, приложение получает минимум неуместных данных и, следовательно, повышает производительность.

• Своевременность. Приложение уведомляется о каждом изменении, как это происходит, или может быть уведомлено о чистом эффекте изменений в течение нескольких минут или часов.

  Обработка менее своевременных данных может быть более эффективной, так как несколько изменений могут быть свернуты в одну. Например, если атрибут изменяется три раза в течение одного часа, приложение уведомляет об изменениях, накопленных в течение часа, будет уведомлено только об изменении одного атрибута, а не трех.

  При думать о временная шкала ss следует учитывать влияние задержки реплика. Обновление, которое возникает на одном контроллере домена, не реплика te к другому контроллеру домена мгновенно. Требование отслеживания изменений временная шкала гораздо лучше, чем ожидаемая задержка реплика tion часто не дает реальных преимуществ приложению.

• Опрос и уведомление. При опросе приложение периодически запрашивает контроллер домена для получения данных отслеживания изменений. При уведомлении контроллер домена отправляет изменения в приложение только при изменении.

  Затраты на опрос очевидны: приложение может запрашивать данные отслеживания изменений, если ничего значительного не произошло. Затраты на уведомление более тонкие. Сервер должен поддерживать данные о запросах на уведомления и обращаться к этим данным, чтобы решить, следует ли отправлять уведомление. Это может добавить дополнительные расходы на обычные запросы на обновление.

• Выражение знаний приложения: постоянное и временное: каждый механизм отслеживания изменений должен включать в себя некоторый метод для сервера, держащего данные, отслеживаемые, чтобы понять состояние знаний приложения, чтобы идея "изменения" была четко определена. Например, состояние знаний приложения может быть выражено как "Обновлено со всеми изменениями, которые произошли на контроллере домена d до времени t". Механизм, основанный на этом способе выражения состояния знаний приложения, обеспечивает эффективный способ получения изменений, произошедших позже указанного времени.

  Если выражение знаний приложения может быть сохранено, то есть хранимо, как в файле или базе данных, перезапуск приложения меньше ресурсов, чем в том случае, если он не может. В приведенном выше примере выражение знаний приложения можно сохранить путем записи контроллера домена d и времени t. Некоторые механизмы уведомлений об изменениях не позволяют сохранять эти данные. Сервер и приложение должны синхронизироваться с другим механизмом при запуске приложения. Это ресурсоемкое значение, если задействовано несколько объектов, и может включать сложное программирование.

Используйте следующие методы для отслеживания изменений в службах домен Active Directory:

• Используйте элемент управления уведомления об изменении, чтобы инициировать постоянный асинхронный поиск изменений, соответствующих указанному фильтру. Дополнительные сведения см. в разделе "Уведомления об изменениях" в службах домен Active Directory.
• Используйте поиск синхронизации каталогов (DirSync), чтобы получить изменения, произошедшие с предыдущего поиска DirSync. Дополнительные сведения см. в разделе "Опрос изменений" с помощью элемента управления DirSync.
• Используйте атрибут USNChanged для поиска объектов, измененных с момента предыдущего поиска. Дополнительные сведения см. в разделе "Опрос изменений с помощью USNChanged".

Элемент управления уведомления об изменениях предназначен для приложений или служб, требующих достаточно быстрого уведомления о редких изменениях. Примером является служба или программа, которая хранит данные конфигурации на сервере Active Directory и должна быть немедленно уведомлена при возникновении изменения. Помните, что существуют ограничения элемента управления уведомлениями.

• Запрос уведомлений зависит от задержки реплика и от того, где произошло изменение. Вы можете быстро получать уведомления, когда изменения реплика tes в реплика мониторинга, но изменение, возможно, произошло гораздо раньше на некоторых других реплика.
• Элемент управления ограничен мониторингом одного объекта или непосредственных дочерних элементов контейнера. Приложения, которые должны отслеживать несколько контейнеров или несвязанных объектов, могут регистрировать до пяти запросов уведомлений.
• Если слишком много клиентов прослушивает изменения, которые происходят часто, это повлияет на производительность сервера. В общем случае приложения должны ограничить использование этого элемента управления по соображениям производительности на сервере. Если вам не нужно сразу знать об изменениях, рекомендуется периодически опрашивать изменения, а не использовать уведомление об изменениях.

Методы поиска DirSync и USNChanged предназначены для приложений, которые поддерживают согласованность между данными на сервере Active Directory и соответствующими данными в другом хранилище. Эти методы используются приложениями, которые периодически опрашивают изменения. Метод DirSync основан на серверном элементе управления LDAP, который можно использовать с помощью API ADSI или LDAP. Недостатки элемента управления DirSync — это то, что оно может использоваться только учетной записью с высоким уровнем привилегий, например администратором домена. Ниже приведен список ограничений элемента управления DirSync.

• Элемент управления DirSync может использоваться только учетной записью с высоким уровнем привилегий, например администратором домена.
• Элемент управления DirSync может отслеживать только весь контекст именования. Невозможно ограничить область поиска DirSync, чтобы отслеживать только определенный поддерев, контейнер или объект в контексте именования.

Метод USNChanged не имеет этих ограничений, хотя он несколько сложнее использовать, чем DirSync.