https://www.scalescale.com/nginx-haproxy-varnish-comparison/#
四层转发tcp(lvs) 七层代理http(haproxy)
稳定性的适合用lvs 网站负载适合用haproxy nginx
haproxy类似nginx、apache 均是7层负载：动静分离，比较智能，可以实现高可用+负载均衡+支持虚拟主机
和nginx很像，但是haproxy（不可以缓存）和nginx（可以缓存），二者都是httpd的代理
haproxy
HAProxy是一个使用C语言编写的自由及开放源代码软件[1]，其提供高可用性、负载均衡，以及基于TCP和HTTP的应用程序代理。支持虚拟主机。
HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的web服务器不被暴露到网络上。
HAProxy实现了一种事件驱动,单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以使每个CPU时间片(Cycle)做更多的工作。
包括 GitHub、Bitbucket[3]、Stack Overflow[4]、Reddit、Tumblr、Twitter[5][6]和
Tuenti[7]在内的知名网站，及亚马逊网络服务系统都使用了HAProxy。 [1]
事件驱动 （计算机领域的事件驱动）
事件驱动是指在持续事务管理过程中，进行决策的一种策略，即跟随当前时间点上出现的事件，调动可用资源，执行相关任务，使不断出现的问题得以解决，防止事务堆积。在计算机编程、公共关系、经济活动等领域均有应用。
haproxy的功能
HAProxy是TCP / HTTP反向代理服务器，尤其适合于高可用性环境
可以针对HTTP请求添加cookie，进行路由后端服务器
可平衡负载至后端服务器，并支持持久连接
支持基于cookie进行调度
支持所有主服务器故障切换至备用服务器
支持专用端口实现监控服务
支持不影响现有连接情况下停止接受新连接请求
可以在双向添加，修改或删除HTTP报文首部
支持基于pattern实现连接请求的访问控制
通过特定的URI为授权用户提供详细的状态信息
配置HAProxy Session亲缘性的三种方式
haproxy负载均衡保持客户端和服务器Session亲缘性的三种方式:
1 用户IP 识别
haproxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令） 配置指令 balance source
2.cookie 识别
haproxy 将WEB服务端发送给客户端的cookie中插入(或添加前缀)haproxy定义的后端的服务器COOKIE ID。
配置指令例举 cookie SESSION_COOKIE insert indirect nocache
用firebug可以观察到用户的请求头的cookie里 有类似" Cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5; SESSION_COOKIE=app1"
SESSION_COOKIE=app1就是haproxy添加的内容
3 session 识别
haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。
配置指令例举 appsession JSESSIONID len 64 timeout 5h request-learn
haproxy相关的概念
（1）有关代理的概念
正向代理:
正向代理通过上面的图理解其实就是用户想从服务器拿资源数据，但是只能通过proxy服务器才能拿到
所以用户A只能去访问proxy服务器然后通过proxy服务器去服务器B拿数据
这种情况用户是明确知道你要访问的是谁，在我们生活中最典型的案例就是“翻墙“了，也是通过访问代理服务器最后访问外网的
反向代理:
反向代理其实就是客户端去访问服务器时，他并不知道会访问哪一台，感觉就是客户端访问了Proxy一样
而实则就是当proxy关口拿到用户请求的时候会转发到代理服务器中的随机（算法）某一台
而在用户看来，他只是访问了Proxy服务器而已，典型的例子就是负载均衡了
实验环境
准备三台新的虚拟机
三台7版本的虚拟机+一台7版本的物理机
主机名 IP 服务
虚拟机server1 172.25.63.1 haproxy,httpd，代理服务器
虚拟机server2 172.25.63.2 httpd,php，后端服务器
虚拟机server3 172.25.63.3 httpd,php，后端服务器
物理机 172.25.63.250 测试端
搭建一个基本的haproxy服务器
三台虚拟机：
虚拟机1调度器：
yum install haproxy -y (建议用rpm包装)
cd /etc/haproxy/
vim haproxy.cfg
查看该服务的版本
查看安装后生成了什么文件
global
log 127.0.0.1 local2 #全局的日志配置，使用log关键字
chroot /var/lib/haproxy #改变当前工作目录
#修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot()操作，可以提升haproxy的安全级别，不过需要注意的是要确保指定的目录为空目录且任何用户均不能有写权限
pidfile /var/run/haproxy.pid #当前进程id文件
maxconn 4000 #设定每个haproxy进程所接受的最大并发连接数
user haproxy
group haproxy
daemon #让haproxy以守护进程的方式工作于后台
defaults
mode http #默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK
log global #应用全局的日志配置
option httplog # 启用日志记录HTTP请求，默认haproxy日志记录是不记录HTTP请求日志
option dontlognull # 启用该项，日志中将不会记录空连接。所谓空连接就是在上游的负载均衡器 或者监控系统为了探测该服务是否存活可用时，需要定期的连接或者获取某固定的组件或页面，或者探测扫描端口是否在监听或开放等动作被称为空连接；官方文档中标注，如果该服务上游没有其他的负载均衡器的话，建议不要使用该参数，因为互联网上的恶意扫描或其他动作就不会被记录下来
option http-server-close #每次请求完毕后主动关闭http通道
option forwardfor except 127.0.0.0/8
option redispatch
# 当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到cookie中，以保证会话的SESSION持久性；
而此时，如果后端的服务器宕掉了， 但是客户端的cookie是不会刷新的，如果设置此参数，将会将客户的请
求强制定向到另外一个后端server上，以保证服务的正常。
retries 3 # 定义连接后端服务器的失败重连次数，连接失败次数超过此值后将会将对应后端
服务器标记为不可用
timeout http-request 10s #http请求超时时间
timeout queue 1m #一个请求在队列里的超时时间
timeout connect 10s #连接超时
timeout client 1m #客户端超时
timeout server 1m #服务器端超时
timeout http-keep-alive 10s #设置http-keep-alive的超时时间
timeout check 10s #检测超时
maxconn 3000 #每个进程可用的最大连接数
监控页面添加认证:
#listen：可以理解为frontend和backend的组合体
listen admin *:8080
stats enable
stats uri /status # 监控页面地址
stats auth admin:westos # 管理帐号和密码
stats refresh 5s #刷新频率
listen westos *:80 #监听的实例名称,地址和端口
balance roundrobin #负载均衡算法
server web1 172.25.42.13:80 check
server web2 172.25.42.14:80 check
安装改服务为之后会建立这个用户
设置加密访问，并且监控页面5s刷新一次
监控页面添加认证:
#listen：可以理解为frontend和backend的组合体
listen admin *:8080
stats enable
stats uri /status # 监控页面地址
stats auth admin:westos # 管理帐号和密码
stats refresh 5s #刷新频率
listen westos *:80 #监听的实例名称,地址和端口
balance roundrobin #负载均衡算法
server web1 172.25.42.13:80 check
server web2 172.25.42.14:80 check
两台real server
/etc/init.d/httpd start
编辑测试页面，并开启http
编辑测试页面，并开启http
监控页面添加认证:
#listen：可以理解为frontend和backend的组合体
listen admin *:8080
stats enable
stats uri /status # 监控页面地址
stats auth admin:westos # 管理帐号和密码
stats refresh 5s #刷新频率
关掉server3的htppd服务
刷新页面
后端服务器恢复正常
监控页面又显示正常
日志监控：
$ModLoad imudp #接受 haproxy 日志
$UDPServerRun 514
vim /etc/rsyslog.conf
*.info;mail.none;authpriv.none;cron.none;local2.none /var/log/messages
local2.* /var/log/haproxy.log #日志文件位置
自带健康检查：（测试）
给haproxy服务器添加日志
查看日志格式
编辑日志服务的配置文件，打开UDP接口，创建haproxy的日志文件，重启服务
查看日志
可以使用多curl 172.25.63.1访问几次，就可以在日志中看到访问的是后端的服务器日志
动态静态访问分离：（可以自己加虚拟主机）
server1安装apache
修改HTTP的的端口，因为haproxy已经使用了80端口
编辑重定向页面
开启服务
#frontend：用来匹配接收客户所请求的域名，uri等，并针对不同的匹配，做不同的请求处理
frontend westos *:80
acl url_static path_beg -i /images
acl url_static path_end -i .jpg .gif .png
use_backend static if url_static
default_backend app (默认访问app)
#backend：定义后端服务器集群
backend static （静态）
#balance roundrobin
server web2 172.25.42.14:80 check
backend app
#balance roundrobin
server web1 172.25.42.13:80 check
server local 172.25.42.12:8000 backup （如果后端real server down掉 则调度报错页面 但是正常情况下不会访问 因为 是“backup”）
默认到server2,app
8000端口访问server1
url_static 默认根目录
错误重定向：
frontend westos *:80
acl url_static path_beg -i /images (以什么开头 默认根目录)
acl url_static path_end -i .jpg .gif .png （以什么结尾）
acl badhost src 172.25.42.250 （设定谁不能访问我)
block if badhost
errorloc 403 http://172.25.42.12:8000 (注意端口不要冲突)
（403：服务器拒绝你的访问 服务器设定你是坏的 ）（如果是403错误就重定向到 172.25.254.12：8000）
use_backend static if url_static
default_backend app
backend static
balance roundrobin
server web2 172.25.42.14:80 check
backend app
balance roundrobin
server web1 172.25.42.13:80 check
frontend westos *:80
acl url_static path_beg -i /images (以什么开头 默认根目录)
acl url_static path_end -i .jpg .gif .png （以什么结尾）
acl badhost src 172.25.42.250 （设定谁不能访问我)
redirect location http://172.25.42.12:8000 if badhost （如果出现错误访问 就重定向 不管是什么错误）
use_backend static if url_static
default_backend app
backend static
balance roundrobin
server web2 172.25.42.14:80 check
backend app
balance roundrobin
server web1 172.25.42.13:80 check
301永久重定向:(一般推荐用301 302临时重定向 有恶意刷点击的嫌疑)
acl westos.org hdr_beg(host) -i westos.org
acl 172.25.42.12 hdr_beg(host) -i 172.25.42.12
# block if badhost
# errorloc 403 http://172.25.42.12:8000
# redirect location http://172.25.42.12:8000 if badhost
redirect code 301 location http://www.westos.org if westos.org
（以westos.org访问 自动重定向 www.westos.org）
redirect code 301 location http://www.westos.org if 172.25.42.12
（以172.25.42.12访问 自动重定向 www.westos.org）
use_backend static if url_static
default_backend app
物理机添加本地解析
回车，此处503报错为服务器出错，与我们无关
回车
连上网就可以
"""
301 redirect: 301 代表永久性转移(Permanently Moved)
302 redirect: 302 代表暂时性转移(emporarily Moved )
ps:这里也顺带记住了两个比较相近的英语单词（permanently、temporarily），嘻哈！
详细来说，301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。他们的不同在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。
读写分离：
利用haproxy实现客户端访问的读写分离
real server(两台！！！！！！！！): yum install php -y
php页面：
chmod 777 upload (默认上传目录一定要给权限)
调度机器：
acl read method GET
acl read method HEAD //两个read write 只用一个就行
acl write method PUT
acl write method POST
use_backend app if write
default_backend static (默认静态页面 为了测试 刚开始 www.westos.org 时是172.25.42.14 而写（上传时 却是在172.25.254.13 上进行的） 做到了读写分离)
backend static
balance roundrobin
server web2 172.25.42.14:80 check
backend app
balance roundrobin
server web1 172.25.42.13:80 check (默认会上传到这个real server)
server local 172.25.42.12:8000 backup
注意： /etc/init.d/haporxy reload real server:/etc/init.d/httpd restart
http://172.25.0.1/index.php
php页面：
chmod 777 upload (默认上传目录一定要给权限)
普通用户从网页上传照片会自动（也就是写操作）上传到upload目录下，因此该目录一定要给权限哦
为了便于区分：我们可以在index.html页面添加服务器的名称Filename(server2) 我这里忘了做了，可以添加上在网页进行区分
server3一样
同理：vim index.php 填写Filename:(server3)
server1重启服务
网页进行写操作（上传照片）
如果上部在index.html写了Filaname名称，此时页面应该显示Filename(server3):Browse… 因为默认在server3上
表示上传成功
注意如果出现invalid file说明图片格式不对
上传到server2的upload目录下
而server3的目录下并没有
如果后台两个服务器都宕机
haproxy服务器就会安全检测的信息
nginx:
编译源码：
tar zxf nginx-1.10.3.tar.gz
cd nginx-1.10.3
cd auto
cd cc
vim gcc (debug注释掉)
yum install pcre-devel -y
yum install openssl-devel -y
./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_stub_status_module
#--with-http_ssl_module 使支持https请求，需已安装openssl
#--with-http_stub_status_module stub_status模块主要用于查看Nginx的一些状态信息
make && make install
useradd -u 900 -s /sbin/nologin nginx
cd /usr/local/nginx
cd conf
vim nginx.conf
ln -s /usr/local/nginx/sbin/nginx /usr/local/bin/
nginx -t (检查有无语法错误)
cd /usr/local/nginx/conf
vim vim nginx.conf
user nginx nginx;
worker_processes auto; (不能超过cpu的最大数)
worker_cpu_affinity 01 10 (cpu的进程绑定 避免来会切换带来的上下文改变而消耗资源)
events {
use epoll;
worker_connections 4096;
}
http {
include mime.types;
default_type application/octet-stream;
upstream westos {
server 172.25.42.13:80;
server 172.25.42.14:80;
}
server {
listen 80;
server_name www.westos.org;
location / {
proxy_pass http://westos;
}
}
nginx -s reload
lscpu:
测试：
nginx虚拟主机配置
基于域名的虚拟主机
就是通过不同的域名区分不同的虚拟主机，基于域名的虚拟主机是企业应用最广的虚拟主机类型，几乎所有对外提供服务的网站使用的都是基于域名的虚拟主机
server {
listen 80;
server_name www.westos.org;
location / {
root html/www;
index index.html index.htm;
}
}
server {
listen 80;
server_name bbs.westos.org;
location / {
root html/bbs;
index index.html index.htm;
}
}
server {
listen 80;
server_name blog.westos.org;
location / {
root html/blog;
index index.html index.htm;
}
}
虚拟主机的别名配置
server {
listen 80;
server_name www.westos.org westos.org;
location / {
root html/www;
index index.html index.htm;
}
}
查看nginx状态信息
with-http_stub_status_module 这个模块的主要功能是记录nginx的基本访问状态信息，让使用者了解nginx的工作装陶，例如连接数等信息
检查编译安装nginx时是否设定了上述模块：
../sbin/nginx -V
nginx version: nginx/1.10.3
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --with-http_ssl_module --with-http_stub_status_module
mkdir /usr/local/nginx/conf/extra
cd /usr/local/nginx/conf/extra
vim status.conf
server{
listen 80;
server_name status.westos.org;
location / {
stub_status on;
access_log off;
}
}
cd /usr/local/nginx/conf
vim nginx.conf
include extra/status.conf;
38
39 #gzip on;
40
41 server {
42 listen 80;
43 server_name www.westos.org westos.org;
44 location / {
45 root html/www;
46 index index.html index.htm;
47 }
物理：vim /etc/hosts
添加域名：status.westos.org
location语法
这个URL可以是普通的字符串地址路径，或者是正则表达，匹配成功则执行后面大括号里的相关指令
正则表达式的前面还可以有‘～’或‘～*’等特殊的字符
server {
listen 80;
server_name www.westos.org westos.org;
root html/www;
location / { #所有location都不能匹配后的默认匹配
return 401;
}
location = / { #精确匹配/
return 402;
}
location /documents/ { #匹配常规字符串，如果有正则，则优先匹配正则
#匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
return 403;
}
location ^~ /images/ { #匹配常规字符串，不做正则匹配检查
# 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条
return 404;
}
location ~* \.(gif|jpg|jpeg)$ { #正则匹配
# 匹配所有以 gif,jpg或jpeg 结尾的请求
# 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
return 500;
}
}
location = / {
# 精确匹配 / ，主机名后面不能带任何字符串
[ configuration A ]
}
location / {
# 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
# 但是正则和最长字符串会优先匹配
[ configuration B ]
}
location /documents/ {
# 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
# 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
[ configuration C ]
}
location ~ /documents/Abc {
# 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
# 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
[ configuration CC ]
}
location ^~ /images/ {
# 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。
[ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
# 匹配所有以 gif,jpg或jpeg 结尾的请求
# 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
[ configuration E ]
}
server {
listen 80;
server_name www.westos.org westos.org;
root html/www;
location = / {
# 精确匹配 / ，主机名后面不能带任何字符串
return 401;
}
location / {
# 因为所有的地址都以 / 开头，所以这条规则将匹配到所有
请求
# 但是正则和最长字符串会优先匹配
return 402;
}
location /documents/ {
# 匹配任何以 /documents/ 开头的地址，匹配符合以后，还
要继续往下搜索
# # 只有后面的正则表达式没有匹配到时，这一条才会采>用这一条
return 403;
}
location ~ /documents/Abc {
# 匹配任何以 /documents/ 开头的地址，匹配符合以后，还
要继续往下搜索
# # 只有后面的正则表达式没有匹配到时，这一条才会采>用这一条
return 503;
}
location ^~ /images/ {
# 匹配任何以 /images/ 开头的地址，匹配符合以后，停止>往下搜索正则，采用这一条。
return 404;
}
location ~* \.(gif|jpg|jpeg)$ {
# 匹配所有以 gif,jpg或jpeg 结尾的请求
# # 然而，所有请求 /images/ 下的图片会被 config D >处理，因为 ^~ 到达不了这一条正则
return 405;
}
}
}
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/images/abc/def
000
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/images
402
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/images/
404
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/images/abc
407
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/documents/Abc.jpg
503
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/documents/images
403
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/images
402
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/images/abc
407
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/images/l/jpg
404
[root@foundation0 Desktop]# curl -s -o /dev/null -I -w "%{http_code}\n" http://www.westos.org/images/l.jpg
四层和七层负载均衡的特点及常用负载均衡Nginx、Haproxy、LVS对比
一、四层与七层负载均衡在原理上的区别
概述：
1.四层负载均衡工作在OSI模型中的四层，即传输层。四层负载均衡只能根据报文中目标地址和源地址对请求进行转发，而无法修改或判断所请求资源的具体类型，然后经过负载均衡内部的调度算法转发至要处理请求的服务器。四层负载均衡单纯的提供了终端到终端的可靠连接，并将请求转发至后端，连接至始至终都是同一个。LVS就是很典型的四层负载均衡。
2.七层负载均衡工作在OSI模型的第七层应用层，所以七层负载均衡可以基于请求的应用层信息进行负载均衡，例如根据请求的资源类型分配到后端服务器，而不再是根据IP和端口选择。七层负载均衡的功能更丰富更灵活，也能使整个网络更智能。如上图所示，在七层负载均衡两端(面向用户端和服务器端)的连接都是独立的。
3.简言之，四层负载均衡就是基于IP+端口实现的。七层负载均衡就是通过应用层资源实现的。
二、常用负载均衡软件对比
LVS的特点：
1、抗负载能力强。抗负载能力强、性能高，能达到F5硬件的60%；对内存和cpu资源消耗比较低
2、工作在网络4层，通过vrrp协议转发（ vrrp就是虚拟路由冗余协议）（仅作分发之用），具体的流量由linux内核处理，因此没有流量的产生。
2、稳定性、可靠性好，自身有完美的热备方案；（如：LVS+Keepalived）
3、应用范围比较广，工作在四层，所以不用考虑要处理的具体应用，可以对所有应用做负载均衡；
4、不支持正则处理，不能做动静分离。
5、支持负载均衡算法：rr（轮循）、wrr（带权轮循）、lc（最小连接）、wlc（权重最小连接）
6、配置 复杂，对网络依赖比较大，稳定性很高。
LVS缺点：
（1）软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
（2）如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了
Ngnix的特点：
1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构；
2、Nginx对网络的依赖比较小，理论上能ping通就就能进行负载功能；
3、Nginx安装和配置比较简单，测试起来比较方便；
4、也可以承担高的负载压力且稳定，一般能支撑超过1万次的并发；
5、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载；
7、Nginx仅能支持http、https和Email协议，这样就在适用范围较小。
8、不支持Session的直接保持，但能通过ip_hash来解决。
9、支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、Ip-hash（Ip哈希）
10、Nginx还能做Web服务器即Cache功能。
nginx的缺点：
（1）适应范围较小，仅能支持http、https、Email协议。
（2）对后端服务器的健康检查，只支持通过端口检测，不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。
HAProxy的特点：
1、支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
3、支持url检测后端的服务器出问题的检测会有很好的帮助。 /images
4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
6、HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。
9、支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）
10、不能做Web服务器即Cache
HAPorxy缺点：
（1）不支持POP/SMTP协议
（2） 不支持SPDY协议
（3） 不支持HTTP cache功能。现在不少开源的lb项目，都或多或少具备HTTP cache功能。
（4）重载配置的功能需要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好。
（5）多进程模式支持不够好
https://www.cnblogs.com/skyflask/p/6970151.html
总结：
大型网站架构：对性能有严格要求的时候可以使用lvs或者硬件F5，单从负载均衡的角度来说，lvs也许会成为主流，更适合现在大型的互联网公司；
中型网站架构：对于页面分离请求由明确规定，并且性能有严格要求时，可以使用haproxy
中小型网站架构：比如日访问量小于1000万，需要进行高并发的网站或者对网络不太严格的时候，可以使用nginx
https://blog.csdn.net/yaya_12345678/article/details/88790235
https://www.sohu.com/a/233936157_262549 LVS、Nginx 及 HAProxy 工作原理
