Linux服务器双机热备详细过程

通常说的双机热备是指两台机器都在运行，但并不是两台机器都同时在提供服务。

当提供服务的一台出现故障的时候，另外一台会马上自动接管并且提供服务，而且切换的时间非常短。

下面来以keepalived结合tomcat来实现一个web服务器的双机热备过程：

keepalived的工作原理是VRRP虚拟路由冗余协议。

在VRRP中有两组重要的概念：VRRP路由器和虚拟路由器，主控路由器和备份路由器。

VRRP路由器是指运行VRRP的路由器，是物理实体，虚拟路由器是指VRRP协议创建的，是逻辑概念。一组VRRP路由器协同工作，共同构成一台虚拟路由器。Vrrp中存在着一种选举机制，用以选出提供服务的路由即主控路由，其他的则成了备份路由。

当主控路由失效后，备份路由中会重新选举出一个主控路由，来继续工作，来保障不间断服务。

两台物理服务器和一个虚拟服务器（vip）：master：redhat2．6．18－53．el5192．168．8．4；backup：redhat2．6．18－53．el5192．168．8．6；vip：192．168．8．100。

节点A192．168．8．4（主节点），节点B192．168．8．6（备用节点），虚拟IP（对外提供服务的IP192．168．8．100）

在这种模式下，虚拟IP在某时刻只能属于某一个节点，另一个节点作为备用节点存在。

当主节点不可用时，备用节点接管虚拟IP（即虚拟IP漂移至节点B），提供正常服务。

keepalived的原理可以这样简单理解：

keepalived安装在两台物理服务器上，并相互监控对方是否在正常运行。

当节点A正常的时候：节点A上的keepalived会将下面的信息广播出去：

192．168．8．100这个IP对应的MAC地址为节点A网卡的MAC地址

其它电脑如客户端和NodeB会更新自己的ARP表，对应192．168．8．100的MAC地址＝节点A网卡的MAC地址。

当节点A发生故障的时候，节点B上的keepalived会检测到，并且将下面的信息广播出去：

192．168．8．100这个IP对应的MAC地址为节点B网卡的MAC地址

其它电脑如客户端会更新自己的ARP表，对应192．168．8．100的MAC地址＝节点B网卡的MAC地址。

扩展资料：

双机热备特指基于active/standby方式的服务器热备。服务器数据包括数据库数据同时往两台或多台服务器执行写 *** 作，或者使用一个共享的存储设备。在同一时间内只有一台服务器运行。

当其中运行着的一台服务器出现故障无法启动时，另一台备份服务器会通过软件诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用。

Keepalived的运行原理是基于VRRP（虚拟路由冗余协议）机制，在VRRP中有两个重要的概念：VRRP路由器和虚拟路由器，主控路由器和备份路由器。

VRRP路由器是一种实体路由器设备，而虚拟路由器则是基于VRRP协议构建的虚拟路由器，是软性的虚拟概念，一组VRRP路由器协同工作，共同构造一台虚拟服务器。

VRRP协议支持一种选举机制，主要用来选出用来提供服务的路由即主控路由，其它的就是备份路由了，当主控路由失效之后，备份路由中重新选出一个主控路由（往往按照设置好的优先级别重新分配），接管主控服务，继续工作，来保证不间断的提供服务。

参考资料：

百度百科-双机热备

导读：Redis是被广泛使用的基础软件之一。对于工程师和,架构师，运维人员来说，了解Redis的高可用方案和背后的原理，是必备的基础知识。本文作者深入分析了Redis高可用的方方面面，并且做了有效总结，相信对广大读者可以起到很好的领路作用。

作者 codedump codedumpinfo 博主，多年从事互联网服务器后台开发工作。可访问作者博客阅读 codedump 更多文章。

Redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式：

Redis中主从节点复制数据有全量复制和部分复制之分。

全量复制使用snyc命令来实现，其流程是：

旧版本全量复制功能，其最大的问题是从服务器断线重连时，即便在从服务器上已经有一部分数据了，也需要进行全量复制，这样做的效率很低，于是新版本的Redis在这部分做了改进。

新版本Redis使用psync命令来代替sync命令，该命令既可以实现完整全同步也可以实现部分同步。

执行复制的双方，主从服务器，分别会维护一个复制偏移量：

主服务器内部维护了一个固定长度的先进先出队列做为复制积压缓冲区，其默认大小为1MB。

在主服务器进行命令传播时，不仅会将写命令同步到从服务器，还会将写命令写入复制积压缓冲区。

每个Redis服务器，都有其运行ID，运行ID由服务器在启动时自动生成，主服务器会将自己的运行ID发送给从服务器，而从服务器会将主服务器的运行ID保存起来。

从服务器Redis断线重连之后进行同步时，就是根据运行ID来判断同步的进度：

有了前面的准备，下面开始分析psync命令的流程：

前面两种情况主服务器收到psync命令之后，会出现以下三种可能：

Redis使用哨兵机制来实现高可用(HA)，其大概工作原理是：

以上将Redis节点分为两类：

以上是大体的流程，这个流程需要解决以下几个问题：

以下来逐个回答这些问题。

哨兵节点通过三个定时监控任务监控Redis数据节点的服务可用性。

每隔10秒，每个哨兵节点都会向主、从Redis数据节点发送info命令，获取新的拓扑结构信息。

Redis拓扑结构信息包括了：

这样，哨兵节点就能从info命令中自动获取到从节点信息，因此那些后续才加入的从节点信息不需要显式配置就能自动感知。

这一 *** 作实际上完成了两件事情： 发现新的哨兵节点：如果有新的哨兵节点加入，此时保存下来这个新哨兵节点的信息，后续与该哨兵节点建立连接。 交换主节点的状态信息，作为后续客观判断主节点下线的依据。

每隔1秒，每个哨兵节点向主、从数据节点以及其他sentinel节点发送ping命令做心跳探测，这个心跳探测是后续主观判断数据节点下线的依据。

上面三个监控任务中的第三个探测心跳任务，如果在配置的down-after-milliseconds之后没有收到有效回复，那么就认为该数据节点“主观下线（sdown）”。

为什么称为“主观下线”？因为在一个分布式系统中，有多个机器在一起联动工作，网络可能出现各种状况，仅凭一个节点的判断还不足以认为一个数据节点下线了，这就需要后面的“客观下线”。

当一个哨兵节点认为主节点主观下线时，该哨兵节点需要通过”sentinel is-master-down-by addr”命令向其他哨兵节点咨询该主节点是否下线了，如果有超过半数的哨兵节点都回答了下线，此时认为主节点“客观下线”。

当主节点客观下线时，需要选举出一个哨兵节点做为哨兵领导者，以完成后续选出新的主节点的工作。

这个选举的大体思路是：

可以看到，这个选举领导者的流程很像raft中选举leader的流程。

在剩下的Redis从节点中，按照以下顺序来选择新的主节点：

选择了新的主节点之后，还需要最后的流程让该节点成为新的主节点：

原文地址：

>

从你目前的情况上来看,应该是网页服务器(应用程序服务器)的配置要求高一点,因为你的这个系统可是能是OA需要大量的数据进行交换

要求数据服务器与应用程序服务器分开,可能你的数据采用的是SQL服务器这种情况下增加了数据的安全性,位于同一局网内的数据数据库不用联网,只服务于应用程序服务器,而应用程序服务器只负责处理访问,数据服务器只负责应用程序服务器的数据,所以这种好处还是因而易见的再者可以使用两台或者两台以上的应用程序服务器,完全将应用与数据分开,对访问与处理速度还是比较快

两台服务器之间的联接显然是通过路由器内层的交换机进行的联机如果有两台数据服务器时,其中一台是备份时才可能用到双网卡使用"心跳线",如果没有备份,这些根本不需要考虑只管用正常的网线连接上交换机就行了

以上就是关于Linux服务器双机热备详细过程全部的内容，包括:Linux服务器双机热备详细过程、调研Redis高可用两种方案、关于数据库服务器与网页服务器分开的问题。等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！