轮询:将请求依次发给服务器
随机:将请求随机发给服务器
通用,无状态的负载均衡
按照预先配置的权重,将请求按照权重比例发送给不同的服务器
服务器的处理能力有差异,例如新老服务器搭配使用
2020年采购的机器CPU核数是2019年采购的机器的1倍,运维直接配置了2倍权重,结果导致新机器全部过载
例如:给服务器1发送40个请求,然后再给服务器2发送40个请求,然后再给服务器3发送20个请求
实现简单,但服务器资源利用可能不均衡,会出现毛刺现象,例如配置了[200,50, 20],但如果配置[2, 2, 1]的话,这种算法运行良好
将所有服务器的权重加起来,然后计算各个服务器的分配概率,用随机数区间来做分配
例如:服务器[0~39],服务器2[40~79],服务器3[80~99],生成0~99的随机数,落入哪个区间就用那个服务器
Nginx 的实现,兼顾服务器故障后的慢启动
负载均衡系统将任务分配给当前负载最低的服务器,这里的负载根据不同的任务类型和业务场景,可以用不同的指标来衡量
负载均衡系统将任务分配给当前性能最好的服务器,主要是以响应时间作为性能衡量标准
Nginx 这种7层网络负载系统,可以以“HTTP 响应时间” 来判断服务器状态(Nginx 内置的负载均衡算法不支持这种方式,需要进行扩展)
基于某个参数计算Hash值,将其映射到具体的服务器
通用负载均衡算法是基于请求的,业务级别的负载均衡是基于业务内容的,更灵活
例如蚂蚁的 LDC 架构,腾讯的 SET 单元化架构
箭头1:对于应该在本 IDC 处理的请求,直接映射到对应的 RZ 即可;
箭头2:不在本 IDC 处理的请求,Spanner 可以转发至其他 IDC 的Spanner。
对于有些场景,A 用户的一个请求可能关联了对 B 用户数据的访问,比如 A转账给 B,A 扣完钱后要调用账务系统去增加 B 的余额。这时候就涉及到:
箭头3:跳转到其他 IDC 的 RZone;
箭头4:跳转到本 IDC 的其他 RZone。
RZ 访问哪个数据库,是可以配置的,对应图中箭头5
一般用于session保持、购物车、下单等场景
可以通过X-来自定义HTTP header,可以服务器下发,也可以直接带上本地信息。这种用法被IETF在2012年6月发布的RFC5548中明确不推荐,虽然RFC已经不推荐使用带X前缀的http头部,但是不推荐不代表禁止,目前应用广泛
一般用于精细化的地址位置、机房级别、版本、平台、渠道等负载均衡,例如:
query string包含负载均衡信息
线上单个服务器(32核)性能大约是300~1000 TPS/QPS
服务器数量=(总TPS+QPS)/单个服务器性能