高并发负载均衡——nginx与lvs
一、企业级web项目架构
一、企业级web项目架构图
二、架构分析
- 客户端通过企业防火墙发送请求
- 在App服务器如tomcat接收客户端请求前，面对高并发大数据量访问的企业架构，会通过加入负载均衡主备服务器将请求进行转发到不同web服务其中。
- 服务器通过访问数据库进行交互，同样高并发大数据会涉及到数据库处理高并发的方案
- 另外会添加多台服务器用作缓存、消息处理等
三、高并发
1、高并发一般会发生在下面两处
- 负载均衡处
- 数据库高并发；
2、高并发初期解决方案
应对高并发，解决方案大多从服务器级别和应用程序级别【硬件和软件】两个方向进行
第一个方向：增大服务器的CPU,增加内存，或者直接购买高性能服务器。但随着业务的不断增加，服务器性能也达到瓶颈。
第二个方向：从应用程序级别也就是软件设计编码方向，如HTML静态化、图片服务器分离、分布式缓存，减少客户端访问时并发请求的数据。
3种利用负载均衡解决高并发访问的方案
二、DNS
一、什么是DNS
简单理解：Domain Name System，域名系统是因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网。例如我们将程序发布到192.168.55.145 和144两台服务器上，通过DNS可以设置一个统一的访问入口，如www.Max1209.com对这两台服务器上的服务进行访问。用户直接访问www.Max1209.com主机名而不需记住机器IP，通过主机名，最终得到该主机名进行域名解析得到对应的IP地址进行访问。
二、DNS实现负载均衡
在DNS服务器中，可以为多个不同的IP配置同一个名字，这个数据被发送给其他名字服务器，而最终查询这个名字的客户机将在解析这个名字时随机使用其中一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，因此不同的客户访问的也就是不同地址的Web服务器。
简单说，也就是一个外观，给部署了同一个网站的n多台服务器设置同一个名字，不同地区或者不同特点的用户访问同一个名字，实际接收客户请求的是外观里的不同ip的服务器，从而达到负载均衡的目的。
同时面对更高访问量需求，DNS可以以设置成树状，多个DNS服务器将请求分发给下一个DNS服务器，N层解析之后再访问到应用服务器，这样就可以增加应用服务器的个数，应对更大并发数据请求。
但使用DNS负载均衡的时候，如果服务器发生故障，DNS继续把请求发送给故障机器，一直到把故障服务器从DNS中移走为止，这样用户就只能等到DNS连接超时后才能访问到目标网站。
三、负载均衡实现的效果
解决方案便可以横向扩充n台应用服务器，并且客户端访问与应用服务器中间加上负载均衡配置，负载均衡能实现的效果主要有三个：
- 转发功能：按照一定的算法【权重、轮询】，将客户端请求转发到不同应用服务器上，减轻单个服务器压力，提高系统并发量。
- 故障移除：通过心跳检测的方式，判断应用服务器当前是否可以正常工作，如果服务器期宕掉，自动将请求发送到其他应用服务器。
- 恢复添加：如检测到发生故障的应用服务器恢复工作，自动将其添加到处理用户请求队伍中。
三、nginx
一、nginx简介
1、nginx应用
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，由俄罗斯的程序设计师Igor Sysoev所开发，供俄国大型的入口网站及搜索引擎Rambler使用。其特点是占有内存少，并发能力强，中国大陆使用nginx网站用户有：百度、新浪、网易、腾讯等。
2、nginx的优点
- 可以运行在多个平台：Linux、Windows等
- 在高并发情况下，Nginx 可支持高达50000个并发连接数的响应。
二、nginx如何实现负载均衡
1、Nginx反向代理
Nginx利用自身反向代理功能，在conf配置文件中添加反向代理地址，以代理服务器的身份接受客户端发送过来的请求，然后将请求转发给内部网络上的应用服务器，并将从服务器上得到的结果返回给客户端，此时代理服务器对外就表现为一个服务器，不过它只负责转发请求，不负责处理。
2、Nginx转发策略：upstream目前支持的分配算法
Nginx转发请求可按照调度规则通过轮询、ip哈希、URL哈希、权重等多种方式对应用服务器做负载均衡，同时还支持后端服务器的健康检查，也就是上面讲的故障移除和恢复添加功能。
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的应用服务器，如果应用服务器down掉，能自动剔除。
2、权重
通过配置权重，指定轮询几率，权重和访问比率成正比，用于应用服务器性能不均的情况。
3、ip_哈希算法
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个应用服务器，可以解决session共享的问题。
三、配置Nginx的负载均衡与分发策略：upstream配置
扩展知识点：Nginx配置4层负载
https://www.aliyun.com/jiaocheng/130203.html
https://blog.csdn.net/hu2010shuai/article/details/54668471
总结：
默认支持七层代理转发：基于HTTP；--with-stream为四层代理转发：基于TCP,UDP；
Nginx TCP负载均衡原理上和LVS等是一致的，工作在更为底层，性能会高于原来HTTP负载均衡不少。但是，不会比LVS更为出色，LVS被置于内核模块，而Nginx工作在用户态，而且，Nginx相对比较重。
1、通过在upstream参数中添加的应用服务器IP后添加指定参数即可实现
upstream tomcatserver1 { server 192.168.72.49:8080 weight=3; server 192.168.72.49:8081; } server { listen 80; server_name 8080.max.com; #charset koi8-r; #access_log logs/host.access.log main; location / { proxy_pass http://tomcatserver1; index index.html index.htm; } }
通过以上配置，便可以实现，在访问8080.max.com这个网站时，由于配置了proxy_pass地址，所有请求都会先通过nginx反向代理服务器，在服务器将请求转发给目的主机时，读取upstream为 tomcatsever1的地址，读取分发策略，配置tomcat1权重为3，所以nginx会将大部分请求发送给49服务器上的tomcat1，也就是8080端口；较少部分给tomcat2来实现有条件的负载均衡，当然这个条件就是服务器1、2的硬件指数处理请求能力。
2、upstream深入配置
upstream myServer { server 192.168.72.49:9090 down; server 192.168.72.49:8080 weight=2; server 192.168.72.49:6060; server 192.168.72.49:7070 backup; }
1、down
表示单前的server暂时不参与负载
2、Weight
默认为1.weight越大，负载的权重就越大。
3、max_fails
允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误
4、fail_timeout
max_fails 次失败后，暂停的时间。
5、Backup
其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
四、Nginx的高可用
除了要实现网站的高可用，也就是提供n多台服务器用于发布相同的服务，添加负载均衡服务器分发请求以保证在高并发下各台服务器能相对饱和的处理请求。同样，负载均衡服务器也需要高可用，以防如果负载均衡服务器挂掉了，后面的应用服务器也紊乱无法工作。
实现高可用的方案：添加冗余。添加n台nginx服务器以避免发生上述单点故障。具体方案详见下文：keepalive+nginx实现负载均衡高可用
四、LVS
https://blog.csdn.net/weixin_42537861/article/details/81180867
一、LVS简介
1、什么是LVS
Linux Virtual Server,Linux虚拟服务器,主要使用集群技术实现和Linux操作系统实现一个高性能、高可用的服务器虚拟的服务器集群系统。
2、LVS主要组成部分
1、负载调度器(load balancer/ Director)
它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址(我们可称之为虚拟IP地址)上的。简单理解这个调度器跟Nginx的反向代理服务、DNS的域名解析实现的是同样功能。对外提供统一虚拟IP，实际用户访问的是LVS通过转发请求到指定服务器上的应用。
2、服务器池(server pool/ Realserver)
一组真正执行客户请求的服务器，执行的服务一般有WEB、MAIL、FTP和DNS等。
3、共享存储(shared storage)
它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。这也是LVS跟Nginx区别之处：LVS可通过共享存储结构实现多个应用服务器间的session共享。
3、LVS如何实现负载均衡
LVS主要通过IP负载均衡技术VS/NAT、VS/TUN、VS/DR实现负载均衡。简单介绍第一个VS/NAT，它是一种最简单的方式，所有的RealServer只需要将自己的网关指向Director即可。客户端可以是任意操作系统，但此方式下，一个Director能够带动的RealServer比较有限。在VS/NAT的方式下，Director也可以兼为一台RealServer。
二、LVS工作模式总结和比较
| NAT | TUN | DR | |
| 后端server 的要求 | any | 打开Tunneling | Non-arp device |
| server 网路 | private | LAN/WAN | LAN |
| sever 数量 | low（10-20） | high（100） | high（100） |
| server 网关 | load balancer | own router | own router |
1、lvs-nat与lvs-fullnat
- 请求和响应报文都经由Director
- lvs-nat RIP的网关要指向DIP
- lvs-fullnat ：RIP和DIP未必在同一IP网路，但能通信
2、lvs-dr与lvs-tun
- 请求报文要经由Dirctor，但响应报文由RS直接发往client
- lvs-dr：通过封装新的MAC首部实现，通过MAC网路转发
- lvs-tun：通过在源IP报文外封装新IP头实现转发，支持远距离通信
1、DR模式
DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器将响应后的处理结果直接返回给客户端用户。
DR技术可极大地提高集群系统的伸缩性。但要求调度器LB与真实服务器RS都有一块物理网卡连在同一物理网段上，即必须在同一局域网环境。
a)通过在调度器LB上修改数据包的目的MAC地址实现转发。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。 b)请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此，并发访问量大时使用效率很高，比Nginx代理模式强于此处。 c)因DR模式是通过MAC地址的改写机制实现转发的，因此，所有RS节点和调度器LB只能在同一个局域网中。需要注意RS节点的VIP的绑定(lo:vip/32)和ARP抑制问题。 d)强调下：RS节点的默认网关不需要是调度器LB的DIP，而应该直接是IDC机房分配的上级路由器的IP(这是RS带有外网IP地址的情况)，理论上讲，只要RS可以出网即可，不需要必须配置外网IP，但走自己的网关，那网关就成为瓶颈了。 e)由于DR模式的调度器仅进行了目的MAC地址的改写，因此，调度器LB无法改变请求报文的目的端口。LVS DR模式的办公室在二层数据链路层（MAC），NAT模式则工作在三层网络层（IP）和四层传输层（端口）。 f)当前，调度器LB支持几乎所有UNIX、Linux系统，但不支持windows系统。真实服务器RS节点可以是windows系统。 g)总之，DR模式效率很高，但是配置也较麻烦。因此，访问量不是特别大的公司可以用haproxy/Nginx取代之。这符合运维的原则：简单、易用、高效。日1000-2000W PV或并发请求1万以下都可以考虑用haproxy/Nginx(LVS的NAT模式) h)直接对外的访问业务，例如web服务做RS节点，RS最好用公网IP地址。如果不直接对外的业务，例如：MySQL，存储系统RS节点，最好只用内部IP地址。
DR的实现原理和数据包的改变
(a) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP
(b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
(c) IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址
(d) 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。
(e) RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP
(f) 响应报文最终送达至客户端
三、lvs的调度算法
1、常用的调度算法
- 加权轮询（Weighted Round Robin）WRR：根据Real Server 权重值进行轮询的调度。
- 最少连接（Least Connections）LC：选择连接最少的服务器。
- 加权最少连接（Weighted Least Connections）WLC：根据Real Server 权重值，选择连接数最少的服务器。
- 源地址散列（Source Hashing）SH：根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器。
- 目标地址散列调度（Destination Hashing ） DH：与SH相反的是，DH根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器。
2、其他的调度算法
- 基于局部性的最少链接（Locality-Based Least Connections）LBLC：主要是针对请求报文的目标IP地址的负载均衡调度，目前主要使用Cache集群系统。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器时可以用的且没有超载，将请求发送到该服务器，若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则使用“LC最少连接”的原则选出一个可用的服务器，将请求发送到服务器。
- 带复制的基于局部性的最少连接（Locality-Based Least Connections with Replication）LBLCR：算法也是针对目标IP地址的负载均衡，目前也主要用于Cache集群系统。它与LBLC算法不通之处时它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。
- 最短的期望的延迟调度（Shortest Expected Delay） SED：SED基于WLC算法，将请求以最短的期望的延迟方式到服务器，计算当前realserver 的负载情况计算方法：（active+1）*256/weight=overhead。
- 最少队列调度（Never Queue）NQ：如果realserver的连接数等于0就直接分配到该服务器，但是此服务器并不一定是最快的那台，如果所有服务器都是繁忙状态，它采取最短的期望延迟分配请求。
