介绍
HAProxy 代表 High Availability Proxy，是一种流行的开源软件 TCP/HTTP 负载均衡器和代理解决方案，可以在 Linux、macOS 和 FreeBSD 上运行。 它最常见的用途是通过将工作负载分布在多台服务器上来提高服务器环境的性能和可靠性（例如 网络、应用程序、数据库）。 它用于许多备受瞩目的环境，包括：GitHub、Imgur、Instagram 和 Twitter。
在本指南中，您将大致了解 HAProxy 是什么，查看负载平衡术语以及如何使用它来提高您自己的服务器环境的性能和可靠性的示例。
HAProxy 术语
在讨论负载平衡和代理时，有许多重要的术语和概念。 您将在以下小节中介绍常用术语。
在了解负载平衡的基本类型之前，您应该先回顾一下 ACL、后端和前端。
访问控制列表 (ACL)
关于负载平衡，ACL 用于测试某些条件并执行操作（例如 根据测试结果选择服务器，或阻止请求）。 例如，使用 ACL 可以根据各种因素（例如模式匹配和与后端的连接数）灵活地转发网络流量。
ACL 示例：
acl url_blog path_beg /blog
如果用户请求的路径以 /blog 开头，则匹配此 ACL。 例如，这将匹配 http://yourdomain.com/blog/blog-entry-1 的请求。
有关 ACL 使用的详细指南，请查看 HAProxy 配置手册 。
后端
后端是一组接收转发请求的服务器。 后端在 HAProxy 配置的 backend 部分中定义。 在最基本的形式中，后端可以定义为：
- 使用哪种负载平衡算法
- 服务器和端口列表
后端可以包含一个或多个服务器。 一般来说，向后端添加更多服务器将通过将负载分散到多台服务器上来增加潜在的负载能力。 通过这种方式还可以提高可靠性，以防您的某些后端服务器不可用。
下面是两个后端配置的示例，web-backend 和 blog-backend 每个都有两个 Web 服务器，侦听端口 80：
backend web-backend balance roundrobin server web1 web1.yourdomain.com:80 check server web2 web2.yourdomain.com:80 check backend blog-backend balance roundrobin mode http server blog1 blog1.yourdomain.com:80 check server blog1 blog1.yourdomain.com:80 check
balance roundrobin 行指定负载均衡算法，详情请参见负载均衡算法 部分。
mode http 指定将使用第 7 层代理，这在 负载平衡类型 部分中进行了说明。
server 指令末尾的 check 选项指定应在这些后端服务器上执行运行状况检查。
前端
前端定义了如何将请求转发到后端。 前端在 HAProxy 配置的 frontend 部分中定义。 它们的定义由以下部分组成：
- 一组 IP 地址和一个端口（例如 10.1.1.7:80、*:443 等）
- ACL
use_backend规则，根据匹配的 ACL 条件定义要使用的后端，和/或处理所有其他情况的default_backend规则
可以将前端配置为各种类型的网络流量，如下一节所述。
负载平衡的类型
现在您已经了解了负载平衡中使用的基本组件，您可以进入负载平衡的基本类型。
无负载平衡
没有负载平衡的简单 Web 应用程序环境可能如下所示：
在此示例中，用户直接连接到您的 Web 服务器，位于 yourdomain.com 并且没有负载平衡。 如果您的单个 Web 服务器出现故障，用户将无法再访问您的 Web 服务器。 此外，如果许多用户试图同时访问您的服务器并且它无法处理负载，他们可能会体验缓慢或者他们可能根本无法连接。
第 4 层负载均衡
将网络流量负载平衡到多个服务器的最简单方法是使用第 4 层（传输层）负载平衡。 这种负载均衡方式会根据IP范围和端口转发用户流量（即 如果对 http://yourdomain.com/anything 的请求进入，则流量将被转发到处理 port 80 上的 yourdomain.com 的所有请求的后端。 有关第 4 层的更多详细信息，请查看我们的 网络简介 的 TCP 小节。
下面是一个简单的第 4 层负载均衡示例图：
用户访问负载均衡器，该负载均衡器将用户的请求转发到 web-backend 后端服务器组。 无论选择哪个后端服务器，都将直接响应用户的请求。 通常，web-backend 中的所有服务器都应该提供相同的内容——否则用户可能会收到不一致的内容。 请注意，两个 Web 服务器都连接到同一个数据库服务器。
第 7 层负载均衡
另一种更复杂的负载平衡网络流量的方法是使用第 7 层（应用层）负载平衡。 使用第 7 层允许负载均衡器根据用户请求的内容将请求转发到不同的后端服务器。 这种负载平衡模式允许您在同一个域和端口下运行多个 Web 应用程序服务器。 有关第 7 层的更多详细信息，请查看我们的 网络简介 的 HTTP 小节。
下面是第 7 层负载均衡的简单示例图：
在此示例中，如果用户请求 yourdomain.com/blog，他们将被转发到 blog 后端，这是一组运行博客应用程序的服务器。 其他请求被转发到 web-backend，它可能正在运行另一个应用程序。 在此示例中，两个后端都使用相同的数据库服务器。
示例前端配置的片段如下所示：
frontend http bind *:80 mode http acl url_blog path_beg /blog use_backend blog-backend if url_blog default_backend web-backend
这配置了一个名为 http 的前端，它处理端口 80 上的所有传入流量。
如果用户请求的路径以 /blog 开头，则 acl url_blog path_beg /blog 匹配请求。
use_backend blog-backend if url_blog 使用 ACL 将流量代理到 blog-backend。
default_backend web-backend 指定所有其他流量将被转发到 web-backend。
负载平衡算法
使用的负载平衡算法决定了负载平衡时将选择后端中的哪个服务器。 HAProxy 提供了多种算法选项。 除了负载平衡算法之外，还可以为服务器分配一个 weight 参数来控制与其他服务器相比选择服务器的频率。
一些常用的算法如下：
循环赛
Round Robin 轮流选择服务器。 这是默认算法。
最小连接
选择连接数最少的服务器。 对于较长的会话，建议这样做。 同一后端的服务器也以循环方式轮换。
来源
这会根据用户发出请求的源 IP 地址的哈希值来选择要使用的服务器。 此方法确保相同的用户将连接到相同的服务器。
粘性会话
某些应用程序要求用户继续连接到同一后端服务器。 这可以通过 sticky sessions 来实现，在需要它的后端使用 appsession 参数。
健康检查
HAProxy 使用健康检查来确定后端服务器是否可用于处理请求。 这样可以避免在服务器不可用时手动从后端删除服务器。 默认的健康检查是尝试建立到服务器的 TCP 连接。
如果服务器未能通过健康检查，因此无法为请求提供服务，它会在后端自动禁用，并且在它再次恢复健康之前不会将流量转发给它。 如果后端中的所有服务器都发生故障，则服务将变得不可用，直到其中至少有一个后端服务器再次恢复健康。
对于某些类型的后端，如数据库服务器，默认的健康检查不一定要确定服务器是否仍然健康。
Nginx Web 服务器也可以用作独立的代理服务器或负载均衡器，并且经常与 HAProxy 结合使用，以实现其缓存和压缩功能。
高可用性
本教程中描述的第 4 层和第 7 层负载平衡设置都使用负载平衡器将流量引导到多个后端服务器之一。 但是，您的负载均衡器是这些设置中的单点故障； 如果它出现故障或被请求淹没，它可能会导致您的服务出现高延迟或停机时间。
高可用性 (HA) 设置被广泛定义为没有单点故障的基础架构。 它通过向架构的每一层添加冗余来防止单个服务器故障成为停机事件。 负载均衡器有助于后端层（Web/应用程序服务器）的冗余，但对于真正的高可用性设置，您还需要有冗余负载均衡器。
这是一个高可用性设置的图表：
在此示例中，您在一个静态 IP 地址后面有多个负载平衡器（一个主动和一个或多个被动），可以从一台服务器重新映射到另一台服务器。 当用户访问您的网站时，请求会通过外部 IP 地址到达活动负载均衡器。 如果该负载平衡器发生故障，您的故障转移机制将检测到它并自动将 IP 地址重新分配给其中一台被动服务器。 有许多不同的方法可以实现主动/被动 HA 设置。 要了解更多信息，请阅读 如何使用浮动 IP 。
结论
既然您已经了解了负载均衡，并且知道如何使用 HAProxy，那么您就有了开始提高自己服务器环境的性能和可靠性的坚实基础。
如果您有兴趣存储 HAProxy 的输出以供以后查看，请查看 如何在 CentOS 8 上使用 Rsyslog 配置 HAProxy 日志记录 [快速入门]
如果您要解决问题，请查看 常见 HAProxy 错误 。 如果需要进一步的故障排除，请查看 如何排除常见 HAProxy 错误 。
