java设计模式pdf、java设计模式pdf下载 收藏 0

如何基于搭建Nginx+Keepalived双机热备环境？

写在前面

最近出版了《海量数据处理与大数据技术实战》，详情可以关注 冰河技术 微信公众号

也有不少小伙伴让我更新一篇基于主从模式搭建Nginx+Keepalived双机热备的环境，怎么办呢？那必须安排上啊！不多说了，我们直接进入正文。

负载均衡技术

负载均衡技术对于一个网站尤其是大型网站的web服务器集群来说是至关重要的！做好负载均衡架构，可以实现故障转移和高可用环境，避免单点故障，保证网站健康持续运行。

由于业务扩展，网站的访问量不断加大，负载越来越高。现需要在web前端放置nginx负载均衡,同时结合keepalived对前端nginx实现HA高可用。

1）nginx进程基于Master+Slave(worker)多进程模型，自身具有非常稳定的子进程管理功能。在Master进程分配模式下，Master进程永远不进行业务处理，只是进行任务分发，从而达到Master进程的存活高可靠性，Slave(worker)进程所有的业务信号都 由主进程发出，Slave(worker)进程所有的超时任务都会被Master中止，属于非阻塞式任务模型。

2）Keepalived是Linux下面实现VRRP备份路由的高可靠性运行件。基于Keepalived设计的服务模式能够真正做到主服务器和备份服务器故障时IP瞬间无缝交接。二者结合，可以构架出比较稳定的软件LB方案。

Keepalived介绍

Keepalived是一个基于VRRP协议来实现的服务高可用方案，可以利用其来避免IP单点故障，类似的工具还有heartbeat、corosync、pacemaker。但是它一般不会单独出现，而是与其它负载均衡技术（如lvs、haproxy、nginx）一起工作来达到集群的高可用。

VRRP协议

VRRP全称 Virtual Router Redundancy Protocol，即 虚拟路由冗余协议。可以认为它是实现路由器高可用的容错协议，即将N台提供相同功能的路由器组成一个路由器组(Router Group)，这个组里面有一个master和多个backup，但在外界看来就像一台一样，构成虚拟路由器，拥有一个虚拟IP（vip，也就是路由器所在局域网内其他机器的默认路由），占有这个IP的master实际负责ARP相应和转发IP数据包，组中的其它路由器作为备份的角色处于待命状态。master会发组播消息，当backup在超时时间内收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，保证路由器的高可用。

在VRRP协议实现里，虚拟路由器使用 00-00-5E-00-01-XX 作为虚拟MAC地址，XX就是唯一的 VRID （Virtual Router IDentifier），这个地址同一时间只有一个物理路由器占用。在虚拟路由器里面的物理路由器组里面通过多播IP地址 224.0.0.18 来定时发送通告消息。每个Router都有一个 1-255 之间的优先级别，级别最高的（highest priority）将成为主控（master）路由器。通过降低master的优先权可以让处于backup状态的路由器抢占（pro-empt）主路由器的状态，两个backup优先级相同的IP地址较大者为master，接管虚拟IP。

keepalived与heartbeat/corosync等比较

Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好呢？

首先要说明的是，Heartbeat、Corosync是属于同一类型，Keepalived与Heartbeat、Corosync，根本不是同一类型的。 Keepalived使用的vrrp协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)； Heartbeat或Corosync是基于主机或网络服务的高可用方式；

简单的说就是，Keepalived的目的是模拟路由器的高可用，Heartbeat或Corosync的目的是实现Service的高可用。 所以一般Keepalived是实现前端高可用，常用的前端高可用的组合有，就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是实现服务的高可用，常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。

总结一下，Keepalived中实现轻量级的高可用，一般用于前端高可用，且不需要共享存储，一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用，且需要共享存储，一般用于多节点的高可用。这个问题我们说明白了。

那heartbaet与corosync又应该选择哪个好？

一般用corosync，因为corosync的运行机制更优于heartbeat，就连从heartbeat分离出来的pacemaker都说在以后的开发当中更倾向于corosync，所以现在corosync+pacemaker是最佳组合。

双机高可用一般是通过虚拟IP（飘移IP）方法来实现的，基于Linux/Unix的IP别名技术。

双机高可用方法目前分为两种：

1）双机主从模式：即前端使用两台服务器，一台主服务器和一台热备服务器，正常情况下，主服务器绑定一个公网虚拟IP，提供负载均衡服务，热备服务器处于空闲状态；当主服务器发生故障时，热备服务器接管主服务器的公网虚拟IP，提供负载均衡服务；但是热备服务器在主机器不出现故障的时候，永远处于浪费状态，对于服务器不多的网站，该方案不经济实惠。

2）双机主主模式：即前端使用两台负载均衡服务器，互为主备，且都处于活动状态，同时各自绑定一个公网虚拟IP，提供负载均衡服务；当其中一台发生故障时，另一台接管发生故障服务器的公网虚拟IP（这时由非故障机器一台负担所有的请求）。这种方案，经济实惠，非常适合于当前架构环境。

今天在此分享下Nginx+keepalived实现高可用负载均衡的主从模式的操作记录：

keepalived可以认为是VRRP协议在Linux上的实现，主要有三个模块，分别是core、check和vrrp。

• core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。
• check负责健康检查，包括常见的各种检查方式。
• vrrp模块是来实现VRRP协议的。

环境说明

操作系统：centos6.8，64位 master机器（master-node）：103.110.98.14/192.168.1.14 slave机器（slave-node）：103.110.98.24/192.168.1.24 公用的虚拟IP（VIP）：103.110.98.20 //负载均衡器上配置的域名都解析到这个VIP上

应用环境如下环境安装

安装nginx和keepalive服务（master-node和slave-node两台服务器上的安装操作完全一样）。

安装依赖

大家可以到链接：https://download.csdn.net/download/l1028386804/10376846下载nginx1.9.7+keepalive1.3.2，也可以将nginx.1.9.7更新为nginx1.19.2。nginx1.19.2与nginx1.9.7的安装方式相同，这里我以nginx1.9.7为例进行安装。

安装nginx

添加www用户，其中-M参数表示不添加用户家目录，-s参数表示指定shell类型

安装keepalived

将nginx和keepalive服务加入开机启动服务

配置服务

先关闭SElinux、配置防火墙 （master和slave两台负载均衡机都要做）

配置nginx

master-node和slave-node两台服务器的nginx的配置完全一样,主要是配置/usr/local/nginx/conf/nginx.conf的http，当然也可以配置vhost虚拟主机目录，然后配置vhost下的比如LB.conf文件。

其中: 多域名指向是通过虚拟主机（配置http下面的server）实现; 同一域名的不同虚拟目录通过每个server下面的不同location实现; 到后端的服务器在vhost/LB.conf下面配置upstream,然后在server或location中通过proxy_pass引用。

要实现前面规划的接入方式，LB.conf的配置如下（添加proxy_cache_path和proxy_temp_path这两行，表示打开nginx的缓存功能）

验证Nginx配置

验证方法（保证从负载均衡器本机到后端真实服务器之间能正常通信）： 1）首先在本机用IP访问上面LB.cong中配置的各个后端真实服务器的url 2）然后在本机用域名和路径访问上面LB.cong中配置的各个后端真实服务器的域名/虚拟路径

后端应用服务器的nginx配置，这里选择192.168.1.108作为例子进行说明。

由于这里的192.168.1.108机器是openstack的虚拟机，没有外网ip，不能解析域名。所以在server_name处也将ip加上，使得用ip也可以访问。

然后在master-node和slave-node两台负载机器上进行测试（iptables防火墙要开通80端口）：

浏览器访问： 在本机host绑定dev.wangshibo.com，如下，即绑定到master和slave机器的公网ip上测试是否能正常访问（nginx+keepalive环境正式完成后，域名解析到的真正地址是VIP地址） 103.110.98.14 dev.wangshibo.com 103.110.98.24 dev.wangshibo.com

keepalived配置

1）master-node负载机上的keepalived配置

slave-node负载机上的keepalived配置

让keepalived监控NginX的状态：

1）经过前面的配置，如果master主服务器的keepalived停止服务，slave从服务器会自动接管VIP对外服务； 一旦主服务器的keepalived恢复，会重新接管VIP。 但这并不是我们需要的，我们需要的是当NginX停止服务的时候能够自动切换。 2）keepalived支持配置监控脚本，我们可以通过脚本监控NginX的状态，如果状态不正常则进行一系列的操作，最终仍不能恢复NginX则杀掉keepalived，使得从服务器能够接管服务。

如何监控NginX的状态 最简单的做法是监控NginX进程，更靠谱的做法是检查NginX端口，最靠谱的做法是检查多个url能否获取到页面。

注意：这里要提示一下keepalived.conf中vrrp_script配置区的script一般有2种写法：

1）通过脚本执行的返回结果，改变优先级，keepalived继续发送通告消息，backup比较优先级再决定。这是直接监控Nginx进程的方式。 2）脚本里面检测到异常，直接关闭keepalived进程，backup机器接收不到advertisement会抢占IP。这是检查NginX端口的方式。

上文script配置部分，\”killall -0 nginx\”属于第1种情况，\”/opt/chk_nginx.sh\” 属于第2种情况。个人更倾向于通过shell脚本判断，但有异常时exit 1，正常退出exit 0，然后keepalived根据动态调整的 vrrp_instance 优先级选举决定是否抢占VIP：

• 如果脚本执行结果为0，并且weight配置的值大于0，则优先级相应的增加
• 如果脚本执行结果非0，并且weight配置的值小于0，则优先级相应的减少
• 其他情况，原本配置的优先级不变，即配置文件中priority对应的值。

提示： 优先级不会不断的提高或者降低

可以编写多个检测脚本并为每个检测脚本设置不同的weight（在配置中列出就行）

不管提高优先级还是降低优先级，最终优先级的范围是在[1,254]，不会出现优先级小于等于0或者优先级大于等于255的情况 在MASTER节点的 vrrp_instance 中 配置 nopreempt ，当它异常恢复后，即使它 prio 更高也不会抢占，这样可以避免正常情况下做无谓的切换

以上可以做到利用脚本检测业务进程的状态，并动态调整优先级从而实现主备切换。

另外：在默认的keepalive.conf里面还有 virtual_server,real_server 这样的配置，我们这用不到，它是为lvs准备的。

如何尝试恢复服务 由于keepalived只检测本机和他机keepalived是否正常并实现VIP的漂移，而如果本机nginx出现故障不会则不会漂移VIP。 所以编写脚本来判断本机nginx是否正常，如果发现NginX不正常，重启之。等待3秒再次校验，仍然失败则不再尝试，关闭keepalived，其他主机此时会接管VIP；

根据上述策略很容易写出监控脚本。此脚本必须在keepalived服务运行的前提下才有效！如果在keepalived服务先关闭的情况下，那么nginx服务关闭后就不能实现自启动了。

该脚本检测ngnix的运行状态，并在nginx进程不存在时尝试重新启动ngnix，如果启动失败则停止keepalived，准备让其它机器接管。 监控脚本如下（master和slave都要有这个监控脚本）：

此架构需考虑的问题 1）master没挂，则master占有vip且nginx运行在master上 2）master挂了，则slave抢占vip且在slave上运行nginx服务 3）如果master上的nginx服务挂了，则nginx会自动重启，重启失败后会自动关闭keepalived，这样vip资源也会转移到slave上。 4）检测后端服务器的健康状态 5）master和slave两边都开启nginx服务，无论master还是slave，当其中的一个keepalived服务停止后，vip都会漂移到keepalived服务还在的节点上； 如果要想使nginx服务挂了，vip也漂移到另一个节点，则必须用脚本或者在配置文件里面用shell命令来控制。（nginx服务宕停后会自动启动，启动失败后会强制关闭keepalived，从而致使vip资源漂移到另一台机器上）

最后验证（将配置的后端应用域名都解析到VIP地址上）：关闭主服务器上的keepalived或nginx，vip都会自动飘到从服务器上。

验证keepalived服务故障情况： 1）先后在master、slave服务器上启动nginx和keepalived，保证这两个服务都正常开启:

2）在主服务器上查看是否已经绑定了虚拟IP

3）停止主服务器上的keepalived:

4）然后在从服务器上查看，发现已经接管了VIP：

发现master的keepalived服务挂了后，vip资源自动漂移到slave上，并且网站正常访问，丝毫没有受到影响！

5）重新启动主服务器上的keepalived，发现主服务器又重新接管了VIP，此时slave机器上的VIP已经不在了

接着验证下nginx服务故障，看看keepalived监控nginx状态的脚本是否正常？ 如下：手动关闭master机器上的nginx服务，最多2秒钟后就会自动起来（因为keepalive监控nginx状态的脚本执行间隔时间为2秒）。域名访问几乎不受影响！

最后可以查看两台服务器上的/var/log/messages，观察VRRP日志信息的vip漂移情况~~~~

可能出现的问题

1）VIP绑定失败 原因可能有： -> iptables开启后，没有开放允许VRRP协议通信的策略（也有可能导致脑裂）；可以选择关闭iptables -> keepalived.conf文件配置有误导致，比如interface绑定的设备错误

2）VIP绑定后，外部ping不通 可能的原因是： -> 网络故障，可以检查下网关是否正常； -> 网关的arp缓存导致，可以进行arp更新，命令是\”arping -I 网卡名 -c 5 -s VIP 网关\”

重磅福利

关注「 冰河技术 」微信公众号，后台回复 “设计模式” 关键字领取《深入浅出Java 23种设计模式》PDF文档。回复“Java8”关键字领取《Java8新特性教程》PDF文档。回复“限流”关键字获取《亿级流量下的分布式限流解决方案》PDF文档，三本PDF均是由冰河原创并整理的超硬核教程，面试必备！！

好了，今天就聊到这儿吧！别忘了点个赞，给个在看和转发，让更多的人看到，一起学习，一起进步！！

写在最后

如果你觉得冰河写的还不错，请微信搜索并关注「 冰河技术 」微信公众号，跟冰河学习高并发、分布式、微服务、大数据、互联网和云原生技术，「 冰河技术 」微信公众号更新了大量技术专题，每一篇技术文章干货满满！不少读者已经通过阅读「 冰河技术 」微信公众号文章，吊打面试官，成功跳槽到大厂；也有不少读者实现了技术上的飞跃，成为公司的技术骨干！如果你也想像他们一样提升自己的能力，实现技术能力的飞跃，进大厂，升职加薪，那就关注「 冰河技术 」微信公众号吧，每天更新超硬核技术干货，让你对如何提升技术能力不再迷茫！

如何设计一个支撑高并发大流量的系统？这次我将思路分享给大家

最近不少小伙伴们都在问我：高并发专题我学了不少文章了，但是如何设计一个高并发的系统我还是一脸懵逼！这个问题怎么解决呢？其实，相信不只是问我的这些小伙伴有这个困惑，就连工作（入坑）了好几年的开发人员也都有这样的困惑：我学习了很多的高并发课程，也看了不少的高大上的文章，可就是不知道怎么去设计一个支撑高并发大流量的系统。针对小伙伴们的疑惑，这里，我就把一些设计高并发大流量的常规思路分享给大家，不一定完全正确，设计高并发大流量系统本来就是一个仁者见仁、智者见智的事情，只要是符合自身业务场景的架构思路，都是好的架构思路，架构本身来说就是没有一个完全正确的架构，而是尽量符合当时自身的业务场景，并且能够良好的支撑业务的负载。

并发是指并发的访问，也就是某个时间点，有多少个访问同时到来；

通常如果一个系统的日PV在千万以上，有可能是一个高并发的系统，这里需要注意的是：只是有可能是一个高并发的系统，不一定是一个高并发的系统。

并发数和QPS是不同的概念，一般说QPS会说多少并发用户下QPS，当QPS相同时，并发用户数越大，网站并发处理能力越好。当并发用户数过大时，会造成进程（线程）频繁切换，反正真正用于处理请求的时间变少，每秒能够处理的请求数反而变少，同时用户的请求等待时间也会变大。 找到最佳线程数能够让web系统更稳定，效率更高。

并发数 = QPS*平均响应时间

QPS： 每秒请求或查询的数量，在互联网领域，指每秒响应请求数；

吞吐量： 单位时间内处理的请求量（通常由QPS与并发数决定）；

响应时间： 从请求发出到收到响应花费的时间，例如一个系统处理一个HTTP请求需要100ms，这个100ms就是系统的响应时间；

PV： 综合浏览量，即页面浏览量或者点击量，一个访客在24小时内访问的页面数量；

UV： 独立访客 ，即一定时间范围内相同访客多次访问网站，只计算为一个独立的访客；

带宽： 计算带宽大小需要关注两个指标，峰值流量和页面的平均大小 ；

日网站带宽可以使用下面的公式来粗略计算：

峰值一般是平均值的倍数；

QPS不等于并发连接数，QPS是每秒HTTP请求数量，并发连接数是系统同时处理的请求数量；

压力测试： 测试能承受的最大并发，测试最大承受的QPS值。

测试工具（ab）： 目标是URL，可以创建多个访问线程对同一个URL进行访问（Nginx）；

ab的使用： 模拟并发请求100次（100个人），总共请求5000次（每个人请求5000次）

QPS达到50： 一般的服务器就可以应付；

QPS达到100： 假设关系型数据库的每次请求在0.01秒完成（理想），假设单页面只有一个SQL查询，那么100QPS意味着1秒中完成100次请求，但此时我们不能保证数据库查询能完成100次；

方案：数据库缓存层、数据库的负载均衡；

QPS达到800： 假设我们使用 百兆宽带，意味着网站出口的实际带宽是8M左右，假设每个页面是有10k，在这个并发的条件下，百兆带宽已经被吃完；

方案：CDN加速、负载均衡

QPS达到1000： 假设使用Redis缓存数据库查询数据，每个页面对Redis请求远大于直接对DB的请求；Redis的悲观并发数在5W左右，但有可能之前内网带宽已经被吃光，表现出不稳定；

方案：静态HTML缓存

QPS达到2000： 文件系统访问锁都成为了灾难；

方案：做业务分离，分布式存储；

流量优化： 防盗链处理（把一些恶意的请求拒之门外）

前端优化： 减少HTTP请求、添加异步请求、启用浏览器的缓存和文件压缩、CDN加速、建立独立的图片服务器；

服务端优化： 页面静态化处理、并发处理、队列处理；

数据库优化： 数据库的缓存、分库分表、分区操作、读写分离、负载均衡

Web服务器优化： 负载均衡

单台服务器每天PV计算

原理： 每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间

公式： ( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)

机器： 峰值时间每秒QPS / 单台机器的QPS = 需要的机器。

关注「 冰河技术 」微信公众号，后台回复 “设计模式” 关键字领取《深入浅出Java 23种设计模式》PDF文档。回复“Java8”关键字领取《Java8新特性教程》PDF文档。两本PDF均是由冰河原创并整理的超硬核教程，面试必备！！

好了，今天就聊到这儿吧！别忘了点个赞，给个在看和转发，让更多的人看到，一起学习，一起进步！！

如果你觉得冰河写的还不错，请微信搜索并关注「 冰河技术 」微信公众号，跟冰河学习高并发、分布式、微服务、大数据、互联网和云原生技术，「 冰河技术 」微信公众号更新了大量技术专题，每一篇技术文章干货满满！不少读者已经通过阅读「 冰河技术 」微信公众号文章，吊打面试官，成功跳槽到大厂；也有不少读者实现了技术上的飞跃，成为公司的技术骨干！如果你也想像他们一样提升自己的能力，实现技术能力的飞跃，进大厂，升职加薪，那就关注「 冰河技术 」微信公众号吧，每天更新超硬核技术干货，让你对如何提升技术能力不再迷茫！

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com