零、三种不同的负载均衡

1. DNS 负载均衡： 以客户端请求应用服务器为例，如下图所示，客户端会将请求的 URL 发送给 DNS 服务器，DNS 服务器根据用户所处的网络区域选择最近机房为其提供服务，这个选择过程就是 DNS 负载均衡。
2. 硬件负载均衡：每个网络区域都会存在一个或者多个服务器集群，这里会通过硬件负载均衡器（例如 F5）将请求负载均衡到具体的服务器集群，这个过程就是硬件负载均衡。
3. 软件负载均衡：最后，在集群内通过 Nginx 这样的软件负载均衡器将请求分配到对应的应用服务器，就完成了整个负载均衡的过程。

在这三类负载均衡中，软件负载均衡是我们接触最多的，其他两类只有在特定的场景下才会存在，本文暂时只关注软件负载。

在分布式系统架构中，负载均衡起着至关重要的作用，决定了请求如何被分配到后端实例，从而影响系统的公平性与正确性。常见的负载均衡方案可分为无状态负载均衡与有状态负载均衡，其中不同行业通常采用不同的策略。

一、常见行业负载均衡方案

1. 电商与互联网服务

• Nginx + 轮询或权重轮询：前端流量通常通过 Nginx 进行负载均衡，采用轮询或权重轮询策略，适用于高并发环境。
• CDN（内容分发网络）：在流量高峰时减少原服务器压力，提升页面加载速度。

2. 金融与支付系统

• 一致性 Hash 负载均衡：确保用户请求落在相同的后端实例，减少数据同步开销。
• 全状态负载均衡（中央路由调度）：通过统一网关管理请求，确保交易一致性。

3. 云计算与分布式存储

• 最少连接数策略：优先选择当前连接最少的实例，平衡系统负载。
• 服务网格（Service Mesh）：如 Istio，增强服务间通信的灵活性。

二、负载均衡策略概述

1. 无状态负载均衡（强调公平性）

无状态负载均衡意味着后端实例彼此对等，一个请求无论被分配到哪个实例，都能得到相同且正确的处理结果。常见的策略包括：

• 轮询策略：请求按照顺序依次分配给不同实例，适用于处理能力均衡的实例。
• 权重轮询策略：基于实例的处理能力赋予不同权重，以更合理地分配请求。
• 随机策略、最少连接数策略：用于实例性能无明显差异的情况。

2. 有状态的负载均衡（强调正确性）

有状态负载均衡确保请求被分配到正确的后端实例，防止数据不一致或错误。主要策略包括：

• Hash 负载均衡：基于用户 ID 或 IP 进行 Hash 计算，确保同一用户请求落在同一实例。
• 一致性 Hash 负载均衡：解决 Hash 方案扩容时的迁移问题。
• 全状态负载均衡：使用中央索引服务管理后端实例 ID 和状态信息，实现精确路由。

三、 总结

• 电商、金融、云计算行业负载均衡各有侧重点，如 Nginx 轮询、Hash 策略、最少连接数等。
• 无状态负载均衡适用于大多数互联网业务，如轮询、权重轮询等。
• 有状态负载均衡适用于需要数据一致性的场景，如支付系统、分布式数据库。
• 扩容 Hash 路由的 MySQL 集群时，可采用一致性 Hash、预分片、流量切换等方案。

通过合理的负载均衡策略，可大幅提升系统的性能、可用性和扩展能力，为高并发业务提供稳健支撑。