Table of Contents:

如何保证Nginx的高可用呢？

1.DNS保证高可用


但这玩意有一个致命的问题，那就是故障的感知时间。

我们的浏览器在访问到真正的Nginx之前，需要把域名转化为真正的IP地址，DNS就是干解析这个动作的，每次需要耗费20-20ms不等。

为了加快解析速度，一般都会有多级的缓存。比如浏览器就有DNS的缓存；你使用的PC机上也有这样的缓存；IPS服务提供商，也会有缓存；再加上有的企业为了加速访问所自建的DNS服务器，中间的缓存层就更多了。

只有所有的缓存都不命中的情况下，DNS才会查询真正的IP地址。所以，如果有一台Nginx当机了，这个故障的感知能力就会特别的差。总有一部分用户的请求，会落在这台已经死亡的机器上。

2.硬件保证高可用


这种架构一般的企业玩不起，只有那些采购有回扣有油水的公司，才会喜欢这个。互联网中用的很少，就不过多介绍了。

当然，F5同样有单点的问题。虽然硬件肯定要比软件稳定上一点，但是总归是一个隐患。就像Oracle无论再厉害，它还是有出问题的时候，到时候备机是必须的。

3.主备模式


如图，使用keepalived组件，通过VRRP协议，即可完成最简单的高可用配置。

我们把DNS的地址绑定在VIP上，当正在服务的Nginx发生问题，VIP会发生漂移，转移到另外一台Nginx上。

可以看到，备份的Nginx，正常情况下是无法进行服务的，它也叫做影子节点，只有主Nginx发生问题的时候才有用。如果你的节点非常多，这种模式下，会有非常大的浪费。

除了浪费，还有一个非常大的问题。那就是，单台Nginx无论性能多么牛X，总是有上限的。当网卡的流量达到顶峰，接下来何去何从呢？

这种模式肯定是不满足需求的。

4.简单组合模式

这个时候，我们就可以配合DNS解析，以及主备模式做文章了。如下图，DNS解析到两个VIP上，VIP本身也做了高可用。这样就能够缩短故障时间，同时也能够保证每个组件的高可用。
这种架构模式思路是非常清晰的，但依然存在影子节点的浪费。

5.LVS+KeepAlived+Nginx

LVS 是 Linux Virtual Server 的简称，也就是 Linux 虚拟服务器。现在 LVS 已经是 Linux 标准内核的一部分，从 Linux2.4 内核以后，已经完全内置了 LVS 的各个功能模块，无需给内核打任何补丁，可以直接使用 LVS 提供的各种功能。

LVS工作在OSI模型的第4层：传输层，比如TCP/UDP，所以像7层网络的HTTP协议，它是识别不出来的。也就是说，我们不能拿HTTP协议的一些内容来控制路由，它的路由切入层次更低一些。

负载均衡keepalive虚拟ip如何获得？

VIP是也是实实在在的IP地址，跟一般的IP地址是一样的，自己的理解是 ”可以漂移的IP地址“（不官方）。1、要配置keepalived服务，需要事先需要准备三个IP地址。主服务器上的IP，备服务器上的IP，对外提供服务的VIP。主、备服务机器的IP直接配置到各自的网卡上。VIP写到配置文件里面，keepalived会将VIP配置到主服务器的网卡上。2、用户访问的是VIP。只有主服务器的keepalived会将VIP配置到网卡上，容灾之后，主变备：keepalived将VIP从网卡上移走。备变主：keepalived将VIP配置到网卡上。3、用户访问域名如何防止单点瘫痪：配好DNS，{域名:VIP}。用户访问该域名，经过解析，拿到VIP。此时，数据包会走上面主备服务器中的主服务器，如果主服务器瘫痪，备服务器会自动接过VIP，备变主，对外提供服务。整个过程，对于用户来说是透明的，用的是同样的域名，解析到的是同样的VIP。

参考链接