软件体系结构——负载均衡 - 指南

常见场景，用什么处理方法

负载均衡技术

基于http的负载均衡

1.根据用户的http请求计算出真实的web服务器地址
2.重定向，将该地址写入http发回浏览器
3.浏览器重新访问
优点：应用层完成方便
缺点：浏览器两次访问

反向代理负载均衡

用户请求来的时候，经过反向代理服务器（如，apache、nginx），将请求转发到后端多台服务器的一台。
优点：应用层部署简单；隐藏重要服务器IP；
缺点：
请求加转发，两次。
反向代理如果要达成隐藏服务器IP，应该内外网双网卡。
反向代理服务器肯成为瓶颈。

基于DNS负载均衡

在用户发出请求时，在DNS对域名进行解析时，分配不同IP的服务器
优点：传输层性能快
缺点：
DNS服务器可能成为瓶颈。
DNS多级解析会产生缓存，如果目标服务器挂掉，会导致访问失败。

基于NAT负载均衡

将一个外部地址进行多个内部地址的映射，动态调配
优点：传输层性能快。
缺点：
NAT可能成为瓶颈，尤其数据量大如大型材料、视频时，速度慢。

负载均衡算法

静态均衡

轮询法

顺序轮流分配，不关系当前节点实际负载。（令牌环网思想）

随机法

随机分配到各个节点，事实上当数量到一定程度，接近于平均分配，和轮询无差别。

源地址哈希

利用哈希算法进行分配
优点：对于大量分布于某个节点的情况，可以进行人为干预，如灰度分布
缺点：
某个节点故障会该节点导致无法使用。
热点事件导致同节点涌入时，冷热分配不均，无法有用发挥集群性能，此时一般切换为轮询。

加权轮询

给配置高，负载低给予更高权重，进行双层轮询。（改进Clock置换算法，未使用未修改）

加权随机

加权后，根据权重随机分配，非顺序

键值范围法

根据键值范围分配，如根据键的范围进行负载，比如0到10万的用户清求走第一个节点服务器，10万到20万的用户请求走第二个节点服务器……以此类推。
优点：容易水平扩展，随着用户量增加，能够增加节点而不影响旧素材；
缺点：容易负载不均衡，比如新注册的用户活跃度高，旧用户活跃度低，那么压力就全在新增的服务节点上，旧服务节点性能浪费。而且也容易单点故障，无法满足高可用。

动态负载

最小连接数

选择当前连接数最小的服务器
缺点：每次连接断开要求重新计数

加权最小连接数

考虑处理性能，进行最小连接数分配

最快响应速度

给响应快的节点分配更多需求

观察模式法

同时考虑最小连接数和最快响应速度

加权百分比

综合考虑：节点利用率、硬盘速率、进程个数等等