如何实施异构服务器的负载均衡及过载保护?
零、需求缘起
第一篇文章“一分钟了解负载均衡”和大家share了互联网架构中反向代理层、站点层、服务层、数据层的常用负载均衡方法。
第二篇文章“lvs为何不能完全代替DNS轮询”和大家share了互联网接入层负载均衡需要解决的问题及架构演进。
在这两篇文章中,都强调了“负载均衡是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】”。
然而,后端的service有可能部署在硬件条件不同的服务器上:
1)如果对标最低配的服务器“均匀”分摊负载,高配的服务器的利用率不足;
2)如果对标最高配的服务器“均匀”分摊负载,低配的服务器可能会扛不住;
能否根据异构服务器的处理能力来动态、自适应进行负载均衡及过载保护,是本文要讨论的问题。
一、service层的负载均衡通常是怎么做的
“一分钟了解负载均衡”中提到,service层的负载均衡,一般是通过service连接池来实现的,调用方连接池会建立与下游服务多个连接,每次请求“随机”获取连接,来保证service访问的均衡性。
“RPC-client实现细节”中提到,负载均衡、故障转移、超时处理等细节也都是通过调用方连接池来实现的。
这个调用方连接池能否实现,根据service的处理能力,动态+自适应的进行负载调度呢?
二、通过“静态权重”标识service的处理能力
调用方通过连接池组件访问下游service,通常采用“随机”的方式返回连接,以保证下游service访问的均衡性。
要打破这个随机性,最容易想到的方法,只要为每个下游service设置一个“权重”,代表service的处理能力,来调整访问到每个service的概率,例如:
假设service-ip1,service-ip2,service-ip3的处理能力相同,可以设置weight1=1,weight2=1,weight3=1,这样三个service连接被获取到的概率分别就是1/3,1/3,1/3,能够保证均衡访问。
假设service-ip1的处理能力是service-ip2,service-ip3的处理能力的2倍,可以设置weight1=2,weight2=1,weight3=1,这样三个service连接被获取到的概率分别就是2/4,1/4,1/4,能够保证处理能力强的service分别到等比的流量,不至于资源浪费。
使用nginx做反向代理与负载均衡,就有类似的机制。
这个方案的优点是:简单,能够快速的实现异构服务器的负载均衡。
缺点也很明显:这个权重是固定的,无法自适应动态调整,而很多时候,服务器的处理能力是很难用一个固定的数值量化。
三、通过“动态权重”标识service的处理能力
提问:通过什么来标识一个service的处理能力呢?
回答:其实一个service能不能处理得过来,能不能响应得过来,应该由调用方说了算。调用服务,快速处理了,处理能力跟得上;调用服务,处理超时了,处理能力很有可能跟不上了。
动态权重设计
1.用一个动态权重来标识每个service的处理能力,默认初始处理能力相同,即分配给每个service的概率相等;
2.每当service成功处理一个请求,认为service处理能力足够,权重动态+1
3.每当service超时处理一个请求,认为service处理能力可能要跟不上了,权重动态-10(权重下降会更快)
4.为了方便权重的处理,可以把权重的范围限定为[0, 100],把权重的初始值设为60分
举例说明:
假设service-ip1,service-ip2,service-ip3的动态权重初始值weight1=weight2=weight3=60,刚开始时,请求分配给这3台service的概率分别是60/180,60/180,60/180,即负载是均衡的。
随着时间的推移,处理能力强的service成功处理的请求越来越多,处理能力弱的service偶尔有超时,随着动态权重的增减,权重可能变化成了weight1=100,weight2=60,weight3=40,那么此时,请求分配给这3台service的概率分别是100/200,60/200,40/200,即处理能力强的service会被分配到更多的流量。
四、过载保护
提问:什么是过载保护?
图示:无过载保护的负载与处理能力图(会掉底)
回答:互联网软件架构设计中所指的过载保护,是指当系统负载超过一个service的处理能力时,如果service不进行自我保护,可能导致对外呈现处理能力为0,且不能自动恢复的现象。而service的过载保护,是指即使系统负载超过一个service的处理能力,service让能保证对外提供有损的稳定服务。
图示:有过载保护的负载与处理能力图(不会掉底)
提问:如何进行过载保护?
回答:最简易的方式,服务端设定一个负载阈值,超过这个阈值的请求压过来,全部抛弃。这个方式不是特别优雅。
五、如何借助“动态权重”来实施过载保护
动态权重是用来标识每个service的处理能力的一个值,它是RPC-client客户端连接池层面的一个东东。服务端处理超时,客户端RPC-client连接池都能够知道,这里只要实施一些策略,就能够对“疑似过载”的服务器进行降压,而不用服务器“抛弃请求”这么粗暴的实施过载保护。
应该实施一些什么样的策略呢,例如:
1.如果某一个service的连接上,连续3个请求都超时,即连续-10分三次,客户端就可以认为,服务器慢慢的要处理不过来了,得给这个service缓一小口气,于是设定策略:接下来的若干时间内,例如1秒(或者接下来的若干个请求),请求不再分配给这个service;
2.如果某一个service的动态权重,降为了0(像连续10个请求超时,中间休息了3次还超时),客户端就可以认为,服务器完全处理不过来了,得给这个service喘一大口气,于是设定策略:接下来的若干时间内,例如1分钟(为什么是1分钟,根据经验,此时service一般在发生fullGC,差不多1分钟能回过神来),请求不再分配给这个service;
3.可以有更复杂的保护策略…
这样的话,不但能借助“动态权重”来实施动态自适应的异构服务器负载均衡,还能在客户端层面更优雅的实施过载保护,在某个下游service快要响应不过来的时候,给其喘息的机会。
需要注意的是:要防止客户端的过载保护引起service的雪崩,如果“整体负载”已经超过了“service集群”的处理能力,怎么转移请求也是处理不过来的,还得通过抛弃请求来实施自我保护。
六、总结
1.service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的
2.异构服务器负载均衡,最简单的方式是静态权重法,缺点是无法自适应动态调整
3.动态权重法,可以动态的根据service的处理能力来分配负载,需要有连接池层面的微小改动
4.过载保护,是在负载过高时,service为了保护自己,保证一定处理能力的一种自救方法
5.动态权重法,还可以用做service的过载保护
本文作者:58沈剑
来源:51CTO
如何实施异构服务器的负载均衡及过载保护?相关推荐
- 异构服务器的负载均衡及过载保护
需求缘起 后端的service有可能部署在硬件条件不同的服务器上: 1)如果对最低配的服务器"均匀"分摊负载,高配的服务器的利用率不足: 2)如果对最高配的服务器"均匀& ...
- 构建负载均衡服务器之一 负载均衡与集群详解
一.什么是负载均衡 首先我们先介绍一下什么是负载均衡: 负载平衡(Load balancing)是一种计算机网络技术,用来在多个计算机(计算机集群).网络连接.CPU.磁盘驱动器或其他资源中分配负载, ...
- pg高性能服务器,Pgpool-II 负载均衡对PG的性能影响
Pgpool-II相当于中间件,Pgpool-II与PG是解耦合的,基于这样的机制,Pgpool-II可以搭建在已经存在的任意版本的PG主从结构上,主从结构的实现与Pgpool-II无关,可以通过sl ...
- windows下使用Nginx服务器实现负载均衡方法
windows下使用Nginx服务器实现负载均衡方法 安装与基本配置 首先下载windows的版本Nginx服务器 下载地址如下: http://www.nginx.org/download/ngin ...
- Varnish——CDN加速的实现(多个后端服务器实现负载均衡、虚拟主机)
实验环境: 主机名 ip 用途 server1 172.25.10.1 ...
- 负载均衡轮询算法和服务器性能,负载均衡算法
对于要实现高性能集群,选择好负载均衡器很重要,同时针对不同的业务场景选择合适的负载均衡算法也是非常重要的. 一.负载均衡算法分类 任务平分类 负载均衡系统将收到的任务平均分配给服务器进行处理,这里的& ...
- 主DNS、辅助DNS、缓存DNS和基于CDN的利用DNS服务器实现负载均衡
实验环境:Centos 6.5 一. 辅助DNS的搭建 Bind dns服务器所需要的包 bind-9.8.2-0.17.rc1.el6_4.6.x86_64.rpm bind-chroot-9.8. ...
- 使用两台服务器做负载均衡(nginx版)
使用两台服务器做负载均衡(nginx版) 一.环境准备 在使用两台服务器做负载均衡前,首先要把环境配置好. 两台服务器上启动的项目都是一样的. 用到的项目包:前端的dist打包文件,后端的jar包: ...
- mqtt服务器性能分析,MQTT服务器动态负载均衡的研究与应用
1. 引言 随着越来越多的工业设备接入物联网,因处理器能力.网络带宽等具有局限性,所以对其通信技术提出了更高的要求 [1].作为网页标准的HTTP,已不能满足机器之间的大规模沟通,其请求/回答模式不再 ...
最新文章
- python selenium对浏览器自动截图
- 从CSRF原理到CMS漏洞利用
- GM6 pageset - Cache get scenario /ui2/cl_pfcg_utils
- 【C++学习之路】第一章——C++核心方法总论
- JavaScript学习笔记(四)——jQuery插件开发与发布
- 我建了这个-现在呢? 如何在DigitalOcean Droplet上部署React App。
- c语言程序设计点亮第一个LED,实验2__C语言程序设计及_LED跑马灯实验.ppt
- Java 泛型(generics)
- 2017.9.5.1.语文
- xcode4的workspace里各lib工程与app工程联编之runscript简介
- 力扣53. 最大子数组和(JavaScript)
- Python基于OpenCV实现视频数据切割为图像数据
- 环境变量配置为jdk8,却显示java版本为jdk7
- 微信商户平台关闭自动提现
- 沙黾农:买股票就买这家上市公司的股票
- PostgreSQL 15.0下载与安装详细保姆教程
- javascript学习网站
- 主引导记录(MBR)的反汇编分析
- HTML 行间距的设置方法与问题
- 新零售赋能最古老产业 看阿里巴巴的农产品上行布局
热门文章
- MacBook Air 使用技巧
- Android 混淆文件project.properties和proguard-project.txt
- POJ 2151 Check the difficulty of problems (概率dp)
- 留言本的漏洞挖掘总结
- DeepEarth中的拖放行为(DragBehavior)
- 原生app跳html页面传值,HTML页面跳转及参数传递问题
- Docker Swarm删除节点
- PowerShell-1.入门及其常用
- 【Linux 内核 内存管理】优化内存屏障 ① ( barrier 优化屏障 | 编译器优化 | CPU 执行优化 | 优化屏障源码 barrier 宏 )
- 【错误记录】Ubuntu 中 ROOT 用户无法启动 Visual Studio Code 开发环境 ( 推荐在普通用户下使用 VSCode 开发环境 )