Performance 是否使用未绑定的LDAP SDK创建LDAP缓存？

我想创建一个具有以下目标的LDAP缓存

减少到ldap服务器的连接尝试

如果条目存在并且在缓存中有效，则读取本地缓存

如果之前没有此类请求或缓存中的条目无效，则从ldap获取

目前，我正在使用未绑定的LDAP SDK查询LDAP，它可以正常工作

在做了一些研究之后，我发现了一个可能有效的持久性搜索示例。ldap服务器中更新的条目会将该条目传递给searchEntryReturned，以便可以进行缓存更新

但我不知道如何做到这一点，因为它是异步的，或者有更好的方法来实现缓存？榜样和想法深受欢迎

Ldap服务器是ApacheDS，它支持持久搜索

---

该程序是一个JSF2应用程序。

我相信ApacheDS支持使用RFC4533中定义的内容同步控件。这些控件可用于在系统之间实现某种复制或数据同步，而缓存在某种程度上是一种常见的用途。未绑定LDAP SDK支持这些控件(http://www.unboundid.com/products/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/ContentSyncRequestControl.html). 我建议查看这些控件和RFC4533中包含的信息，以确定这是否更合适

另一种方法可能是查看ApacheDS是否支持LDAP变更日志（例如，采用良好的LDAP变更日志草案中描述的格式）。这允许您检索有关已更改的条目的信息，以便可以在本地副本中更新这些条目。通过定期轮询changelog以查找新的更改，您可以按照自己的速度使用有关更改的信息（包括应用程序脱机时可能进行的更改）

尽管持久性搜索在您的情况下可能会起作用，但仍有一些问题可能使其成为问题。首先，您无法控制将更新的条目发送到客户机的速度，如果服务器应用更改的速度比客户机使用更改的速度快，那么这可能会使客户机不知所措（在许多实际案例中都观察到了这一点）。第二，持久性搜索将让您知道更新了哪些条目，而不是对它们进行了哪些更改。在缓存的情况下，这可能不会产生太大的影响，因为您只需替换整个条目的副本，但在其他情况下就不太理想了。另一个大问题是，持久搜索只会返回有关在搜索活动时更新的条目的信息。如果您的客户端被关闭或由于某种原因连接变得无效，那么当客户端处于该状态时，没有简单的方法可以获取有关任何更改的信息

---

客户端缓存通常是一件坏事，原因很多。它可以为应用程序提供过时的数据，这有可能导致不正确的行为，或者在某些情况下造成安全风险，如果您将其用于身份验证，这绝对是一个巨大的安全风险。如果不是所有客户端对缓存中包含的数据都具有相同级别的访问权限，那么这也可能带来安全风险。此外，为每个客户端应用程序实现缓存并不是一个可伸缩的解决方案，如果您要尝试在多个应用程序之间共享缓存，那么您最好将其作为一个完整的目录服务器实例。最好使用一个服务器，它可以简单地处理所需的负载，而不需要任何额外的缓存。

非常好的解释。嗯。。。我的ldap服务器实际上是localhost，有很多请求询问“这个用户在一组职员中吗？”。结果是一个页面调用了100个ldap请求，其中一些请求实际上与之前请求的请求相同，产生了5秒的有效负载。我知道“未更新”缓存会导致问题。我应该改进什么？一般来说，确定用户是否是给定组的成员的过程应该只需要一个搜索操作来匹配一个条目。如果它是一个静态组（例如，使用groupOfNames、groupOfUniqueNames或groupOfEntries对象类），那么只需要使用一个过滤器对条目执行基本级别的搜索，该过滤器以成员属性为目标，其值等于目标用户的DN（例如“（member=uid=john.doe，ou=People，dc=example，dc=com）”。如果是动态组，则确保用户条目在范围内并与相关筛选器匹配。此外，某些目录提供了其他确定方法（例如，用户条目中的动态生成属性，其中包含该用户所属组的DNs列表）。在这种情况下，您可以利用该功能进行更有效或更方便的确定。