我想做一个 LDAP 缓存，目标如下
减少与 ldap 服务器的连接尝试
如果条目存在且在缓存中有效，则读取本地缓存
如果之前没有这样的请求或者缓存中的条目无效，则从ldap获取
目前我正在使用 unboundid LDAP SDK 来查询 LDAP，它可以工作。
在做了一些研究之后，我发现了一个可能有效的持久搜索示例。 ldap 服务器中更新的条目会将条目传递给 searchEntryReturned，以便可以更新缓存。
但我不确定如何执行此操作，因为它是异步的，还是有更好的方法来实现缓存？非常欢迎示例和想法。
Ldap 服务器是 Apache DS，它支持持久搜索。
该程序是一个 JSF2 应用程序。
【问题讨论】：
标签： performance caching ldap unboundid-ldap-sdk
我相信 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 更改日志（例如，采用 draft-good-ldap-changelog 中描述的格式）。这允许您检索有关已更改条目的信息，以便可以在本地副本中更新它们。通过定期轮询更改日志以查找新更改，您可以按照自己的节奏使用有关更改的信息（包括可能在您的应用程序离线时进行的更改）。
虽然持久搜索可能适用于您的情况，但仍有一些问题可能会导致问题。首先是您无法控制将更新条目发送到客户端的速率，如果服务器应用更改的速度快于客户端可以使用它们的速度，那么这可能会使客户端不堪重负（已观察到在许多实际案例中）。第二个是持久搜索会让您知道更新了哪些条目，但不知道对它们进行了哪些更改。在缓存的情况下，这可能不会产生巨大的影响，因为您只需替换整个条目的副本，但在其他情况下不太理想。另一个大问题是持久搜索只会返回有关在搜索处于活动状态时更新的条目的信息。如果您的客户端已关闭或连接由于某种原因变得无效，那么当客户端处于该状态时，就没有简单的方法来获取有关任何更改的信息。
客户端缓存通常是一件坏事，原因有很多。它可以为应用程序提供陈旧的数据，这有可能导致不正确的行为或在某些情况下带来安全风险，如果您将其用于身份验证，这绝对是一个巨大的安全风险。如果并非所有客户端都对缓存中包含的数据具有相同级别的访问权限，它也可能带来安全风险。此外，为每个客户端应用程序实现一个缓存并不是一个可扩展的解决方案，如果您要尝试在多个应用程序之间共享一个缓存，那么您不妨将其设为一个完整的目录服务器实例。最好使用可以简单地处理所需负载而无需任何额外缓存的服务器。
【讨论】：