了解Nginx的高可用就接触到了这几个概念，一开始对这些概念还有点迷糊。区分这几个概念概念的最好方法就是搭建一个同时包含他们三个的架构。如下图：
当然，他们三个组合的架构其实有很多种，这只是其中一种。
接下来通过问答的形式理清这些概念。
为什么要有这么复杂的架构？
所有的问题起源与一台服务器的单机性能不够。一台不够就再加几台，形成集群，于是同一个服务运行再多个服务器上了。但随之而来的就有一个问题，客户端怎么知道要访问谁？假设集群中的每台服务器都有公网IP的话，那么可以通过将IP绑定域名，可以让DNS轮询，决定使用哪个IP。这样的结果就是，往往所有流量都全部取到一台服务器上，等这台服务器承受不了流量挂了，就切换到下一台服务器上，这就如同灾难转移，葫芦娃救爷爷。这样集群就形同虚设了，我们认为集群应该是平均分摊流量的，这时候我们就需要使用负载均衡了。
负载均衡当然好，这意味着所有流量都要经过Nginx，即使Nginx吞吐量比Tomcat优秀或许能承受住所有流量，但是也有挂的风险。一旦Nginx挂了，整个系统都不可用了，所以我们需要保证Nginx 高可用。
要保证高可用自然可以想到加一个备机，在主机挂了就切换成备机。
这样的方案确实可靠，但是有些浪费，因为平常使用的时候备机没有任何人访问，属于冷备，为了极少发生的系统崩溃支付两倍的成本不值得，但是又必须保证崩溃时能切换成备机。这时候就可以将两台机器互为主备，达成双机热备的状态，所谓的热备，就是备用机也提供服务，这样即节省了成本，也可以解决单台Nginx吞吐量不足的情况。
LVS、Keepalived、Nginx分别是做什么的？
LVS和Nginx都是做负载均衡的。Keepalived是保证高可用的，在Nginx或者LVS主机出现故障时，可以由备机承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续提供服务。
Keepalived是如何完成主备切换的？
Keepalived工作是基于VRRP协议的，VRRP协议允许一台机器可以拥有一个或者多个虚拟IP（即图中的VIP）。由一个主机和多个备机组成一组高可用的机器并对外提供一个虚拟IP。客户端通过虚拟IP访问主机，而备机负责监控主机，如果主机挂了，就选举其中一个备机接管主机，所谓的接管就是将虚拟IP绑定到新的主机上，这个过程称为IP漂移。
虚拟IP、VIP是什么？
VIP就是虚拟IP，即不分配给任何服务器的IP，因此他可以完成IP漂移。图中的IP指的就是分配给服务器的IP，区别于VIP。其中的IP其实可以是公网的IP也可以是内网的IP。而图中的架构一共有两个公网IP，一个是123.123.123.21，另一个是123.123.123.22，提供给外网访问。
VRRP协议允许一台机器有一个或多个虚拟IP，这也使得双机热备成为可能，图中每台LVS和Nginx都绑定了两个VIP，虽然图中每台只标了一个VIP，标的VIP指的是这台以服务器为主机的VIP，实际上这台服务器的VIP可以同时是另一台的VIP（当另外一台机器挂机时），即有两个VIP。
Keepalived的备机是如何监控主机并完成IP漂移的？
Keepalived是一个软件，需要配置内容包括当不限于：执行脚本、触发间隔、VIP。脚本是用户自己写的，用于检测某个服务的进程是否可用，在这个架构中就是LVS进程或者Nginx进程，这个脚本在每个触发间隔过后执行一次脚本，脚本内容通常是如果进程不可用就杀死Keepalived进程。Keepalived进程在正常运行的时候会互相发送VRRP协议心跳包，如果没有收到对方心跳包就认为对方挂了，就触发IP漂移。
上文提到，虚拟IP是不分配给任何服务器的IP，而IP漂移就是把虚拟IP绑定备机上。这里的绑定和分配有些些语义上的不同。我们知道IP是可以静态绑定也可以动态分配，但是无论是哪种，在服务器运行期间，静态绑定或者动态分配的IP都是不会变的，而虚拟IP就是可以在运行期间“变化”。这个变化指的就是显现或者不显现，事实上在写配置文件的时候每个服务器就已经“绑定”了一个或多个虚拟IP，只是根据主机、备机的运行状况而决定显不显现。
这里的显不显现指的就是是否响应ARP请求 。
IP的“绑定”有两个层次，一个是IP和域名绑定，另一个是IP和MAC地址绑定。这是我们“绑定IP”的语义是虚拟IP和某一台机器绑定，即和某一台机器的MAC地址绑定。而IP和MAC地址绑定是通过ARP协议来实现的，只要不响应ARP请求，IP就不会和MAC地址绑定，只要响应了ARP请求，IP就会和MAC就会绑定。所以Keepalived的IP漂移本质上就是协调哪一个机器来响应ARP请求从而使得他的MAC地址绑定虚拟IP。
Keepalived没有注册中心是如何知道把VRRP心跳包发给谁的?
Keepalived基于VRRP的虚拟路由器实现设备发现，会使用默认的244.0.0.18作为组播地址，这其实起到了类似注册中心的作用。
域名换绑IP是不是就可以达成类似Keepalived的IP漂移的效果?
通过域名换绑IP确实可以达成切换主备的效果，但是这个过程需要人工故障发现和人工切换，速度肯定是比不上Keepalived的IP漂移，IP漂移这个过程大概只需要几秒钟，而域名换绑IP需要等DNS生效这需要几分钟？或者DNS配置域名绑定主机和备机两个IP，让DNS轮询实现切换和故障发现，这直接实现了双机热备，就不用配置Keepalived了。但轮询的故障发现速度和切换速度仍然比不上IP漂移，并且写方案随着机器躲起来就变得难以实现，用DNS轮询的话就需要每台机器都有一个公网IP，而IP漂移本质上实在同一网段下工作的，对外暴露的IP数是可以自行决定的。
但是这两种方案都有一个缺点，就是虽然都达成了双机热备的效果了，在外看来就是一个集群，而集群就会有负载均衡的问题，而这两个方案都没有解决负载均衡。而Keepalived还可以通过增加Nginx或者LVS进行负载均衡，而DNS方案IP就已经直达客户端，没有机会给我们做负载均衡。
Nginx和LVS的区别？
| LVS | Nginx | |
|---|---|---|
| 工作层次 | 第四层： IP、端口的 | 第七层：URL或主机IP等 |
| 复杂度 | 低 | 高 |
| 性能 | 高；无需解析内容 | 一般；需要进行处理 |
| 额外功能 | 无 | 有 |
Nginx比LVS有更多的功能，但是这也意味着有更多的开销，性能就稍微差了一些。
为什么不直接让Keepalived保证Tomcat高可用？
凡是集群就有负载均衡的问题。Keepalived仅仅解决的是集群里的故障发现和切换工作（流量转移），但是无法保证平均分摊流量。这时候就需要Nginx和LVS来做负载均衡了。
Keepalived一般用于Nginx和LVS，而Tomcat都是通过Nginx和LVS来做负载均衡。原因是通常同一个微服务有多个Tomcat运行，挂了一个两个没有什么大问题，通过Nginx可以实现发现故障和流量转移，并且在转移流量的过程中还是能够达到了每台存活的服务器的流量，这意味着Nginx不仅完成里Keepalived的工作，并且还使得了流量均摊，不至于产生雪崩（如果是Keepalived，挂的那台服务器的所有流量会漂移另一台上，很可能那一台也要挂，最终，所有流量将集群逐个击破。）
为什么要有LVS和Nginx两层？
实际上只是为了弄清楚LVS和Nginx而已，具体几层看怎么设计吧。Nginx既然也组成集群，那么也有负载均衡问题，这时就可以交给LVS来做。
当然，你会说，LVS不也有负载均衡问题吗？无论设计多少层负载均衡，多少层网关，所有流量总还是会通过一个地方的，怎么扛得住呢？
确实是这样的，但是服务器和服务器之间并不是完全相同点，从LVS到Nginx到Tomcat，他们的功能以此增加，吞吐量也依次减少。几台Tomcat扛不住的流量可能一台Nginx就能扛住，几台Nginx扛不住的流量可一台LVS就能扛住。那LVS扛不住呢？总不能让所有流量都往一个地方走吧，所以可以考虑类似CDN的手段，每个地区就近解决就好了。
总结
以上就是这两天学到的内容，可能会有不正确，不严谨的地方，各位批评指正。