两台服务器心跳同步

两台服务器心跳同步,第1张

服务器存储视频,带宽不够用,想用两台服务器,如何让所有服务器之间视频实时同步,可以用什么软件!当企业租用服务器,但是在数据同步的时候,又有着严格的要求,要求数据达到一致,在科技发达的今天,这又该如何做到了下面小Y为大家介绍两台服务器之间如何让数据同步的方法。
1、采用高可用sureHA软件镜像型,一台主服务器,一台备服务器,通过心跳线(网线)实时将数据备份,实现服务器双机互备的功能,此方式保证两台服务器之间数据的一致性。
2、采用高可用sureHA双机热备共享型。一台主服务器,一台备服务器,链接一台存储,将数据放到存储里面,实现数据的共享。此方式保证两台服务器之间数据的一致性。
3、可实现服务器虚拟化,把所有的服务器物理资源都整理成一个大的资源池,数据都存放在磁盘阵列上面,所有应用系统都通过调用磁盘阵列里面的数据,此方式保证两台服务器之间数据的一致性。
不管科技如何进步,在服务器方面还是需要人为的进行 *** 作和监督,未来数据有着更多的发展,服务器同步也成为不可缺少的一部分。如果亲们有服务器租用或者托管需求随时联系小Y,提供技术协助等服务。

简单地说是为了证明客户端和服务器还活着。websocket 在使用过程中,如果遭遇网络问题等,这个时候服务端没有触发 onclose 事件,这样会产生多余的连接,并且服务端会继续发送消息给客户端,造成数据丢失。因此需要一种机制来检测客户端和服务端是否处于正常连接的状态,心跳检测和重连截止就产生了。

思路是



服务端socket要做五件事,客户端socket要做三件事:

接下来双方就可以通过 read() 和 write() 函数通信了,双方也都可以通过 close() 函数主动断开连接。


上面的例子中,我们预期的效果是客户端点击一次发送,给服务端发送两条数据,服务端触发两次“收到客户端数据的回调”,然后分别打印:

但实际上两条数据被合并成一条数据发送给服务端了,服务端只触发了一次“收到客户端数据的回调”,也只打印了一次:

这就是 数据粘包——多条数据被合并成了一条数据传输。

我们知道TCP有个 发送缓存 ,有些情况下TCP并不是有一条数据就发一条数据,而是等发送缓存满了,再把发送缓存里的多条数据一起发送出去,这就会导致数据粘包。

此外TCP还采用了 Nagle优化算法 来打包数据,它会将多次间隔较小且数据量较小的数据自动合并成一个比较大的数据一块儿传输,这也会导致数据粘包。

处理数据粘包也很简单,核心思路就是: 发送方在发送数据的时候先给每条数据都添加一个包头,包头里存放的关键信息就是真实数据的长度,当然也可以存放更多的业务信息,此外包头的尾部还需要拼接一个包头结束标识——回车换行符,以便将来接收方读取数据时可以根据这个包头结束标识优先读取到包头数据。接收方调用指定的读取方法优先读取到包头数据,然后根据包头里的长度信息再去精准读取指定长度的真实数据,这样就可以读取到一条完整的数据了,然后再读取下一条数据就不会粘包了。

正常来说,socket连接一旦建立之后就会一直挂在那里,直到某一端主动断开连接。但实际上,运营商在检测到链路上有一段时间无数据传输时,就会自动断开这种处于非活跃状态的连接,这就是所谓的运营商NAT超时,超时时间为5分钟。 因此我们就需要做心跳保活——即客户端每隔一定的时间间隔就向服务端发送一个心跳数据包,用来保证当前socket连接处于活跃状态,避免运营商把我们的连接中断,这个时间间隔我们取的是3分钟,服务器在收到心跳包时不当做真实数据处理即可。

客户端主动断开连接时(如App退出登录或者App进入后台等场景),我们不需要做断线重连;其它情况下如果连接断开了(如服务器出了问题或者网断了等场景),我们就需要做断线重连,来尽量使连接处于正常连接的状态,这样才能保证业务的正常运行。 具体做法就是,当客户端检测到跟服务端断开连接时就启动第一次断线重连,2秒后启动第二次断线重连,再隔4秒后启动第三次断线重连,如果三次断线重连还没成功,就认为是服务器出了问题,不再重连。

tcp的断线检测,分为两种:

① 利用tcp自带的keep –alive机制

② 自己组建心跳包的方式向对端发送

通过Keep-alive机制对tcp的连接保持,也就是Tcp的心跳包,见MSDN:

If keep-alive is enabled for a TCP socket with SO_KEEPALIVE, then the default TCP settings are used for the keep-alive timeout and interval unless these values have been changed by calling the WSAIoctl function with the SIO_KEEPALIVE_VALS option The default settings when a TCP socket is initialized sets the keep-alive timeout to 2 hours and the keep-alive interval to 1 second

也就是说协议栈会在2小时后发送向对端发送请求包。默认情况下,此Keep-alive机制是关闭的。

Keep-alive默认下是关闭的,也就是本端与对端是除非程序主动send,是不会发送数据包(心跳包),既是,处理本端与对端的系统里的socket状态是不会变化,这里,如果对端当机(或者网线断掉),本端是无法知道对端socket已经关闭,所以本端的socket会一直的存在。

通过实验发现,客户端网线拔掉之后,此时服务端的连接依然存在。

所以,tcp只是数据的发送与接收,包括握手,断开以及rst,time_wait,close_wait 等等。

心跳包之所以叫心跳包是因为:它像心跳一样每隔固定时间发一次,以此来告诉服务器,这个客户端还活着。事实上这是为了保持长连接,至于这个包的内容,是没有什么特别规定的,不过一般都是很小的包,或者只包含包头的一个空包。

在TCP的机制里面,本身是存在有心跳包的机制的,也就是TCP的选项:SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般,如果只是用于保活还是可以的。

心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器,在一定时间间隔下发送一个空包给客户端,然后客户端反馈一个同样的空包回来,服务器如果在一定时间内收不到客户端发送过来的反馈包,那就只有认定说掉线了。 其实,要判定掉线,只需要send或者recv一下,如果结果为零,则为掉线。

但是,在长连接下,有可能很长一段时间都没有数据往来。理论上说,这个连接是一直保持连接的,但是实际情况中,如果中间节点出现什么故障是难以知道的。更要命的是,有的节点(防火墙)会自动把一定时间之内没有数据交互的连接给断掉
。在这个时候,就需要我们的心跳包了,用于维持长连接,保活。

在获知了断线之后,服务器逻辑可能需要做一些事情,比如断线后的数据清理呀,重新连接呀……当然,这个自然是要由逻辑层根据需求去做了。

总的来说,心跳包主要也就是用于长连接的保活和断线处理。一般的应用下,判定时间在30-40秒比较不错。如果实在要求高,那就在6-9秒。

1、 客户端每隔一个时间间隔发生一个探测包给服务器
2、 客户端发包时启动一个超时定时器
3、 服务器端接收到检测包,应该回应一个包
4、 如果客户机收到服务器的应答包,则说明服务器正常,删除超时定时器
5、 如果客户端的超时定时器超时,依然没有收到应答包,则说明服务器挂了

在客户端添加一个线程,用来发送在线的心跳包(此包生成的为时间戳,加密),服务器收到后,自动更新当前在线用户的在线时间
服务器添加一个线种,定时循环检测用户的时间戳,如果大于或小于设定时间(一般在30秒至1分钟)即判断为掉线并做掉线处理;
客户端防故意断网,如果发送信息失败,即断网

应用场景 :
在长连接下,有可能很长一段时间都没有数据往来。理论上说,这个连接是一直保持连接的,但是实际情况中,如果中间节点出现什么故障是难以知道的。

更要命的是,有的节点(防火墙)会自动把一定时间之内没有数据交互的连接给断掉。在这个时候,就需要我们的心跳包了,用于维持长连接,保活

什么是心跳机制?

就是每隔几分钟发送一个固定信息给服务端,服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。

发包方:可以是客户也可以是服务端,看哪边实现方便合理。

心跳包之所以叫心跳包是因为:它像心跳一样每隔固定时间发一次,以此来告诉服务器,这个客户端还活着。事实上这是为了保持长连接,至于这个包的内容,是没

有什么特别规定的,不过一般都是很小的包,或者只包含包头的一个空包。心跳包主要也就是用于长连接的保活和断线处理。一般的应用下,判定时间在30-40

秒比较不错。如果实在要求高,那就在6-9秒。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zz/13073279.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-30
下一篇 2023-05-30

发表评论

登录后才能评论

评论列表(0条)

保存