Я считаю, что Apache DS поддерживает использование элементов управления синхронизацией контента, как определено в RFC 4533. Эти элементы управления могут использоваться для реализации своего рода репликации или синхронизации данных между системами, а кеширование - это несколько общее использование этого. SDK UnboundID LDAP поддерживает эти элементы управления (http://www.unboundid.com/products/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/ContentSyncRequestControl.html). Я бы рекомендовал посмотреть эти элементы управления и информацию, содержащуюся в RFC 4533, чтобы определить, может ли это быть более уместным.
Другой подход может заключаться в том, чтобы узнать, поддерживает ли Apache DS журнал изменений LDAP (например, в формате, описанном в проекте-good-ldap-changelog). Это позволяет вам получать информацию о внесенных изменениях, чтобы их можно было обновить в локальной копии. Периодически опросив журнал изменений, чтобы искать новые изменения, вы можете потреблять информацию об изменениях в своем собственном темпе (включая те, которые могли быть сделаны, когда приложение было отключено).
Хотя постоянный поиск может работать в вашем случае, есть несколько проблем, которые могут вызвать проблемы. Во-первых, вы не получаете никакого контроля над скоростью, с которой обновленные записи отправляются клиенту, и если сервер может применять изменения быстрее, чем клиент может их использовать, тогда это может привести к перегрузке клиента (который наблюдался в ряде случаев в реальном мире). Во-вторых, постоянный поиск позволит вам узнать, какие записи были обновлены, но не какие изменения были внесены в них. В случае кеша это может не иметь большого влияния, потому что вы просто замените копию всей записи, но в других случаях она менее желательна. Еще одна большая проблема заключается в том, что постоянный поиск будет возвращать только информацию об элементах, обновленных во время поиска. Если ваш клиент отключен или соединение по какой-либо причине становится недействительным, тогда нет простого способа получить информацию о любых изменениях, пока клиент находится в этом состоянии.
Клиентское кэширование, как правило, плохо, по многим причинам.Он может служить устаревшими данными для приложений, которые могут вызвать неправильное поведение или в некоторых случаях представлять угрозу безопасности, и это абсолютно огромный риск для безопасности, если вы используете его для аутентификации. Это может также представлять угрозу безопасности, если не все клиенты имеют одинаковый уровень доступа к данным, содержащимся в кеше. Кроме того, реализация кэша для каждого клиентского приложения не является масштабируемым решением, и если вы попытаетесь предоставить общий доступ к кешу в нескольких приложениях, вы можете просто сделать его полным экземпляром сервера каталогов. Гораздо лучше использовать сервер, который может просто обрабатывать требуемую нагрузку без необходимости дополнительного кэширования.
Очень хорошее объяснение. Умм ... мой ldap-сервер на самом деле является локальным хостом, и есть так много запросов с просьбой «Является ли этот пользователь в группе клерка?». Оказалось, что страница вызывает 100 запросов ldap, некоторые из них на самом деле являются тем же запрошенным ранее запросом, что приводит к полезной нагрузке 5сек. Я понимаю, что «не обновленный» кеш вызывает проблемы. что я должен улучшить? – Tommy
В целом, процесс определения того, является ли пользователь членом данной группы, должен требовать только одной операции поиска, соответствующей только одной записи. Если это статическая группа (например, с использованием классов объектов groupOfNames, groupOfUniqueNames или groupOfEntries), тогда необходимо выполнить поиск на уровне базового уровня с помощью элемента с таргетингом на атрибут элемента со значением, равным целевому DN пользователя (например. "(member = uid = john.doe, ou = People, dc = example, dc = com)"). Если это динамическая группа, убедитесь, что запись пользователя находится в области видимости и соответствует соответствующему фильтру. –
Кроме того, некоторые каталоги предлагают другие способы определения (например, динамически сгенерированный атрибут в записи пользователя со списком DN групп, в которых этот пользователь является членом). В этом случае вы сможете воспользоваться этой возможностью, чтобы сделать более эффективное или удобное определение. –