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