因果广播

因果顺序想守住的是"果不得先于因出现"这条叙事逻辑：一条回复消息的内容可能依赖原消息，若某个副本先看到回复再看到原文，它相当于观察到了信息从未来流向过去。happens-before 恰好刻画了"信息可能流动过"的路径——同一进程的先后两步，或经由一次消息收发——因此按它约束交付顺序，就足以保证每个进程看到的历史都是一种自洽的讲法。同样重要的是它不约束什么：两条并发消息之间不存在信息流，谁先谁后对任何一方的内容都没有影响，强行统一它们的顺序需要付出全局协调的代价，因果广播刻意放弃这一点，换来无须共识即可实现的轻盈。

正例：进程 A 广播"提交事务 $t$"，进程 B 收到后广播"确认 $t$"。由于 B 的广播在接收 A 的消息之后，happens-before 成立，所有正确进程必须先交付"提交"再交付"确认"；若进程 C 先收到网络上跑得快的"确认"，实现会把它压在缓冲区里，直到"提交"到达并交付。用向量时钟检查即为：B 的消息携带的时钟显示"依赖 A 的第 1 条消息"，C 发现自己尚未交付该条，于是等待。

边界情形：若 C 与 D 并发广播两条独立更新，接收者甲可以先交付 C 的、接收者乙先交付 D 的——这完全合法，因为因果广播刻意不规定并发消息的先后。普通原子广播公理库原子广播Atomic broadcast · Total-order broadcast所有正确进程以同一总序交付广播消息。会让所有进程对这两条消息采用同一顺序，却可能反过来打乱有因果关系的消息，因此两种规格彼此并不包含；若两类保证都需要，应采用同时尊重因果关系的全序广播。另一个易忽略的边界是"库外因果"：happens-before 只追踪系统内的消息收发，若两个用户通过电话等旁路信道传递了信息，再各自广播，系统视这两条消息为并发，因果广播不会（也无法）保护这种系统外的因果链。

用户先发布帖子 $m_1$，另一用户读到后发送回复 $m_2$，任何副本都不应先显示回复再显示原帖。两位互不通信用户同时发帖属于并发消息，不同副本可交换顺序而不违反因果广播。仅保持每个发送者 FIFO 顺序不足以捕获跨发送者的间接因果。

因果广播在异步崩溃模型中可以直接实现，不像原子广播那样与共识公理库分布式共识Distributed consensus · Consensus problem多个进程在可能故障和通信延迟下对一个值达成一致的任务。等价、受同一终止性不可能结果约束。协作编辑与聊天系统可用它保证回复消息不先于原文交付；操作型无冲突复制数据类型公理库无冲突复制数据类型Conflict-free replicated data type · CRDT通过单调状态合并或可交换操作在无协调下保证副本收敛的数据类型。也常把因果交付列为传播前提，再单独证明并发操作可交换。

因果一致性公理库因果一致性Causal consistency · Causal memory要求每个观察者的读写可见顺序都扩展程序顺序与读来源所生成因果偏序的一致性模型。约束的是读写版本对客户端的可见顺序，还要定义 reads-from、会话上下文和读返回值；因果广播只约束消息交付。前者可以用后者作为传播层，却仍需把消息映射为版本可见性，因此两页不能互作同义定义。选择广播规格时，应分别判断是否需要保留因果先后、统一并发消息顺序，或同时需要两者。