我理解心跳就是像是微信是否在线的概念。集群中判断节点是否可用就得有 heartBeat 的检测机制。
之前看过一些开源的代码。看到有两种方式。一种是通过 api 接口，由客户端不断的发送 http 请求。服务端来判断是否在线。回调通知的时候通过 /callBack 接口
还有一种是通过长链接。tcp 建立链接后，keepalive ，在同一个链接上发送和接收消息。好像用在实时推送消息更多？
第二种需要缓存当前的链接，意味着更大的缓存，更多的资源消耗吗？达到更快的推送速度？
有大佬指点指点吗，对心跳这块不是很了解
 |
1
sunny352787 Jul 18, 2022
要不说说你要干啥？游戏、App 、网页都是不同的心跳策略，对应不同的需求
|
 |
2
THESDZ Jul 18, 2022
看你的心跳时效性要求，要求不高就第一种，否则就第二种吧。
建议状态由外部传入，即：当前心跳的应用是哪一个，而非通过会话之类的保持，接口（长连接）本身不要由状态。 |
 |
3
southsala Jul 18, 2022
你想了解啥，两种都实际用过之后你就明白优缺点和适用范围
|
 |
4
frank1256 OP @sunny352787
@THESDZ @southsala 目前这样的一种场景，任务调度器。类似开源的 xxljob ，这样的。我看了他提供的 go 客户端是通过 callback 接口回调，和 heartbeart 接口做心跳的。我也想实现一个任务调度的服务，在判断节点是否在线的场景里，我在考虑能不能用长链接呢，所以参考了开源的作品，就不太理解为什么他没有用长链而采用的是接口的方式 |
|
5
sunny352787 Jul 18, 2022
@frank1256 这其实无所谓啊，还是看你需求，像我这边的任务调度服务就是接收 gRPC 双向 stream ，其他服务向任务调度服务发起连接然后保持，这样也不用自己维护心跳 gRPC 全帮你处理了，还可以添加多个地址做热备什么的。
感觉你的问题和心跳没啥关系，应该是先考虑整体系统架构，服务之间的网络是内网还是公网，要求时效性如何，所有服务都是你自己可控还是有其他外部的访问需求，确定好了你的网络通讯方式，那你的在线检测机制也就差不多定了，你现在这个思考方向我感觉你是考虑反了 |
 |
6
jimrok Jul 18, 2022
@frank1256 用长连接，一般是避免没有数据传送的场景，这种场景下，交换机一般有 timeout 的处理，会把这个连接中断掉。所以，一些推送应用，都需要定时发送 ping 的包给 server ，让这个 tcp 一直存活。
|
 |
8
flyqie Jul 18, 2022 via Android
看个人喜好。
我用过三种方式: slave 主动发 http 请求，master 主动发 http 请求，单独或者复用长链接。 感觉主要还是跟业务有关，没有绝对的优劣。 有些时候如果确定消息频次够的话，甚至都可以不用任何心跳。 心跳主要有两种方式，你说的这个应该是业务层面上的健康检查，还有一种是像楼上老哥所说的为了防止连接被交换机等设备干掉。 |
|
9
southsala Jul 18, 2022
因为第一种跟简单可靠，要求不高还是这种更简便
|
 |
11
sampeng Jul 18, 2022
你说的两种从技术上没本质区别。。http 也有 keepalive
|
 |
12
codergmc Jul 19, 2022
看你应用的连接方式，你的数据是走的 http 交换的，用第一种，数据用 tcp 交换的用第二种，另外心跳的实现不要基于协议的 keepalive 机制，要在应用层自己去实现
|
Select Language