负载均衡算法
负载均衡算法
说明事项
不同模型下对于代理后面的的服务器叫法不一样, 有时候叫 上游(nginx), 有时候叫 后端，有的又叫 RS(lvs 的 RealServer)，还有直接叫 server 的，大家知道是同一个东西就行。
简单分类
- 静态算法, 固定分发策略
- 动态算法(根据状态的不同分配方式由所变化)
静态算法
1. RR (Round-Robin) 轮询
轮流请求后端服务
优点：简单，性能高 特点: 不记录当前连接的状态，是一种无状态调度 缺点: 如果后端资源配置不一样, 容易造成负载不平衡
2. WRR (Weighted Round-Robin) 加权轮询
在 RR 的基础上，可以增加或减少分配给某个后端应用的流量比例;
场景: 应对后台服务性能不一致的场景, 性能好的服务器多处理一点流量;
例如: A=1, B=2;
则请求 1 给 A, 请求 2,3 给 B, 请求 4 给 A, 请求 5,6 给 B
3. random 随机算法
轮询算法实际上还是按列表环进行顺序分配;
而全随机算法, 在数据量足够大的场景下, 能达到均衡分布;
4. ip hash (Source Hashing)
区分2种场景
- 使用 源ip地址进行 hash, 一般是处理进来的流量, 源地址散列, 或源地址 HASH, 简称 SH
- 使用 目的ip地址进行 hash, 一般是处理出去的流量, Destination Hashing 简称 DH
根据这个请求的源地址进行 hash, 然后从地址列表中找出一个服务器来; 类似与 取模 运算；
优点: 同一个客户端IP的请求始终会落到一个后端节点，便于 cookie 与 session 进行会话绑定； 缺点: 后端新增或减少一个节点时，将有 1/n 流量始终不可用, 如果重启或重载配置, 则原来映射关系就会全部重新排。
5. 一致性哈希
简单理解: 划一个圈, 每个节点占一个范围；
如果有新增服务器, 就圈内找最合适的一个节点, 将它的一部分范围转交给新节点;
也可以是两个相邻节点各出让一部分
如果是某各节点故障, 就把它原来的这个范围, 给它相邻的两个节点进行瓜分；
优点: 可以在客户端实现 缺点: 节点变化时需要操作的内容有些多, 适合在客户端实现, 而不是 LB
6. 序列分配
根据键的序列进行分配; 如 ID 为 1-1000 分到 A 节点, 1001-2000 分配到 B 节点
7. 取模分配
对 key 和节点数进行取模计算后分配到相应节点
动态算法
1. 最小连接数(Least-Connection ) 简称 LC
对当前与后端服务器的连接进行统计, 谁少就把新连接给谁;
适合场景: 下载类的服务，小文件下载连接释放得快
2. 加权最少链接(Weighted Least-Connection) 简称 WLC
在 LC 的基础上增加了权重, 权重高的可以承受更多连接
3. 最快响应模式
传递连接给那些响应最快的服务器
4. 其它算法
还有一些 lvs 的不常用算法, 比较复杂，特定场景下可能有用
LBLC(局部性的最少链接): 先去目标ip的最近调度服务器, 如果不可用, 再使用 lc 算法;
LBLCR(带复制的基于局部性最少链接): 比较复杂。先去一个目标服务器小组, 按lc算法选一个节点; 如果节点不可用再选; SED(最短期望延迟), NQ(Never Queue) 最快响应模式
5. 自定义控制
如根据监控系统内的 CPU 使用率和连接数,当前大事务量等, 来改变注册中心内配置的权重 劣势: 实现复杂 优点: 非常灵活