摘要

  • RFC 3384 要求多主副本最终收敛到同一活状态；若冲突裁决会让目录信息从活状态中消失，系统仍必须保存那份信息、通知管理员并留下可能的人工覆盖路径。
  • 网络到达顺序不能决定最终赢家。可用的统一答案与可审计的分歧证据，是两个必须同时满足的义务。

两个目录服务器在断网期间都接受了写入，而且改的是同一个属性。连接恢复以后，双方都握有一段在本地完全成立的历史。若系统承诺最终一致，就必须让所有副本选出同一个活值。然而，选出赢家并不等于获得了销毁败者的授权。RFC 3384 最值得记住的设计边界，正是在“已经一致”之后提出的：被裁决挤出的信息仍然必须留下。

这份文件于 2002 年 10 月以 Informational RFC 发布。它收集的是可互操作 LDAPv3 目录复制的基本需求，而不是一套完整的复制协议，也不是某种产品部署的证明。因此，历史评价不能把需求文本写成实现史。它规定合格方案不得越过哪些边界，却没有替未来工程选择唯一的冲突算法、时钟或存储格式。

LDAP 当时已经规范客户端与服务器如何交流，服务器之间怎样复制却是另一项问题。复制能把目录内容带到离读者更近的位置，也能在一台服务器故障时维持服务。与此同时，它把拓扑、部分副本、访问控制、模式定义、重放、会话安全以及并发写入都带进同一个运行面。

RFC 3384 把复制区域定义为目录信息树中可配置的一部分。区域可以重叠，也可以嵌套。某一区域的一个实例叫副本，持有该区域的服务器形成副本组。复制协议约定则承载区域范围、访问参数、凭证、保密方式与传播行为。由此可见，“已经同步”从来不是脱离范围的绝对判断；它总是相对于哪一片树、哪一组成员、哪一份约定而言。

文件讨论了五种一致性模型。事务一致性包含熟悉的 ACID 性质，但分布式两阶段提交带来的复杂度，使作者当时没有沿这条路线继续。需求的重点落在最终一致与有限努力的最终一致上。暂时分歧由此成为运行模型的一部分，而不是协议已经失败的自动证据。

暂时允许分歧，并不等于结果可以随意。M3 要求持有某条目的每个副本，最终让属性收敛到同一组值。MM6 在多主情境中再次要求属性与条目收敛。网络分区可以推迟共同状态，却不能取消到达共同状态的义务。

多主设计让冲突成为结构性可能。多个主副本无需先联系其他主副本就能收写。这样做保住了本地可用性，但也允许两项修改在互相可见之前同时触及同一份目录数据。重连之后，复制机制必须决定哪项修改进入活状态。

决定必须是确定性的，但“最后收到者胜”并不可靠。两个副本可能以相反顺序收到完全相同的两项更新；若它们都把本地最后一次到达当作权威，便会各自选出不同赢家。MM7 因而要求，为保证最终收敛，冲突解决不能依赖变更按顺序到达。传输网络负责递送决定，不能因为偶然时序而获得分配永久权威的权力。

RFC 3384 没有指定逻辑时钟、服务器优先级或时间戳比较规则。它只固定更根本的验收条件：在受支持的模型内，独立副本即使以不同顺序看到更新，也必须能走向同一结果。规范为后续设计保留空间，同时排除那些正确性依赖不可控到达序列的方案。

MM5 随后把“收敛”与“证据毁损”拆开。多主复制不得丢失信息。如果冲突解决仍会让目录信息离开收敛后的活视图，复制过程就必须把它存到别处，向管理员说明冲突与损失，并提供可能进行管理覆盖的机制。

这并不是要求两个互斥值都继续留在活条目里。若客户端仍要自行猜测哪个值有效，系统只是把裁决推给下游。RFC 3384 设计的是两个现实层：一个供客户端使用的统一当前状态，以及一个保存自动规则所排除内容的证据通道。管理员可以看到被移走的内容，理解选择发生的原因，并在必要时更改活状态。

这也暴露了常见健康指标的盲区。十个副本都显示同一值，说明传播已经得到共同视图；它没有说明赢家是否正确、败者能否恢复、冲突是否通知到人。绿色的“已收敛”灯只覆盖读者此刻看到的层面。证据是否存在、裁决能否追责、错误能否撤回，需要另外证明。

M12 处理的是重放边界。消费者重复收到同一更新，其结果必须与只收到一次相同。连接可能在服务器应用更新之后、确认送达之前中断。供应方不知道对方是否已经处理，只能重试。如果重复投递被当成第二项独立修改，恢复机制反而会制造数据破坏。

P6 要求复制保留 LDAP 操作原有的原子性。一次操作包含的多个变更，不能因为跨服务器传递就只显露一部分。不过，两项完整而原子的操作依然可能互相冲突。原子性防止撕裂写入，它不负责替两个都成立的意图决定赢家。

文件也把数据冲突和会话启动冲突分开。若多个主服务器同时尝试向同一副本发起复制，MM4 要求自动解决或避免这一竞争。消费者忙碌、连接丢失、周期重排属于会话协调；值内容之间的分歧属于数据裁决。两者相关，却不能用同一个“冲突”标签掩盖。

管理能力被写进互操作边界。AM2 要求每个副本保存与哪些服务器交换过数据的审计历史。AM4 与 AM5 希望实现能够比较两个副本，并在不触发新复制周期的情况下修复差异。空白副本还应能从完整更新初始化。对账不能只是后台不可见的保证，它需要可核对的证据和可控的修复动作。

到达顺序不能选赢家，却不代表任何顺序都无意义。AM6 要求保留访问控制信息与其所管数据之间的更新顺序。若数据先到、保护它的规则后到，中间状态可能拥有完全不同的安全含义。偶然网络顺序不能成为权威，但明确的因果依赖仍需随更新传播。

模式不匹配必须被处理并报告。复制范围包括模式定义、属性名与属性值、访问控制信息、知识信息和命名空间信息，同时不把 DSA 特有运行属性本身当作普通复制内容。副本可以是部分副本，但“部分”不应意味着边界不明；协议约定必须说清它包含哪些区域、条目与属性。

安全需求同样拒绝把不同事实揉成一个标签。相互认证、相互授权检查、完整性与保密性分别存在。文件也要求支持匿名复制会话，这并不表示匿名与已认证会话拥有同等信任，而是要求协议能表示两种条件以及各自的政策后果。

后来的 LDAP 文档只能提供时间线，不能反向证明 RFC 3384 已被完整实现。RFC 4510、RFC 4511 与 RFC 4512 重新组织了 LDAP 技术规范；RFC 4533 定义内容同步操作，RFC 5805 后来定义事务。相邻机制不等于同一承诺，更不能据此声称某个具名产品满足了全部多主需求。

与前一份 RFC 3383 对照，可以看出两种不同的协调面。RFC 3383 管理 LDAP 扩展标识符怎样进入共享登记空间，降低名字碰撞；RFC 3384 处理合法更新怎样在时间上碰撞，以及败选历史怎样保留。前者治理名字进入，后者治理状态分歧留下何种证据。

Lu Heng 的“最小初始规范”视角解释了为何一份不选定算法的需求文档仍有价值。初始规范可以先钉住不可接受的伤害：不能让网络到达顺序授予权威，不能静默丢掉另一项写入，不能让管理者失去纠正通道。具体机制仍可本地化、演进和替换，但自由选择不包含销毁争议材料的自由。

“现实层”视角则要求逐项区分：写入被接受、更新被传播、冲突被检测、赢家进入活状态、败者被另存、管理员收到通知、人工最终决定。这些都是不同事实。把它们压缩成一个“同步成功”，就会让技术指标冒充治理结论。

RFC 3384 的持久提醒，是警惕过分干净的收敛。分布式系统可能通过消灭反证而获得一个答案。保存落败值的要求，把静默覆盖改造成可审计决定。副本可以一致，但不能借一致假装它们从未发生过分歧。

来源