一、静态负载均衡算法
1. 轮询（Round Robin）
原理：按顺序将请求依次分配给每个服务器，循环往复。
适用场景：服务器性能相近的集群，简单且无状态请求。
客户端请求 → Server 1 → Server 2 → Server 3 → Server 1 → ...
2. 加权轮询（Weighted Round Robin）
原理：根据服务器权重（如处理能力）分配请求，权重高的服务器接收更多请求。
适用场景：服务器性能不均（如CPU、内存差异）。
假设权重为 3:2:1（Server1 处理3次，Server2 处理2次，Server3 处理1次）：
请求序列：S1 → S1 → S1 → S2 → S2 → S3 → 重复...
3. 随机（Random）
原理：完全随机选择服务器。
适用场景：简单场景，服务器性能接近且无会话保持需求。
4. 加权随机（Weighted Random）
原理：按权重概率随机选择服务器，权重高的被选概率更高。
适用场景：需兼顾随机性和服务器性能差异。
5. 源IP哈希（IP Hash）
原理：根据客户端IP计算哈希值，固定分配到同一服务器。
适用场景：需要会话保持（Session Persistence）的应用，如购物车。
IP为192.168.1.1的请求 → Hash计算 → 固定分配到Server2
IP为192.168.1.2的请求 → Hash计算 → 固定分配到Server1
二、动态负载均衡算法
1. 最少连接数（Least Connections）
原理：将请求分配给当前活跃连接最少的服务器。
适用场景：处理长连接或请求处理时间差异较大的服务（如FTP）。
Server1连接数：5
Server2连接数：3
Server3连接数：8
新请求 → 分配到Server2（连接数最少）
2. 加权最少连接（Weighted Least Connections）
原理：结合服务器权重和连接数，计算（连接数/权重）最小的服务器。
适用场景：性能不均且需动态调整的场景。
3. 最短响应时间（Least Response Time）
原理：选择响应时间最短或延迟最低的服务器。
适用场景：对延迟敏感的服务（如实时通信、API网关）。
Server1响应时间：50ms
Server2响应时间：20ms
Server3响应时间：80ms
新请求 → 分配到Server2（响应最快）
4. 资源基于（Resource-Based）
原理：根据服务器实时资源（CPU、内存、带宽）使用率分配请求。
适用场景：需要动态感知服务器负载的场景，如高流量波动环境。
三、哈希类算法
1. 一致性哈希（Consistent Hashing）
原理：哈希环映射服务器和请求，增减服务器时仅影响邻近节点，减少数据迁移。
适用场景：分布式缓存（如Redis集群）、微服务路由。
2. URL哈希（URL Hash）
原理：根据请求的URL路径哈希，相同URL分配到同一服务器。
适用场景：缓存优化或内容局部性需求（如静态资源服务器）。
请求URL "/image.jpg" → Hash计算 → 固定分配到Server3
请求URL "/video.mp4" → Hash计算 → 固定分配到Server1
四、混合及高级算法
1. 自适应算法（Adaptive）
原理：结合多种指标（连接数、响应时间、资源使用）动态调整权重。
适用场景：云环境中的弹性伸缩（如AWS ALB、Nginx Plus）。
初始权重：Server1(3), Server2(2), Server3(1)
根据实时负载（CPU、响应时间）→ 动态调整为 Server1(2), Server2(3), Server3(2)
2. 地理负载均衡（GSLB）
原理：根据用户地理位置分配最近的服务器。
适用场景：全球分布式系统（如CDN、多区域部署）。
选择建议
会话保持需求：*优先选择IP哈希或一致性哈希。
动态调整需求：使用最少连接数或最短响应时间。
性能不均集群：加权算法（轮询/随机/最少连接）。
高可用性：结合健康检查（剔除故障节点）和动态算法。
这些算法通常由负载均衡器（如Nginx、HAProxy、F5）实现，具体选择需结合实际业务场景和服务器状态