心跳 heartBeat 的不同场景下实现疑问

[frank1256]

我理解心跳就是像是微信是否在线的概念。集群中判断节点是否可用就得有 heartBeat 的检测机制。

之前看过一些开源的代码。看到有两种方式。一种是通过 api 接口，由客户端不断的发送 http 请求。服务端来判断是否在线。回调通知的时候通过 /callBack 接口

还有一种是通过长链接。tcp 建立链接后，keepalive ，在同一个链接上发送和接收消息。好像用在实时推送消息更多？

第二种需要缓存当前的链接，意味着更大的缓存，更多的资源消耗吗？达到更快的推送速度？

有大佬指点指点吗，对心跳这块不是很了解

[sunny352787]

要不说说你要干啥？游戏、App 、网页都是不同的心跳策略，对应不同的需求

[THESDZ]

看你的心跳时效性要求，要求不高就第一种，否则就第二种吧。

建议状态由外部传入，即：当前心跳的应用是哪一个，而非通过会话之类的保持，接口（长连接）本身不要由状态。

[southsala]

你想了解啥，两种都实际用过之后你就明白优缺点和适用范围

[frank1256]

@sunny352787
@THESDZ
@southsala
目前这样的一种场景，任务调度器。类似开源的 xxljob ，这样的。我看了他提供的 go 客户端是通过 callback 接口回调，和 heartbeart 接口做心跳的。我也想实现一个任务调度的服务，在判断节点是否在线的场景里，我在考虑能不能用长链接呢，所以参考了开源的作品，就不太理解为什么他没有用长链而采用的是接口的方式

[sunny352787]

@frank1256 这其实无所谓啊，还是看你需求，像我这边的任务调度服务就是接收 gRPC 双向 stream ，其他服务向任务调度服务发起连接然后保持，这样也不用自己维护心跳 gRPC 全帮你处理了，还可以添加多个地址做热备什么的。

感觉你的问题和心跳没啥关系，应该是先考虑整体系统架构，服务之间的网络是内网还是公网，要求时效性如何，所有服务都是你自己可控还是有其他外部的访问需求，确定好了你的网络通讯方式，那你的在线检测机制也就差不多定了，你现在这个思考方向我感觉你是考虑反了

[jimrok]

@frank1256 用长连接，一般是避免没有数据传送的场景，这种场景下，交换机一般有 timeout 的处理，会把这个连接中断掉。所以，一些推送应用，都需要定时发送 ping 的包给 server ，让这个 tcp 一直存活。

[frank1256]

@jimrok 了解了

[flyqie]

看个人喜好。

我用过三种方式: slave 主动发 http 请求，master 主动发 http 请求，单独或者复用长链接。

感觉主要还是跟业务有关，没有绝对的优劣。

有些时候如果确定消息频次够的话，甚至都可以不用任何心跳。

心跳主要有两种方式，你说的这个应该是业务层面上的健康检查，还有一种是像楼上老哥所说的为了防止连接被交换机等设备干掉。

[southsala]

因为第一种跟简单可靠，要求不高还是这种更简便

[flyqie]

@flyqie

心跳主要有两种方式 -> 心跳主要有两种用途

[sampeng]

你说的两种从技术上没本质区别。。http 也有 keepalive

[codergmc]

看你应用的连接方式，你的数据是走的 http 交换的，用第一种，数据用 tcp 交换的用第二种，另外心跳的实现不要基于协议的 keepalive 机制，要在应用层自己去实现