Bayou 阅读笔记：最终一致性与应用冲突

允许离线写入的复制系统，需要接受副本暂时不同。本文从课程中的 Bayou 笔记整理，讨论这些差异如何被发现、解释和合并。

最终一致性不负责自动解决业务冲突

在没有新更新、通信最终恢复并完成同步等条件下，副本应收敛到一致状态。但“收敛”本身不保证这个状态符合所有业务约束。

离线日历里，两台设备可以分别预订同一个房间和时段。简单保留所有记录，虽然所有人最终看到相同日历，却仍可能重复预订。

冲突依赖应用语义

判断方式	容易遗漏的问题
整个文件是否都被改过	两个互不相关的会议也被视为冲突
是否修改同一条记录	不同会议可能争用同一房间或同一参会者
应用约束检查	需要明确具体业务规则和修复方式

Bayou 将依赖检查和合并逻辑放进写操作，使应用能够说明什么时候发生冲突、发现后如何处理。原论文关注的是弱连接环境中的复制存储。

顺序也会影响结果

“10 点空闲就预约 10 点，否则预约 11 点”这样的更新，结果取决于它读取的已有状态。因此只交换更新还不够，各副本还需要约定执行顺序和确定性的合并行为。

当一个暂定更新的新位置被确定，副本可能回滚并重放后续更新。用户界面也要表达暂定状态，否则同步后发生变化会让人误以为已确认的数据被任意修改。

暂定与已提交

Bayou 区分 tentative 与 committed 写。主节点为已提交写分配稳定的提交顺序；同步同时处理已提交部分和暂定部分。这样既支持断连期间的本地操作，也能逐步建立稳定的历史。

主节点提交不会让离线操作立刻变成强一致。系统仍需要传播状态；暂定操作也不能被当成已获得所有节点确认的最终结果。

从这篇笔记保留的设计问题

设计同步功能时，应分别描述：哪些内容可离线修改、业务冲突如何定义、修改何时稳定，以及用户能否看出暂定状态。

不要把数据库层的“同一行”误当成业务层的“同一个资源约束”。收敛、因果顺序、提交稳定性和业务正确性，需要分别论证。