软件体系结构——负载均衡

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

负载均衡技术

基于http的负载均衡

1.根据用户的http请求计算出真实的web服务器地址

2.重定向,将该地址写入http发回浏览器

3.浏览器重新访问

优点:应用层实现简单

缺点:浏览器两次访问

反向代理负载均衡

用户请求来的时候,通过反向代理服务器(如,apache、nginx),将请求转发到后端多台服务器的一台。

优点:应用层部署简单;隐藏重要服务器IP;

缺点:

请求加转发,两次。

反向代理如果要实现隐藏服务器IP,需要内外网双网卡。

反向代理服务器肯成为瓶颈。

基于DNS负载均衡

在用户发出请求时,在DNS对域名进行解析时,分配不同IP的服务器

优点:传输层性能快

缺点:

DNS服务器可能成为瓶颈。

DNS多级解析会产生缓存,如果目标服务器挂掉,会导致访问失败。

基于NAT负载均衡

将一个外部地址进行多个内部地址的映射,动态调配

优点:传输层性能快。

缺点:

NAT可能成为瓶颈,尤其数据量大如大型文件、视频时,速度慢。

负载均衡算法

静态均衡

轮询法

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

随机法

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

源地址哈希

通过哈希算法进行分配

优点:对于大量分布于某个节点的情况,可以进行人为干预,如灰度分布

缺点:

某个节点故障会该节点导致无法使用。

热点事件导致同节点涌入时,冷热分配不均,无法有效发挥集群性能,此时一般切换为轮询。

加权轮询

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

加权随机

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

键值范围法

根据键值范围分配,如根据键的范围进行负载,比如0到10万的用户清求走第一个节点服务器,10万到20万的用户请求走第二个节点服务器......以此类推。

优点:容易水平扩展,随着用户量增加,可以增加节点而不影响旧数据

缺点:容易负载不均衡,比如新注册的用户活跃度高,旧用户活跃度低,那么压力就全在新增的服务节点上,旧服务节点性能浪费。而且也容易单点故障,无法满足高可用。

动态负载

最小连接数

选择当前连接数最小的服务器

缺点:每次连接断开需要重新计数

加权最小连接数

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

最快响应速度

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

观察模式法

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

加权百分比

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

相关推荐
SkyWalking中文站20 小时前
认识 Horizon UI · 1/17:SkyWalking 新一代可观测性控制台
运维·前端·监控
雪梨酱QAQ1 天前
Kubeneters HA Cluster部署
运维
江华森1 天前
Spring Cloud 微服务全栈实战:从 Eureka 到 Docker Compose 一文贯通
运维
江华森1 天前
Matplotlib 数据绘图基础入门
运维
江华森1 天前
NumPy 数值计算基础入门
运维
乘云数字DATABUFF5 天前
5分钟部署开源APM Databuff:OpenTelemetry全链路追踪入门实战
运维·后端
荣--7 天前
一键部署不是为了省时间 —— 它是把"买来的 PaaS"变成"自己的平台"的拐点
运维·zabbix·工程化·一键部署·平台化·边界设计
江华森7 天前
动手实战学 Docker — 从零到集群编排完全指南
运维
Avan_菜菜8 天前
FRP 内网穿透完整实战:从 HTTP 映射到 HTTPS 自签代理
运维·nginx·https
SelectDB9 天前
Litefuse 开源并推出单进程轻量模式,25 秒就能跑起来的 Agent 可观测与评估平台
运维·后端·自动化运维