无主（点对点）架构中向量时钟工作原理与应用问题

对你现有理解的校验（问题1答复） #

你的推导有部分符合实际逻辑，但存在几个核心认知偏差：

• 首先你假设的固定单协调者、写法定人数（write quorum）为3的架构不属于纯无主（P2P）架构：纯无主架构没有固定承担写入转发职责的协调节点，任何副本都可以直接接收客户端写请求，临时充当该次写入的协调节点。另外写quorum=3意味着3副本必须全部写入成功才算本次写操作生效，这种配置下根本不会出现你说的“副本3写入失败、部分节点更新成功”的情况——只要有一个副本写入失败，本次写就会直接返回失败，不会提交新的数据版本。你描述的部分节点更新成功、出现版本不一致的场景，只会出现在写quorum小于副本总数的配置下，比如3副本设置写quorum=2，只要2个节点写成功就算写入生效，未被写入的节点会留存旧版本，后续通过读修复、反熵同步对齐版本。
• 向量时钟的更新逻辑不是协调者统一分配全局时钟值：每个副本只负责维护自身ID对应的逻辑时钟分量，只有当节点本地成功应用了某份数据的写入更新时，才会把自身ID对应的时钟计数加1；其他节点ID对应的时钟分量，是在节点间同步数据、交换版本信息时，通过取各分量最大值的方式合并得到的，不存在协调者远程修改其他副本时钟值的逻辑。
• 你提到的“检测到逻辑时钟差值为1即可修复不一致”的判断逻辑是错的：向量时钟判断版本先后靠的是全分量的偏序关系，和单分量的差值没有关系：

  对同一份数据的两个版本A、B，如果A的向量时钟里所有节点ID对应的计数值都大于等于B向量时钟中对应ID的计数值，且至少有一个ID的计数值严格大于B，就说明A是B的因果后继版本，B是过期版本，可以直接用A覆盖修复；
  如果两个版本的向量时钟各自存在至少一个ID的计数值大于对方，说明两个版本是并发产生的冲突版本，无法自动判定新旧，需要业务逻辑介入解决冲突（比如按时间戳取最新、合并字段值等）。
  你举的例子里，全副本写入成功时各副本存的向量时钟为{1:1, 2:1, 3:1}，部分节点写入成功后存活节点持有的向量时钟为{1:2, 2:2, 3:1}，这两个向量时钟确实满足偏序关系（后者所有分量都大于等于前者），后者是更新的版本，这部分的VC值推导是正确的，但背后的判断原理不是单分量差值。

向量时钟的存储位置（问题2答复） #

你推测的“向量时钟存储在协调者上”的结论是错误的。
向量时钟是和单个数据版本强绑定的元数据，必须和对应的数据一起存储在持有该版本的副本节点本地，核心原因有三个：

• 纯无主架构下不存在固定协调者，每次写入的协调节点是临时产生的（通常是最先收到客户端请求的副本），根本没有一个固定节点可以持久化存储全量数据的向量时钟。
• 无主架构的核心特性就是支持副本间点对点完成同步、读修复操作，不需要经过固定协调节点：两个副本同步数据时，只需要拿出本地存储的、和数据绑定的向量时钟做对比，就能直接判断版本关系、完成冲突检测。如果向量时钟存在协调者上，一旦协调者宕机或者发生网络分区，整个集群的版本判断逻辑就会完全瘫痪，完全违背无主架构高可用的设计目标。
• 即便是你描述的带固定协调者的场景，协调者也不会持久化存储向量时钟：处理写请求时协调者只会临时拉取对应数据的当前VC、更新对应分量生成新VC，随写请求下发给副本，最终新VC还是会和数据一起持久化在副本本地。

内容的提问来源于stack exchange，提问作者Ted