前言

      在写这篇文章之前,我曾对HeartBeat做过诸多的研究,也做过诸多的项目,在这些项目中,有客户端为了维持状态,而定时向服务端发送的HeartBeat;有服务端为了维持客户端连接状态而处理HeartBeat等,但是怎么说,无外乎两种状态,HeartBeat要么存在于客户端,要么存在于服务端,其本身具有无状态性,不和数据库进行任何交互,上一条HeartBeat和下一条HeartBeat无特别的必然联系。

那么,HeartBeat究竟是什么,有什么表现形式呢?

      首先,HeartBeat从字面意思上解释,就是心跳,心跳都是有一定规律的,比如说,3秒跳一次,5秒跳一次,甚至60秒跳一次等。所以说,HeartBeat的基本单位一般都是以秒来计数的。并且两次HeartBeat间隔的时间不能过长,如果间隔时间过长,比如说两三个小时跳一次,那么HeartBeat也就失去了它本来的意义了,至于原因的话,我方后面讲。它在程序中,主要是为了检测状态的,比如在客户端,连接到服务端后,每隔10秒钟会上传一次心跳包,服务端接收到此心跳包,就会拆包分析,然后重置客户端的心跳计数,如果连续3次,或者4次没有收到客户端传来的心跳包,那么就视为客户端掉线。有人可能就说了,客户端下线的时候,直接向服务端发送一个下线通知不就行了,还用什么心跳包来检测掉线呢? 其实不然,客户端的掉线,是有多种情况的,每个用户不一定都会发送掉线通知,比如他们家里停电了,或者电脑重启了,或者浏览器崩溃了等等,这些情况下客户端还没来得及发送掉线通知就挂了,所以增加心跳检测是应对这种掉线的比较好的方式,它有助于让服务器保存活动的客户端连接,去掉死链,从而提升性能,规避风险。

      上面的这种方式,我们可以用下图的流程来表示:

      其次,就是HeartBeat的表现方式,在不同人的程序里面,是不同的,但是肯定相同的地方在于,他们都会有心跳标识符的。比如我这里规定和服务端的通讯协议:  信息头|功能码|数据部分|CRC ,其中功能码 006就代表心跳包。那么在客户端我就会这样封包: dst|006|datadata|0013 然后发送给服务端,服务端收到信息后,先进行CRC校验以便确定信息的正确和完整性,然后通过拆包得知客户端传来的是心跳包,那么就会将对应的客户端里面的心跳计数重置即可。其实就是这么简单。

      这只是比较普通一些的心跳,对于不同的业务系统来说,可能会有不同的表现形式,比如对咱们RSA系统来说,如果要想重构这种心跳包,需要为不同的activity类型规定不同的心跳包,比如对于按钮点击,我们可以专门定义一个按钮点击心跳包;对于拖拽,我们可以定义一个拖拽心跳包等,服务端接收以后,能够处理。并且这种心跳包的传输是基于socket传输的,而不是目前的借助于数据库,在性能上和多样性方面,更加的高效。之所以RSA在以前没有采用这种方式,应该是当时还没有websocket吧。

      最后我们需要说到的一个问题就是HeartBeat频繁的发送会不会在业务拥塞的时候,造成性能问题。针对这种场景,已经有了适合的解决方案,那就是在业务场景拥挤的时候,我们只需要将HeartBeat的发送和处理放到其他线程上即可,并且改变HeartBeat的发送时长,比如从原来的十秒,改成现在的三十秒,这样就能在很大程度上提高性能;当业务不拥塞的时候,我们就可以把HeartBeat的发送和处理放到业务线程上,并适当减少HeartBeat的发送时间,也都是可取的。这种配置如果做成可自动切换的,就更好了。

实际例子

      我们讲了这么多,接下来看看例子。这个是我写的一个小DEMO,用HeartBeat来检测聊天用户的掉线问题。

      基于SignalR的小型IM系统

 

posted on 2016-01-18 14:15  程序诗人  阅读(876)  评论(0编辑  收藏  举报