虚同步为我们提供了一个组播组成员管理和通信协调模型。通过虚同步,进程可以随时加入或离开一个组播组,同时通过虚同步还可以保证原子组播,即确保信息要么传送到组中的所有进程,要么没有进程能交付该信息。即发送者在组播过程中崩溃,虚同步保证信息要么会被发送到所有剩余进程,要么会被每个进程忽略。
组视图
虚同步将组视图定义为当前在组播组中的进程集合。每个组播信息都与唯一的群组视图相关联,在该组视图中,信息应发送给所有组视图成员,或者不发送给任何成员。同时系统中的每个进程都有相同的群组视图,即组视图中成员都应同意消息应交付。
群组成员可接收三种类型的消息:
- 常规消息:普通应用程序消息。
- 视图更改:视图更改消息,用于通知进程组内成员的更改。
- 检查点请求:如果进程加入了一个组,它就需要更新其状态(内部状态和存储数据),以便包含最新版本并与其他副本同步。为此,进程可以向组中的任何其他进程发送检查点请求消息,该进程会将其当前状态发送给请求进程。
虚同步本质是保证即所有组播都发生在视图变化之间。换一种说法,组视图变更就像一道屏障,任何组播都无法通过。视图更改时,所有正在传输的组播都会在视图更改生效前完成。每当某个进程加入或离开某个组,组视图都会发生变化。此更改信息将传播给所有组员。毕竟,我们需要确保每个人都拥有相同的组视图。组视图信息通过一条组视图更改多播消息共享。
一种虚同步实现
两个前提假设:
- 点到点的可靠传输,通过TCP来实现,多播通过多个单播实现,即发送方向每个组成员发送消息
- 点到点的有序传输,即对接收方来说,接收到来自一个源的消息的顺序与消息的发送顺序一致
每个进程通过一个可靠多播向所有组成员发送消息,接收进程异步确认这些消息。当发送方收到每个组成员都已收到特定消息的确认时,该消息现在被认为是稳定的,可以传递给应用程序。发送方将向组成员发送消息,通知他们哪些消息是稳定的。这些消息通常附加到其它消息包中一起发送。
如果发送进程在多播中途死亡,那么它已经发送但未被确认的任何消息都是不稳定的,并且可能没有到达组中的所有进程。死亡的发送方从组中删除,强制发生视图更改。在视图更改期间,每个进程将其所有不稳定的消息发送给所有组成员并等待确认。进程接收到的任何非重复的消息都被认为是稳定的,并被传递给应用程序。最后每个进程向组成员广播一个刷新消息。组成员在将所有现在稳定的消息传递到应用程序之后确认收到的每条刷新消息。确认所有刷新后,视图更改完成,如下图所示。
图中进程1担任组管理服务的角色,组成员服务(GMS)提供了一致的组成员视图。如果任何进程怀疑某个进程失败,它会通知GMS,GMS会将其从组中删除并发起视图变更。如果进程想要加入一个组,也是通过GMS服务。如果GMS服务进程死亡,可以从其余的幸存的成员可以选择另一个流程来担任即可。
虚同步模型的最大问题是不能处理网络分区。因为框架假设它们不会发生。网络分区的问题需要使用分布式协调算法来解决。