可靠性的几种情况

*Request-reply：如果服务器死机（在处理请求时），客户端可以解决这个问题，因为它不会得到回复。然后它可以气急败坏地放弃，等待并稍后再试，找到另一个服务器，等等。至于客户的死亡，我们可以暂时将其视为“别人的问题”。

*Pub-sub：如果客户端死了（得到了一些数据），服务器就不知道了。Pub-sub不会将任何信息从客户端发送回服务器。但是客户端可以在带外联系服务器，例如通过request-reply，并询问“请重新发送我错过的所有内容”。至于服务器死机，这超出了这里的范围。订阅者还可以自我验证他们运行的速度是否太慢，如果他们运行得太慢，则可以采取措施（例如，警告操作员并停止运行）。

*管道：如果worker（在工作时）死亡，前方单元不知道。管道就像时间的齿轮，只在一个方向上工作。但是收集器可以检测到一个任务没有完成，并向前方单元发送一条消息，说“嘿，重发任务324！”如果前方单元或收集器死亡，那么无论哪个上游客户端最初发送的工作批次都会等待超时，并重新发送整个批次。它不优雅，但系统代码确实不会死得太频繁。

将客户端连接到服务器的方法大致有三种。每种方法都需要一种具体的可靠性方法：

*多个客户端直接与一台服务器通信。用例：客户端需要与之通信的一个知名服务器。我们要处理的故障类型：服务器崩溃和重启，以及网络断开连接。

*多个客户端与一个将工作分配给多个worker的代理进行通信。用例：面向服务的事务处理。我们旨在处理的故障类型：服务崩溃和重新启动、服务忙循环、服务过载、队列崩溃和重新启动以及网络断开连接。

*多个客户端与没有中间代理的多个服务器通信。用例：分布式服务，如域名解析。我们旨在处理的故障类型：服务崩溃和重启、服务忙循环、服务过载和网络断开连接。