分布式系统中的处理失败问题

分布式系统是由一组独立的计算机组成的，这些计算机对客户端来说仿佛是一个统一的、具有凝聚力的整体。 在任何分布式系统中，都有多个组件协同工作以完成某项任务。 随着系统变得越来越复杂，包含的成分也越来越多，故障发生的可能性就会上升，从而导致系统的可靠性下降。 换句话说，在分布式系统中，总会有一些系统出现故障，而另一些系统则能够正常运行。 这可以被视为一种部分失败。 部分失败的情况是无法预测的，因为消息在网络中传输所需的时间是不确定的。我们无法确定是否发生了成功或失败的情况。 因此，我们根本不知道在这段时间里哪些系统出现了故障，也不清楚某个系统是否真的发生了故障。 由于这个原因，处理分布式系统的问题相当困难。 在分布式系统中，可能会出现部分故障的情况，比如节点崩溃或通信连接中断等。 因此，在进程间通信过程中出现的此类错误可能会导致以下问题：

• 请求消息丢失
• 响应消息丢失
• 请求执行失败
• 有可能，您的请求已经被暂时搁置了。
• 远程节点正在休息，进行垃圾回收操作。
• 该请求已被远程节点处理，但响应信息在网络传输过程中丢失了。
• 由于我们的网络处于拥塞状态，因此响应时间会有所延迟。

请求消息丢失：这种损失可能发生在发送方与接收方的通信链路出现故障时，或者因为接收端的节点在请求消息到达时并未被激活。

2. 响应丢失：无法接收到响应消息。这种损失可能发生在发送方与接收方的通信链路出现故障时，或者因为发送方侧的节点在收到响应消息时并未被激活。

3. 请求执行失败：这种情况发生在接收节点的处理请求过程中发生崩溃时。

为了解决这些问题，消息传递系统采用了可靠的IPC协议。该协议允许在固定的时间间隔后重新传输消息。接收端的内核会向发送端的内核返回确认消息。

在两个进程之间的客户端-服务器通信中，使用了以下可靠的IPC协议：

• 四消息可靠IPC协议
• 三消息可靠IPC协议
• 两消息可靠IPC协议

四消息可靠IPC协议：在这两个进程之间的客户端-服务器通信过程中，其运作方式如下：

• 该请求消息是由客户端发送给服务器的。
• 在收到请求消息之后，服务器的内核会向客户端机器上的内核发送确认消息。如果确认消息未能在设定的时间范围内被接收，那么客户端机器的内核也会重新发送该请求消息。
• 当服务器处理完客户的请求后，就会向客户发送一个回复消息。该消息中还会包含处理的结果信息。
• 现在，客户端的内核会向服务器机器的内核发送确认消息，以表示已经收到了响应。如果确认消息在设定的时间范围内没有收到，那么服务器机器的内核也会重新发送该确认消息。

2. 三消息可靠IPC协议：当客户端进程接收到成功的响应时，就说明请求消息已经由服务器在客户端-服务器通信过程中接收到了。因此，这一过程就是基于这样的概念来进行的。

• 该请求消息是由客户端发送给服务器的。
• 在收到请求消息之后，服务器会发送包含处理结果的回复消息给客户端。如果回复消息未能在设定的时间内被接收，那么客户端机器的内核还会再次发送请求消息。
• 当服务器处理完客户的请求后，会向客户端发送回复消息。该消息中包含了处理的结果。此时，客户端的内核会向服务器的内核发送确认信号。如果在一定时间内没有收到确认信号，那么服务器中的内核会重新发送响应消息。

如果请求的处理时间过长，那么就会出现问题。因为消息的重传只能在固定的时间间隔内进行，而这些时间间隔通常设置得比较长，这样可以避免不必要的重复传输。另一方面，如果为请求处理分配的时间过短，那么就会导致请求消息被多次发送。为了解决这个问题，可以使用以下协议：

• 客户端向服务器发送了一个请求消息。
• 当服务器接收到请求时，内核会立即启动计时器。当客户端在请求处理完成后从服务器端收到回复消息时，该消息就相当于对请求消息的确认。否则，服务器会发送单独的确认消息来确认请求消息。如果超过超时时间仍未收到确认消息，那么就需要进行重新传输操作了。
• 当客户端收到回复消息后，客户端的内核会向服务器的内核发送确认消息。只有当确认消息在指定的超时时间内没有收到时，服务器的内核才会重新发送回复消息。

3. 双消息可靠IPC协议：“双消息可靠IPC协议”用于两个进程之间的客户端-服务器通信。为了实现这一协议，可以开发一个消息传递系统。

• 客户端向服务器发送了一个请求消息。当该请求被发送后，客户端会被阻塞，直到服务器做出响应为止。
• 当服务器完成对客户端请求的处理之后，它会向客户端发送一个回复消息，其中包含了处理的结果。如果响应在指定的超时时间内没有收到，那么客户端机器的内核会重新发送该请求消息。

幂等性：

所谓“幂等性”，本质上指的是“可重复性”。也就是说，用相同的参数多次执行某个幂等操作，最终会得到相同的结果，而不会产生任何副作用。

在Multidatagram消息中，对丢失或不符合序列规则的数据包进行跟踪是必需的。

完整的传输意味着，所有消息的数据包都被发送到的进程所接收。因为，每个数据包对于多数据报消息的顺利传输来说都是至关重要的。 因此，最简单的做法就是分别处理每个数据包（这种协议被称为“停止等待协议”）。 在多数据报消息中，第二种处理方式（称为Blast协议）是：为所有数据包使用一个单一的确认包来发送确认信息。 不过，使用这种方法时，如果某个节点发生崩溃或通信链路出现故障，那么就会引发以下问题：

• 在通信过程中，多数据报消息中的一个或多个数据包可能会丢失。
• 数据包的乱序接收。

为了处理这些问题，采用了位图方法来识别消息数据包。

在分布式系统中，还可能出现其他各种类型的故障：

• 应用服务器可能会因为多种原因而崩溃，包括数据中心出现故障、CPU/内存使用量过高、应用程序代码存在缺陷、停电、自然灾害等。
• 在分布式系统中，各个服务可以通过HTTP/TCP协议直接进行通信。然而，两个服务之间出现通信失败的情况可能是由多种原因导致的，比如服务不可用、网络问题、依赖关系故障等。由于这种连锁效应，其中一个服务可能无法履行其职责，进而可能导致整个系统崩溃。
• 这种情况也可能发生：某个应用程序无法读取或写入数据库。这种情况的发生原因多种多样，比如网络问题导致数据库无法使用、由于CPU/内存占用过高而导致数据库运行受阻，或者数据库服务器出现故障等。因为数据在任何系统中都是最重要的组成部分，所以处理数据库故障至关重要。
• 消息和事件是通过队列和流来传递的，这些机制是非常重要的组成部分。然而，基础设施方面的问题、多个节点无法访问、同步副本的数量未达到最低要求等等，都可能导致这些问题的发生。

上述分布式系统中出现的其他问题，可以通过以下方式来处理：

• 如果应用服务器中的某个节点出现故障，那么就需要用一个新的节点来替换它。这种替换操作可以通过自动化脚本或人工干预来完成。如果整个集群或应用服务器都出现故障，可以使用备份集群来应对这种情况。此时，可以将流量引导到位于同一地区或不同地区的备用集群上。
• 如果出了什么问题，可以根据重试策略来再次尝试。重试可以缩短间歇性故障的恢复时间，但也可能使问题更加严重，因为系统需要更多时间来恢复。
• 缓存还可以作为后备手段，用于存储那些需要重复访问的数据。这样，在下游系统出现故障时，仍然可以从中获取一致性的数据。不过，由于缓存在某些情况下可能并不适用，因此当出现故障时，应该采取适当的处理方式——而不是返回错误信息，而是返回适当的降级后的结果。
• 处理数据库故障的方式，取决于所处理数据的关键性。拥有一个备份数据库，并将所有数据从主数据库中复制出来，这样可以降低因单个数据点故障而带来的风险。在主要数据库恢复之前，可以利用这个备份数据库来满足数据的需求。 在数据库准备好再次承担负载之前，应用程序可能会采用备用策略来处理后续的请求。 数据读取可以来自缓存或冗余数据库。
• 将消息推送到副本流或队列中，以增加冗余性。这样一来，即使是事务性通信信息也不会丢失。在不同的数据中心和可用区创建资源是实现冗余的最佳方式。如果消息属于第三层，那么可以将其暂时存储到事务日志中。应用程序可以定期尝试将消息重新放入事务日志中，直到流恢复正常为止。