这是双向心跳的正确机制吗？

Question

我有一个软件应用程序，我们有两个服务，比如A和B。

A将一些长时间运行的工作(由id跟踪)委托给异步完成的B。他们都是通过HTTP聊天的。

在提交作业后，A定期执行传递id的getStatus调用。

考虑到任何一个A或B都可能死掉，我需要处理失败场景。

我正在考虑使用上面的getStatus调用作为2 way heartbeats，对于不愉快的情况(以及它们在->之后的处理)，它的行为如下：

1. A unable to reach B -> heartbeat would timeout/connection refused, leading A to think work has failed
2. A is able to reach B but B has crashed and restarted -> heartbeat is treated as unknown, leading A to think work has failed
3. A dies/becomes unresponsive -> B misses few heartbeats and cancels its work(via timer), another A would reschedule this

上面的heartbeat处理对于A和B来说是一个很好的方法来了解彼此的活性吗？

Answer 1

利用我使用自定义UDP接口所做的工作，您需要记住一些关于活性检查的属性：

• 超时意味着另一个系统无法到达。
• 主动拒绝意味着它在那里，但它不能接任何电话
• 成功接收消息意味着另一个服务已启动并正在运行。
• 使用UDP，您可以发送一条消息，但无法保证它已收到。
• 不能保证在成功的心跳之后，服务还会继续运行。

使用HTTP协议，您至少有信心，如果您接收到状态代码，您已经成功地连接到了相反的服务。您将需要建立时间阈值，在这里，该活性信号仍然被认为是新鲜的。这取决于你的特殊需要。例如，在基于UDP的系统中，我有以下阈值：

• 小于或等于6s，信号是新鲜的。
• 在6s到12s之间的信号是陈旧的或不确定的。
• 超过12s，另一个系统被认为是脱机的。

这些可能对你来说太紧了。这里的权衡是，你给予更多的时间被认为是一个新鲜的活性信号，更不确定的是，实际上.但是，越紧的门槛，您就越有可能给自己提供拒绝服务攻击。

就您的情况而言，我在这两个服务中都有以下内容：

• 跟踪上次成功发送HTTP消息的时间戳
• 同样的时间戳也可以用于成功地接收消息。
• 具有一个本地函数，该函数使用当前时间戳中的增量和最后一次成功通信来指示“新”、“不确定”或“陈旧”信号状态。
• 在“新鲜”阈值1/2处有一个计时器触发器来调用活性检查.但是，每次您有一个事件，将更新该本地时间戳，重置那个定时器。