使用 unboundid LDAP SDK 创建 LDAP 缓存？
我想创建一个具有以下目标的 LDAP 缓存
减少与 ldap 服务器的连接尝试
如果条目存在且在缓存中有效，则读取本地缓存
如果之前没有此类请求，或者缓存中的条目无效，则从 ldap 中获取
当前我正在使用 unboundid LDAP SDK 来查询 LDAP 并且它可以工作。
经过一些研究后，我发现了一个可能有效的持久搜索示例。 LDAP 服务器中更新的条目会将条目传递给 searchEntryReturned，以便可以进行缓存更新。
但我不知道如何做到这一点，因为它是异步的还是有更好的方法来实现缓存？例子和想法非常受欢迎。
Ldap服务器是Apache DS，它支持持久搜索。
该程序是一个 JSF2 应用程序。
I would like to make a LDAP cache with the following goals
Decrease connection attempt to the ldap server
Read local cache if entry is exist and it is valid in the cache
Fetch from ldap if there is no such request before or the entry in the cache is invalid
Current i am using unboundid LDAP SDK to query LDAP and it works.
After doing some research, i found a persistent search example that may works. Updated entry in the ldap server will pass the entry to searchEntryReturned so that cache updating is possible.
But i am not sure how to do this since it is async or is there a better way to implement to cache ? Example and ideas is greatly welcomed.
Ldap server is Apache DS and it supports persistent search.
The program is a JSF2 application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我相信 Apache DS 支持使用 RFC 4533 中定义的内容同步控件。这些控件可用于实现系统之间的一种复制或数据同步，而缓存是其中的一种常见用途。 UnboundID LDAP SDK 支持这些控件 (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 中描述的格式）。这允许您检索有关已更改条目的信息，以便可以在本地副本中更新它们。通过定期轮询变更日志以查找新的更改，您可以按照自己的节奏使用有关更改的信息（包括应用程序离线时可能进行的更改）。
尽管持久搜索可能适用于您的情况，但有一些问题可能会导致出现问题。首先，您无法控制更新条目发送到客户端的速率，并且如果服务器应用更改的速度比客户端使用它们的速度快，那么这可能会压垮客户端（这已经被观察到）在许多现实世界的案例中）。第二个是持久搜索将让您知道更新了哪些条目，但不知道对它们进行了哪些更改。在缓存的情况下，这可能不会产生巨大的影响，因为您只需替换整个条目的副本，但在其他情况下不太理想。另一个大问题是持久搜索只会返回有关搜索活动期间更新的条目的信息。如果您的客户端因某种原因关闭或连接变得无效，则没有简单的方法可以获取有关客户端处于该状态时的任何更改的信息。
出于多种原因，客户端缓存通常是一件坏事。它可以向应用程序提供过时的数据，这可能会导致不正确的行为，或者在某些情况下会带来安全风险，如果您使用它进行身份验证，这绝对是一个巨大的安全风险。如果并非所有客户端都对缓存中包含的数据具有相同级别的访问权限，也可能会带来安全风险。此外，为每个客户端应用程序实现缓存并不是一个可扩展的解决方案，如果您要尝试在多个应用程序之间共享缓存，那么您不妨将其设为完整的目录服务器实例。最好使用可以简单地处理所需负载而不需要任何额外缓存的服务器。
I believe that Apache DS supports the use of the content synchronization controls as defined in RFC 4533. These controls may be used to implement a kind of replication or data synchronization between systems, and caching is a somewhat common use of that. The UnboundID LDAP SDK supports these controls (http://www.unboundid.com/products/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/ContentSyncRequestControl.html). I'd recommend looking at those controls and the information contained in RFC 4533 to determine whether that might be more appropriate.
Another approach might be to see if Apache DS supports an LDAP changelog (e.g., in the format described in draft-good-ldap-changelog). This allows you to retrieve information about entries that have changed so that they can be updated in your local copy. By periodically polling the changelog to look for new changes, you can consume information about changes at your own pace (including those which might have been made while your application was offline).
Although persistent search may work in your case, there are a few issues that might make it problematic. The first is that you don't get any control over the rate at which updated entries are sent to your client, and if the server can apply changes faster than the client can consume them, then this can overwhelm the client (which has been observed in a number of real-world cases). The second is that a persistent search will let you know what entries were updated, but not what changes were made to them. In the case of a cache, this may not have a huge impact because you'll just replace your copy of the entire entry, but it's less desirable in other cases. Another big problem is that a persistent search will only return information about entries updated while the search was active. If your client is shut down or the connection becomes invalid for some reason, then there's no easy way to get information about any changes while the client was in that state.
Client-side caching is generally a bad thing, for many reasons. It can serve stale data to applications, which has the potential to cause incorrect behavior or in some cases pose a security risk, and it's absolutely a huge security risk if you're using it for authentication. It could also pose a security risk if not all of the clients have the same level of access to the data contained in the cache. Further, implementing a cache for each client application isn't a scalable solution, and if you were to try to share a cache across multiple applications, then you might as well just make it a full directory server instance. It's much better to use a server that can simply handle the desired load without the need for any additional caching.