2019-11-14对于 Slave 所在服务器故障的情况，由于服务器宕机或重启，那么系统环境等均不工作了，这种情况 TCP 长连接也无法进行探测了，也就是说 TCP 长连接方法在这种场景下无法判断节点是否故障。
为什么？？？难道重启或岩机，还能tcp长连接？反过来，心跳也能检查进程退出吧，因为如果进程退出也不会有心跳吧 2 3
2019-11-20如何避免出现”双主“呢
https://www.iteye.com/blog/1316478764-2206068
这篇博客 给了一个一种颁发有效期的机制。
其实都会依赖一个高可用的监控系统来监控应用系统主节点的状态，根据其状态做判断 2
2019-11-16那假设出现双主的场景，一般是通过什么有效策略去解决呢，或者有没有好的办法尽量去避免这种情况 1
2019-11-13非集中式的心跳机制好多是基于Gossip协议做的，比如consul，redis。 1
2019-11-13关于检测存活还是有些疑问。长连接为什么不能检测机器故障呢？服务器宕机时长连接也会断开的吧。
另外非集中式的下线条件是过半数以上机器标记为不可达才会认为机器下线对吗？下线后监控的顺序会发生改变吗？ 5 1
2019-11-13判断节点是否存活的方法中，基于长链接的方法是利用了TCP层本身的机制；而基于心跳的方式是基于应用层自己的方法去实现。
如果用OSI模型来描述，就是前者是四层的存活检测，后者是七层的存活检测。 1
2020-01-14这个专栏写的真好，我订阅的晚，一口气看到这里。老师的讲解即有生动的例子，也有表格的总结对比，一路看下来收获很多!感谢🙏老师
2019-11-15我以为就我看不到心跳检测，原来大家都有疑问。为什么TCP断开就判断是程序挂了，心跳就是服务器挂了？？不明白 1
2019-11-13tcp长连接和心跳那块儿不是很理解，我觉得探测slave进程故障才应该用心跳，探测机器故障长连接是可以的。
slave进程如果还活着但是死锁卡住了，其实长连接是探测不到的，内核协议栈会正常回复探测报文。slave进程如果异常退出，但是操作系统没死，这时socket关闭时有机会发fin，master会收到fin（不考虑网络丢失），所以可以很快知道slave进程死了。如果slave所在机器宕机来不及发fin，master长连接不停探测，最终是会发现机器死了的。
我认为心跳就是探测slave进程是否死锁卡死等这种场景的，slave进程死了就认为机器也挂了，不管物理机器是否宕机了。 1
2019-11-13收获满满