“因果一致性约束的是读写版本对客户端的可见顺序,还要定义 reads from、会话上下文和读返回值;因果广播只约束消息交付。前者可以用后者作为传播层,却仍需把消息映射为版本可见性,因此两页不…”
形式陈述 ​
在复制或共享内存系统中,先把一次读写执行投影为带会话标识、对象、值与 reads-from 关系的操作序列
历史满足因果一致性,粗略说是每个进程或客户端的可见序都必须扩展这一因果偏序:若
不同论文对读操作是否进入序关系、同一写是否必须立即可见、冲突写如何选值采用不同形式化。完整规格需要固定对象的顺序语义、写的唯一标识、reads-from 关系、会话迁移方式与可见性闭包。Lamport 因果关系提供数学骨架,但存储系统还要说明哪些客户端观察生成边;物理时间较早或先到达某副本,本身都不是因果证据。
基本因果一致性不包含最终传播、并发更新收敛、读己之写、单调读或实时新鲜度等全部体验。会话保证可以从恰当维护的因果上下文导出,也可以由 API 单独承诺;causal+ 一类加强还要求并发冲突以确定方式收敛。若把这些附加条款直接塞进基本定义,就无法准确比较只保因果序与同时保收敛的系统。
直觉 ​
因果一致性保护“先有原因,后有结果”的可见叙事。客户端根据一条帖子写出回复,回复便携带对原帖的依赖;任何展示回复的副本都应先具备原帖。两位互不观察对方的用户独立发帖则没有信息流,系统无需为他们支付全局定序成本。
放弃并发写的统一顺序,是因果一致性获得低协调和地理可用性的关键。每个观察者都读到一个尊重依赖的世界,却不必立即与所有其他观察者共享同一条总历史;这比顺序一致性弱,也比只承诺最终收敛多了一层中间可见性约束。
例子与边界 ​
用户 A 发布帖子
仅让每个发送者的更新 FIFO 到达不足以捕获跨客户端依赖:B 的回复由另一发送者产生,却依赖 A 的帖子。系统可用版本向量、显式依赖集合或因果广播传播这一关系;广播是消息交付规格,存储一致性仍需把交付结果映射为版本可见性和读返回值,两者不能直接等同。
因果一致性也不自动带来收敛。两个副本并发写同一字段,各自先显示本地值;即使所有因果依赖都按序传播,若冲突处理采用“收到即覆盖”,交换更新后仍可能留下相反结果。最终一致性或 CRDT 合并规则负责停止更新后的收敛,因果一致性负责传播期间不颠倒依赖,两个维度可以单独成立或同时提供。
推论与应用 ​
因果一致存储通常让客户端携带一个因果上下文,写操作继承此前读到的版本,副本只在依赖满足后公开新版本。会话跨副本迁移时若丢掉上下文,新副本可能无法知道客户端已经观察了什么;sticky session、依赖令牌或版本向量分别以不同方式保存这份信息。
协作应用、社交时间线与离线优先系统常能接受并发更新暂时异序,却不能接受回复先于原文、撤销先于操作等因果倒置。是否还需要统一冲突结果、实时读取或事务原子性,应作为独立规格叠加,而不是从“causal”标签中推断。
参考资料
- Phillip W. Hutto and Mustaque Ahamad, “Slow Memory: Weakening Consistency to Enrich Concurrency,” ICDCS 1990, pp. 302–311。
- Mustaque Ahamad et al., “Causal Memory: Definitions, Implementation, and Programming,” Distributed Computing 9, 1995, pp. 37–49。
- Wyatt Lloyd et al., “Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS,” SOSP 2011, pp. 401–416。