OpenLDAP（或者是LDAP的任何一种）是否能够提供写入问题？我知道这是一个最终一致的模型，但是有更多的DB具有最终的一致性和写作关注。
在做了一些研究之后，我仍然无法弄清楚它是否是一种东西。
答案 0 :(得分：2)
UnboundID Directory Server为可靠的复制模式提供支持，在该模式下，您可以请求服务器延迟对操作的响应，直到以满足您所需约束的方式复制它。这可以通过在添加/删除/修改/修改DN请求中包含特殊控制，或者通过配置服务器的标准来控制每个操作，该标准可用于识别哪些操作应使用此保证的复制模式（例如， ，您可以配置服务器，以便针对特定属性集的操作比其他属性受到更高级别的保证。
我们可靠的复制实施允许您为本地服务器（与从客户端接收请求的服务器位于同一数据中心的服务器）和非本地服务器（其他数据中心中的服务器）定义单独的要求。这允许您调整服务器以实现性能和行为之间的平衡。
对于本地服务器，可能的保证级别为：
不要进行任何特殊保证处理。服务器将在本地处理后立即将响应发送到客户端，并且更改将尽快复制到其他服务器。有可能（尽管极不可能）在服务器将响应发送到客户端之后但在复制之前发生的永久性故障可能导致更改丢失。
延迟对客户端的响应，直到将更改复制到本地数据中心的至少一个其他服务器。这确保即使在客户端正在与之通信的实例丢失的情况下也不会丢失更改，但是当客户端收到响应时，可能尚未在本地数据中心的所有实例上看到更改
延迟对客户端的响应，直到在本地数据中心的所有服务器中显示更改结果。这可确保访问本地服务器的客户端不会看到过时的信息。
非本地服务器可用的保证选项包括：
不要进行任何特殊保证处理。服务器不会基于与非本地服务器的任何通信来延迟对客户端的响应，但是如果整个数据中心丢失（例如，通过大规模的自然灾害）或者变得不可用（例如，因为它），则可能丢失或延迟更改。丢失网络连接。）
延迟对客户端的响应，直到将更改复制到至少一个其他数据中心的至少一个其他服务器。这可确保即使丢失完整的数据中心也不会丢失更改，但不保证在客户端收到响应时，更新的信息将随处可见。
延迟对客户端的响应，直到将更改复制到每个其他数据中心的至少一个服务器。这可确保即使网络分区在处理更改后的一段时间内使数据中心不可用，也会在每个数据中心处理更改。但同样，这并不能保证在客户收到回复时到处都可以看到更新后的信息。
延迟对客户端的响应，直到所有其他数据中心的所有可用服务器中都显示更改。这可确保任何客户端都不会看到过时的信息，无论他们使用的服务器位置如何。
UnboundID Directory Server还提供的功能有助于确保客户端在正常情况下不会暴露于过时的信息。我们的复制机制非常快，因此更改通常会在几毫秒内到处出现。每个服务器都在不断监视自己的复制积压，并且如果积压变得太大（例如，警告管理员等温和操作或更严厉的措施，如拒绝客户端请求，直到复制赶上），则可以采取措施。并且由于服务器由于某种原因而脱机时遇到大多数复制积压，因此服务器还能够在启动时延迟接受来自客户端的连接，直到它赶上在脱机时处理环境中处理的所有更改。如果您进一步将此与UnboundID目录代理服务器的高级负载平衡和运行状况检查功能结合使用，则可以确保仅将客户端请求转发到没有复制积压或可能导致任何其他不良情况的服务器操作失败，需要很长时间才能完成或遇到过时的信息。
答案 1 :(得分：2)
通过回顾RFC3384关于LDAP的复制要求的讨论，看起来LDAP只需要最终的一致性，并且不需要事务一致性。因此，任何支持此功能的产品都可能通过特定于供应商的实现来执行此操作。
CA Directory确实支持名为MULTI-WRITE的专有复制模型，该模型保证客户端仅在所有复制的实例更新后才获得写入确认。此外，它还支持标准的X.525 Shadowing Protocol，它提供较低的一致性保证和更好的性能。
对于典型的LDAP实现，更新请求通常会在处理此请求的DSA更新后立即返回，而不是在更新副本实例时。我相信OpenLDAP就属于这种情况。好处是速度，缺点是缺乏保证更新已应用于所有副本。
答案 2 :(得分：-1)
CA's directory产品使用内存映射系统，写入速度非常快，这不是问题。