软件体系结构——负载均衡
常见场景,用什么处理方法
负载均衡技术
基于http的负载均衡
1.根据用户的http请求计算出真实的web服务器地址
2.重定向,将该地址写入http发回浏览器
3.浏览器重新访问
优点:应用层实现简单
缺点:浏览器两次访问
反向代理负载均衡
用户请求来的时候,通过反向代理服务器(如,apache、nginx),将请求转发到后端多台服务器的一台。
优点:应用层部署简单;隐藏重要服务器IP;
缺点:
请求加转发,两次。
反向代理如果要实现隐藏服务器IP,需要内外网双网卡。
反向代理服务器肯成为瓶颈。
基于DNS负载均衡
在用户发出请求时,在DNS对域名进行解析时,分配不同IP的服务器
优点:传输层性能快
缺点:
DNS服务器可能成为瓶颈。
DNS多级解析会产生缓存,如果目标服务器挂掉,会导致访问失败。
基于NAT负载均衡
将一个外部地址进行多个内部地址的映射,动态调配
优点:传输层性能快。
缺点:
NAT可能成为瓶颈,尤其数据量大如大型文件、视频时,速度慢。
负载均衡算法
静态均衡
轮询法
顺序轮流分配,不关系当前节点实际负载。(令牌环网思想)
随机法
随机分配到各个节点,事实上当数量到一定程度,接近于平均分配,和轮询无差别。
源地址哈希
通过哈希算法进行分配
优点:对于大量分布于某个节点的情况,可以进行人为干预,如灰度分布
缺点:
某个节点故障会该节点导致无法使用。
热点事件导致同节点涌入时,冷热分配不均,无法有效发挥集群性能,此时一般切换为轮询。
加权轮询
给配置高,负载低给予更高权重,进行双层轮询。(改进Clock置换算法,未使用未修改)
加权随机
加权后,根据权重随机分配,非顺序
键值范围法
根据键值范围分配,如根据键的范围进行负载,比如0到10万的用户清求走第一个节点服务器,10万到20万的用户请求走第二个节点服务器……以此类推。
优点:容易水平扩展,随着用户量增加,可以增加节点而不影响旧数据;
缺点:容易负载不均衡,比如新注册的用户活跃度高,旧用户活跃度低,那么压力就全在新增的服务节点上,旧服务节点性能浪费。而且也容易单点故障,无法满足高可用。
动态负载
最小连接数
选择当前连接数最小的服务器
缺点:每次连接断开需要重新计数
加权最小连接数
考虑处理性能,进行最小连接数分配
最快响应速度
给响应快的节点分配更多需求
观察模式法
同时考虑最小连接数和最快响应速度
加权百分比
综合考虑:节点利用率、硬盘速率、进程个数等等