分布式系统心跳协议的设计

应用层心跳必不可少：
1、操作系统崩溃导致机器重启, 没有机会发送 FIN 分节
2、服务器硬件故障导致机器重启, 也没有机会发送 FIN 分节
3、并发连接数很高时, 操作系统或进程如果重启, 可能没有机会断开全部连接, 即 FIN 分节可能出现丢包, 但没有机会重试
4、网络故障, 连接双方能得知这一情况的唯一方案是检测心跳超时

为什么 TCP keepalive 不能代替应用层心跳?
心跳除了说明进程还在、网络通畅, 更重要的是表明应用程还能正常工作;
而 TCP keepalive 由操作系统负责探查, 即使进程死锁或阻塞, 操作系统也会如常收发 TCP keepalive 消息, 对方无法得知这一异常.

进程 C 依赖于 S, 则一般 S 为 sender, C 为 receiver.

心跳设计关键：（高置信度与低反应时间不可兼得）
1、通常 sender 的发送周期和 receiver 的检查周期相同, 为 T; timeout 时间一般为 2T
2、T 越小, 开销越大; T 越大, receiver 检测到故障的延迟也就越大
3、心跳信息应该包含发送方的标识符; 建议也包含当前负载, 便于客户端做负载均衡
4、如果 sender 和 receiver 之间有其他消息中转进程, 那么还应该加上 sender 的发送时间, 防止消息在传输过程中堆积而导致假心跳
5、要在工作线程中发送, 不要单独起一个”心跳线程”, 防止伪心跳（防止工作线程死锁或阻塞时还在发送心跳）
6、与业务信息用同一个连接, 不要单独用”心跳连接”, 防止伪心跳（如果验证的不是收发业务数据的 TCP 连接畅通则意义不大）