内容简介：一、HAProxy 简介1、HAProxy 是开源、免费、快速并且可靠的一种解决方案，他可以运行在大部分主流的 Linux 服务器上。2、HAProxy 适用于负载那些特大的 WEB 站点，而这些站点通常又需要会话保持或者进行七层处理。
一、HAProxy 简介
1、HAProxy 是开源、免费、快速并且可靠的一种解决方案，他可以运行在大部分主流的 Linux 服务器上。
2、HAProxy 适用于负载那些特大的 WEB 站点，而这些站点通常又需要会话保持或者进行七层处理。
3、HAProxy 是能够提供高可用性、负载均衡以及基于 L4（TCP） 和 L7（HTTP）的应用的代理。
4、HAProxy 功能丰富，且性能稳定。
二、影响 HAProxy 负载均衡器的性能因素
1、Session 会话率：即每秒产生的会话数，这个因素取决于客户端的访问量，因此，访问量越大，Session 会话率越大，负载均衡压力就越大。
2、Session concurrency 并发会话数：即并发会话数越多，服务器处理的会话时间就越长，客户端表现出来的访问就会越慢。
3、Date rate 数据速率：它以 MB/s 或者 Mbps 来衡量，其数据量越大，并发会话数就会增加，并发会话数越多、数据速率越高，所要求使用的内存就越多。
因此，这三个因素，在高并发负载均衡中，可能会成为 HAProxy 的性能瓶颈。
三、HAProxy 负载均衡器的核心功能和关键特性
1、HAProxy 的核心功能
负载均衡：HAProxy 的负载均衡有两种模式，分别为 L4（TCP） 和 L7（HTTP），这两种负载均衡均支持以下负载均衡调度算法： roundrobin：动态轮询算法 rr：轮询算法 static-rr：静态轮询算法 lc：最少连接 IP Hash：IP 地址散列（包括源地址和目标地址） URL_PARAM Hash：对用户请求的 uri 仅 params 部分中的参数的值作hash计算 HTTP_HEADER Hash：对用户请求的 uri 的 http 头部信息作hash计算 这里仅列举常用的这些算法，当然还有其他算法，都不常用。
健康检查：其实健康检查可以算作 HAProxy 的一种工作模式，不过这种工作模式，现在几乎很少用到，所以，健康检查，一般是做为 L4（TCP） 和 L7（HTTP）的状态检查。 会话保持：对于未实现会话共享的应用集群，可通过 Insert Cookie/Rewrite Cookie/Prefix Cookie，以及上述的多种Hash方式实现会话保持。 解析 SSL：HAProxy 可以解析 HTTPS 协议，并且能够将客户端 HTTPS 请求解密为 HTTP 后向后端传输。 HTTP 请求重写和重定向：HAProxy 可以使用正则表达式将 HTTP 请求重写和重定向。 监控与统计：HAProxy 提供了基于 WEB 界面的统计信息页面，在该页面能够展示应用服务器的健康状态和数据流量。做为运维，我们可以基于此页面来开发监控程序以监控 HAProxy 的状态。
2、HAProxy 的关键特性
关于 HAProxy 的特性，其实和 HTTP 协议的特性是是息息相关的。
a、HTTP 事务模型：
- HTTP 协议是事务驱动的
- 每个请求（Request）仅能对应一个响应（Response）
- HTTP 常用链接模式
HTTP close：每个 Request 产生且仅产生一个 Response，客户端发送请求时，将建立一个从客户端到服务端的 TCP 连接，客户端发送的每一个 Request 都经过此连接传送给服务端，然后服务端发出 Response 报文。随后这个 TCP 连接将关闭，下一个 Request 将重新打开一个 tcp连接进行传送。
Keep-alive：Http close 模式下，TCP 链接会随着 Response 的关闭而关闭，因此，频繁的链接和关闭会造成资源和时间的大量消耗。为了避免这种情况，在服务器端发送 Response 时给出 content-length 的标记，让客户端知道还有多少内容没有接收到，没有接收完则tcp连接不关闭。这种模式我们称为 “Keep-alive”。
Pipelining：这种模式能够提升 Http close ,不过它任然使用 keep-alive 模式。但是在使用这种模式时，客户端不需要等待收到服务端的 Response 后才发送后续的 Request 请求。因此，这种模式在请求含有大量图片的页面时很有用，所以能够很好的提高性能。
HAProxy 支持的 5 种连接模式：
1、keep alive：分析并处理所有的 Request 和 Response（默认）， 当后端为静态或缓存服务器建议使用此模式 。
2、tunnel：仅分析处理第一个 Request 和 Response，剩余所有内容不进行任何分析直接转发。较早的版本使用，现在已基本不用。
3、passive close：在请求和响应首部加上 "connection:close" 标记的 tunnel ，在处理完第一个 Request 和 Response 后尝试关闭两端连接。
4、server close：处理完第一个 Response 后关闭和 Server 端的连接，但和客户端的连接仍然保持， 当后端为动态应用程序服务器组建议使用此模式 。
5、forced close：传输完一个response后客户端和服务端都关闭连接。
b、HAProxy 使用单线程，能够减少上下文切换时对资源的消耗。
c、HAProxy 能够最大化的利用系统本身的特性，是的系统在处理请求时能发挥出最高的性能。
四、HAProxy 安装和配置
服务器地址分配
1、HAProxy 的安装
在这里，我们采用 yum 源安装：
[root@haproxy ~]# yum -y install haproxy
2、HAProxy的配置：
a、日志配置
对于 HAProxy 的日志配置，我们这里需要介绍下系统日志的构成。对于系统日志，主要有两部分构成，即
Faciliti.priority，这种构成相当于 服务.优先级
Facility 可以是这些关键字：auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security, syslog, user, uucp 以及 local0 到 local7。local0 到 local7 是预留出来的接口，给第三方应用调用。
priority可以使用的关键字：debug, info, notice, warning, warn, err, error, crit, alert, emerg, panic 。debug 是最不严重的级别，panic 是最严重的级别。如果日志级别优先级是 info，表示比 info 严重的日志都需要记录。
而对于关键字的获取，我们可以在 rsyslog.conf 中获得，使用命令 man 5 rsyslog.conf ，一直往下找 SELECTORS（选择器）。
b、配置本机接收通过网络发来的日志，即日志服务器的配置：
[root@haproxy ~]# vim /etc/rsyslog.conf
取消上图中红框内内容的注释即可，图中已取消。
重启 rsyslog 服务
[root@haproxy ~]# systemctl restart rsyslog
c、HAProxy 的配置文件解释
HAProxy 的配置文件位于 /etc/haproxy/ 目录下，如图：
如图，HAProxy 的配置文件分为 5 部分：global、defaults、frontend、backend static、backend app
但是在实际配置过程中，我们可将后面三部分简化为 listen。因此，我们在这里对 global、defaults 部分的配置字段做一一解释，如下表：
d、HAProxy 配置文件修改
一般情况下，第一部分 global 和第二部分 defaults 不用修改，保持默认即可，因此，我们这里主要进行第三部分 listen 的修改。
我们将
行下的部分全部删除，然后添加 listen 部分：
listen stats #这里的 stats 可以自定义
bind 0.0.0.0:1050 #监听端口，可自定义
stats refresh 30s #统计页面自动刷新时间
stats uri /monitor #统计页面 url
stats realm Haproxy Monitor #统计页面密码框提示文本
stats auth admin:admin #统计页面用户名和密码
stats hide-version #隐藏统计界面上的 HAProxy 的版本信息
listen myweb 0.0.0.0:80 #可以自定义命名，网址+ip+端口
cookie SERVERID rewrite
balance roundrobin #动态轮询调度算法
server web1 172.16.0.3:80 cookie application1instances1 check inter 2000 rise 2 fall 5
server web2 172.16.0.4:80 cookie application1instances2 check inter 2000 rise 2 fall 5 #表示后端服务器 web1 和 web2 ，IP 地址分别为 172.16.0.3 和 172.16.0.4，通过写cookie信息设置状态，application，应用，instances，实例，check对服务器做健康检查，inter 2000毫秒，如果连续两次检查都是成功的（rise 2）则说明服务器是好的，如果连续五次检查都是失败的（fall 5）则说明服务器是坏的。
如图：
保存并退出，启动或重启（之前有启动过） HAProxy 服务。
[root@haproxy ~]# systemctl start haproxy
或
[root@haproxy ~]# systemctl restart haproxy
e、验证
首先，我们验证站点访问，在浏览器中输入 http://192.168.20.140/ ，结果如图：
其次，我们验证监控站点，在浏览器中输入 http://192.168.20.140:1050/monitor ，如图：
会要我们输入用户名和密码，就是我们在配置文件中设置的 admin
登陆之后，界面如下：
如图，在左边红框内，主要展示一些 HAProxy 服务器的状态，包括启动时间、PID号等等，而右边红框内主要展示颜色标志，具体的颜色变化会展示在下边的 web1、web2 的行，需要注意的时，4个颜色的变化，如下图：
表示服务在线正常
表示服务在线，但是已经 down 掉
表示服务已经 down 掉，但是正在恢复中
表示服务已经全部 down 掉，无法提供服务
以上配置是 HAProxy 的 L7（HTTP）负载均衡配置。下面我们看下 L4（TCP）负载均衡配置
五、HAProxy 的 L4 （TCP）配置
其实 HAProxy 的 L4（TCP）配置和 L7（HTTP）配置是差不多的，只需要更改如下三个地方
1、将配置文件中 mode http 修改为 mode tcp ，表示开启 TCP 模式
2、将配置文件中 option httplog 修改为 option tcplog ，表示开启 tcplog
3、将 balance roundeobin 修改为 balance source，表示基于客户端的 IP 会话保持。
而其他部分暂时可以不用修改，在使用过程中，我们可以根据实际数据进行更改。
六、日志查看
前面我们配置了 HAProxy 的日志，它的日志会记录在系统的 messages 日志里面，现在我们来看一下，日志的内容
当我们访问站点时，日志会在 messages 中刷新，如上图，主要会记录后端服务器的访问情况以及当会话闲置时 HAProxy 的状态日志，当然，我们只是配置仅限有日志，并未配置其他类型的日志进行记录，所以这里只会显示这么多。
到此为止，我们的 HAProxy 部署配置已结束，如果想了解更多相关的只是，请参阅官方文档。 官方文档
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- dubbo集群和负载均衡
- 认识认识LVS负载均衡集群
- Nginx+Tomcat 配置负载均衡集群
- Keepalived+Nginx搭建高可用负载均衡集群
- 在 Kubernetes 集群中 gRPC 的负载均衡
- 利用saltstack一键部署高可用负载均衡集群
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Python基础教程
[挪] Magnus Lie Hetland / 袁国忠 / 人民邮电出版 / 2018-2-1 / CNY 99.00
本书包括Python程序设计的方方面面：首先从Python的安装开始，随后介绍了Python的基础知识和基本概念，包括列表、元组、字符串、字典以及各种语句；然后循序渐进地介绍了一些相对高级的主题，包括抽象、异常、魔法方法、属性、迭代器；此后探讨了如何将Python与数据库、网络、C语言等工具结合使用，从而发挥出Python的强大功能，同时介绍了Python程序测试、打包、发布等知识；最后，作者结合......一起来看看 《Python基础教程》 这本书的介绍吧!
