摘要

  • RFC 992 把进程故障与恢复作为有序组播事件，使仍在运行的成员按照相同的成员视图顺序处理消息。
  • GBCAST 管成员变动，ABCAST 管共享操作的共同次序，CBCAST 保留因果顺序，同时让互不相干的工作并行。

设想三份相同的任务队列。客户发来“取出队首任务”，消息还在路上，其中一台机器倒下了。两台幸存者都能继续工作，却可能看到两种顺序：甲先收到取任务指令，乙先收到故障通知。机器没全死，服务倒先精神分裂了。复制本来是为了防止一台机器毁掉全局，结果一份不同的事件年表就够它们各走各路。

Kenneth Birman 和 Thomas Joseph 在 1986 年 11 月发表的 RFC 992 中，把这个竞速问题摆在康奈尔 ISIS 项目的中心。此前的 RFC 966 与 RFC 988 已讨论主机组和多播。难点发生在收件名单变动时：发给“整个组”的一条消息，到底该由哪一版名单来解释？若名单更新和业务消息各跑各的，收件人就会在最需要一致的时候各执一词。

他们把最重的一把锤子叫 GBCAST。成员恢复时，用它宣布自己回来；成员故障时，系统代它向组内宣布离开。死掉的进程没法自己说再见，协议只好替它发言。这个通知与普通多播排在同一条秩序里。如果某个成员先看到业务消息、后看到故障通知，那么重叠的收件人也要按这个顺序看；故障进程先前发出的消息，也排在它的故障通知之前。每台机器维护一份 VIEW，即自己认为的成员名单。名单不会在全球同一毫秒跳变，但成员看到的变更序列相同，同一条多播到来时所处的 VIEW 也相同。

最贵的礼仪不能拿来招待每封信。GBCAST 协调成本高，作者让 ABCAST 和 CBCAST 分担日常工作。ABCAST 保证带有相同标签的多播在共同收件人处顺序一致，适合复制队列的操作。CBCAST 只要求有因果关联的消息按先后来，独立消息可以各走各路。三种工具不是花哨的缩写比赛，而是一张成本表：什么时候必须让所有人翻到同一页，什么时候只要别把原因排到结果后面。

论文采用“故障即停止”的模型，并假设现场有机制发现进程故障。作者还拿当时工作站的时钟精度和站点间通信时延说明，单靠钟表裁决消息竞速很别扭。这是 1980 年代实验室里的参数，不是今天的数据。文中提到 ISIS 先前原型已完成，新实现仍在推进。它留下的历史问题却很耐用：成员死去会改变后续指令的含义，因此“它死了”本身也必须是一条被正确投递的指令。

故障机器缺席会议无可厚非。幸存机器至少应该拿到同一份会议记录。