磁盘阵列是怎么自动切换的？

1、你的这台存储要同时连接到主备服务器，即成为它们的共享磁盘，这是一个前提条件。
2、主备服务器的自动切换主要依赖于服务器上的集群软件，心跳检测是集群软件中为实现自动切换功能而设的一种手段，用以判定集群中的其他服务器是否正常工作。
3、集群软件通常由 *** 作系统厂商配备或由第三方公司提供，具体有哪些品牌/型号首先要看你服务器上用的是哪种 *** 作系统。少数应用系统，像ORACLE数据库甚至会自带集群软件。

要在 linux 上监测宕机并自动切换到备用服务，您可以采取以下步骤：
1 设置心跳检测：创建一个脚本来进行心跳检测，并定期运行该脚本。该脚本将检查主要服务器是否还在运行，如果没有响应，则会触发故障转移过程。
2 配置备用服务器：在备用服务器上安装和配置同样的软件和服务，并确保具有相同的配置和环境。
3 设置自动切换：如果主要服务器无法响应，请设置故障转移脚本自动启动备用服务器。此脚本应该能够自动识别并切换到备用服务器。
4 测试：测试自动切换功能以确保一旦主服务器崩溃，备用服务器就会立即接管服务。
需要注意的是，在实施任何故障转移计划之前，请确保您已备份了所有数据，并且所有相关人员都知道该计划的详细信息。

基于现在的理解列出上面这句话中错误的知识点：

根据对这两个概念的理解，得出Websocket协议本身就实现了长连接，因为它是基于单个TCP连接进行通信，在此基础上还实现了服务器可主动发送数据，进行双向通信的功能

有这样的需求场景：很多网站需要实现推送功能，这就需要服务器主动向浏览器发送请求，但是>1、服务器端运行一个常驻线程，用于实时检查在线列表中，是否存在超时用户，有的话，就做相应处理，并将用户从在线列表中删除
2、用户登陆成功后，在客户端用JavaScript，使用定时器，每间隔固定时间（比如20秒），通过Ajax异步发送请求服务器某个页面，或者WebService之类的接口。这就是所谓的心跳请求。
3、服务器收到用户的心跳请求后，更新用户最后一次联系服务器的时间。
这样服务器检查超时的时候，实际上就可以把当前时间，减去用户最后一次联系服务器的时间，如果超过一个指定值，比如1分钟，那就认为这个用户离线了。
PS：原理很简单，但要设计一个高效的机制，还是要多考虑实现的算法，特别是服务器端的在线列表，和检查超时的机制。我曾经在几年前做了一个实现，后来重写了N遍，才发现了一个相对比较合理的方法。

很多人认为，TCP协议有KeepAlive机制，为何基于它的通讯链接仍然需要在应用层实现额外的心跳保活呢？本文将从移动端IM的角度告诉你，即使使用的是TCP协议，应用层的心跳保活仍旧必不可少。

在使用TCP长连接的IM服务设计中，往往都会涉及到心跳。心跳一般是指客户端每隔一定时间向服务端发送自定义指令，以判断双方是否存活，因其按照一定间隔发送，类似于心跳，故称为心跳指令。

TCP是一个基于连接的协议，其连接状态是由一个状态机进行维护，连接完毕（三次握手）后，双方都会处于established状态，这之后的状态并不会主动进行变化。也就是说，即使上层不进行任何调用，一直使TCP连接空闲，那么它仍然是保持连接的状态。这个时候就需要一种机制来检测TCP连接的状态，KeepAlive就是背负这个使命出现的。

那么问题来了，KeepAlive是用来检测TCP连接状态的，那为什么还需要心跳呢？这里就需要考虑一种情况了，假如某台服务器因为某些原因导致负载超高，CPU100%，无法响应任何业务需求，但是使用TCP探针仍旧能够确定连接状态，这就是典型的连接活着但业务提供方已死的状态，对客户端而言，这时最好的选择就是断线后重新连接其他服务器，而不是一直认为当前服务器是可用状态，一直向当前服务器发送些必然后失败的请求。

从上面我们可以知道，KeepAlive并不适合检测双方存活的场景，这种场景还得依赖于应用层的心跳。应用层的心跳有着更大的灵活性，可以控制检测时机、间隔和处理流程，甚至可以在心跳包上附带额外信息。从这个角度而言，应用层的心跳的确是最佳实践。

TCP KeepAlive用于检测连接的死活，而心跳机制则附带一个额外的功能：检测通讯双方的存活状态。

从上面我们可以得出结论，目前而言，应用层心跳的确是检测连接有效性，双方是否存活的最佳实践，那么剩下的问题就是怎么实现。

最简单粗暴的方法是定时心跳，如每隔30秒心跳一次，15秒内没有收到心跳包则认为当前连接已失效，断开连接并进行重连。这种做法最直接，实现也简单。唯一的问题就是耗电和耗流量。以一个协议包 5 个字节计算，一天收发 2880 个心跳包，一个月就是 5 x 2 x 2880 x 30 = 08 M 的流量，如果手机上多装几个 IM 软件，每个月光心跳就好几兆流量没了，更不用说频繁的心跳带来的电量损耗。

既然频繁心跳会带来耗电和耗流量的弊端，改进的方向自然就是减少心跳频率，但也不能过于影响连接检测的实时性。基于这个需求，一般可以将心跳间隔根据程序状态进行调整，当程序在后台时（这里主要指安卓），尽量拉长心跳间隔，5分钟、甚至10分钟都可以。

而当App在前台时则按照原来规则 *** 作。连接可靠性的判断也可以放宽，避免一次心跳超时就认为连接无效的情况，使用错误积累，只在心跳超时n次后才判定当前连接不可用。

---

TCP keepalive 和 >

欢迎分享，转载请注明来源：内存溢出

原文地址: http://outofmemory.cn/zz/12919015.html