文章目录
-
- 零、三种不同的负载均衡
- 一、常见行业负载均衡方案
-
- [1. 电商与互联网服务](#1. 电商与互联网服务)
- [2. 金融与支付系统](#2. 金融与支付系统)
- [3. 云计算与分布式存储](#3. 云计算与分布式存储)
- 二、负载均衡策略概述
-
- [1. 无状态负载均衡（强调公平性）](#1. 无状态负载均衡（强调公平性）)
- [2. 有状态的负载均衡（强调正确性）](#2. 有状态的负载均衡（强调正确性）)
- [三、 总结](#三、 总结)
零、三种不同的负载均衡
- DNS 负载均衡： 以客户端请求应用服务器为例，如下图所示，客户端会将请求的 URL 发送给 DNS 服务器，DNS 服务器根据用户所处的网络区域选择最近机房为其提供服务，这个选择过程就是 DNS 负载均衡。
- 硬件负载均衡：每个网络区域都会存在一个或者多个服务器集群，这里会通过硬件负载均衡器（例如 F5）将请求负载均衡到具体的服务器集群，这个过程就是硬件负载均衡。
- 软件负载均衡：最后，在集群内通过 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、预分片、流量切换等方案。
通过合理的负载均衡策略，可大幅提升系统的性能、可用性和扩展能力，为高并发业务提供稳健支撑。