千万级流量架构下的负载均衡解析

本人免费整理了Java高级资料,涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程,一共30G,需要自己领取。
传送门:https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q

  • 一、负载均衡
  • 负载均衡算法
  • 转发实现
  • 二、集群下的 Session 管理
  • Sticky Session
  • Session Replication
  • Session Server

一、负载均衡

集群中的应用服务器(节点)通常被设计成无状态,用户可以请求任何一个节点。

负载均衡器会根据集群中每个节点的负载情况,将用户请求转发到合适的节点上。

负载均衡器可以用来实现高可用以及伸缩性:

  • 高可用:当某个节点故障时,负载均衡器会将用户请求转发到另外的节点上,从而保证所有服务持续可用;
  • 伸缩性:根据系统整体负载情况,可以很容易地添加或移除节点。

负载均衡器运行过程包含两个部分:

  1. 根据负载均衡算法得到转发的节点;
  2. 进行转发。

负载均衡算法

1. 轮询(Round Robin)

轮询算法把每个请求轮流发送到每个服务器上。

下图中,一共有 6 个客户端产生了 6 个请求,这 6 个请求按 (1, 2, 3, 4, 5, 6) 的顺序发送。(1, 3, 5) 的请求会被发送到服务器 1,(2, 4, 6) 的请求会被发送到服务器 2。

该算法比较适合每个服务器的性能差不多的场景,如果有性能存在差异的情况下,那么性能较差的服务器可能无法承担过大的负载(下图的 Server 2)。

2. 加权轮询(Weighted Round Robbin)

加权轮询是在轮询的基础上,根据服务器的性能差异,为服务器赋予一定的权值,性能高的服务器分配更高的权值。

例如下图中,服务器 1 被赋予的权值为 5,服务器 2 被赋予的权值为 1,那么 (1, 2, 3, 4, 5) 请求会被发送到服务器 1,(6) 请求会被发送到服务器 2。

3. 最少连接(least Connections)

由于每个请求的连接时间不一样,使用轮询或者加权轮询算法的话,可能会让一台服务器当前连接数过大,而另一台服务器的连接过小,造成负载不均衡。

例如下图中,(1, 3, 5) 请求会被发送到服务器 1,但是 (1, 3) 很快就断开连接,此时只有 (5) 请求连接服务器 1;(2, 4, 6) 请求被发送到服务器 2,只有 (2) 的连接断开,此时 (6, 4) 请求连接服务器 2。该系统继续运行时,服务器 2 会承担过大的负载。

最少连接算法就是将请求发送给当前最少连接数的服务器上。

例如下图中,服务器 1 当前连接数最小,那么新到来的请求 6 就会被发送到服务器 1 上。

4. 加权最少连接(Weighted Least Connection)

在最少连接的基础上,根据服务器的性能为每台服务器分配权重,再根据权重计算出每台服务器能处理的连接数。

5. 随机算法(Random)

把请求随机发送到服务器上。

和轮询算法类似,该算法比较适合服务器性能差不多的场景。

6. 源地址哈希法 (IP Hash)

源地址哈希通过对客户端 IP 计算哈希值之后,再对服务器数量取模得到目标服务器的序号。

可以保证同一 IP 的客户端的请求会转发到同一台服务器上,用来实现会话粘滞(Sticky Session)

转发实现

1. HTTP 重定向

HTTP 重定向负载均衡服务器使用某种负载均衡算法计算得到服务器的 IP 地址之后,将该地址写入 HTTP 重定向报文中,状态码为 302。客户端收到重定向报文之后,需要重新向服务器发起请求。

缺点:

  • 需要两次请求,因此访问延迟比较高;
  • HTTP 负载均衡器处理能力有限,会限制集群的规模。

该负载均衡转发的缺点比较明显,实际场景中很少使用它。

2. DNS 域名解析

在 DNS 解析域名的同时使用负载均衡算法计算服务器 IP 地址。

优点:

  • DNS 能够根据地理位置进行域名解析,返回离用户最近的服务器 IP 地址。

缺点:

  • 由于 DNS 具有多级结构,每一级的域名记录都可能被缓存,当下线一台服务器需要修改 DNS 记录时,需要过很长一段时间才能生效。

大型网站基本使用了 DNS 做为第一级负载均衡手段,然后在内部使用其它方式做第二级负载均衡。也就是说,域名解析的结果为内部的负载均衡服务器 IP 地址。

3. 反向代理服务器

反向代理服务器位于源服务器前面,用户的请求需要先经过反向代理服务器才能到达源服务器。反向代理可以用来进行缓存、日志记录等,同时也可以用来做为负载均衡服务器。

在这种负载均衡转发方式下,客户端不直接请求源服务器,因此源服务器不需要外部 IP 地址,而反向代理需要配置内部和外部两套 IP 地址。

优点:

  • 与其它功能集成在一起,部署简单。

缺点:

  • 所有请求和响应都需要经过反向代理服务器,它可能会成为性能瓶颈。

4. 网络层

在操作系统内核进程获取网络数据包,根据负载均衡算法计算源服务器的 IP 地址,并修改请求数据包的目的 IP 地址,最后进行转发。

源服务器返回的响应也需要经过负载均衡服务器,通常是让负载均衡服务器同时作为集群的网关服务器来实现。

优点:

  • 在内核进程中进行处理,性能比较高。

缺点:

  • 和反向代理一样,所有的请求和响应都经过负载均衡服务器,会成为性能瓶颈。

5. 链路层

在链路层根据负载均衡算法计算源服务器的 MAC 地址,并修改请求数据包的目的 MAC 地址,并进行转发。

通过配置源服务器的虚拟 IP 地址和负载均衡服务器的 IP 地址一致,从而不需要修改 IP 地址就可以进行转发。也正因为 IP 地址一样,所以源服务器的响应不需要转发回负载均衡服务器,可以直接转发给客户端,避免了负载均衡服务器的成为瓶颈。

这是一种三角传输模式,被称为直接路由。对于提供下载和视频服务的网站来说,直接路由避免了大量的网络传输数据经过负载均衡服务器。

这是目前大型网站使用最广负载均衡转发方式,在 Linux 平台可以使用的负载均衡服务器为 LVS(Linux Virtual Server)。

参考:

二、集群下的 Session 管理

一个用户的 Session 信息如果存储在一个服务器上,那么当负载均衡器把用户的下一个请求转发到另一个服务器,由于服务器没有用户的 Session 信息,那么该用户就需要重新进行登录等操作。

Sticky Session

需要配置负载均衡器,使得一个用户的所有请求都路由到同一个服务器,这样就可以把用户的 Session 存放在该服务器中。

缺点:

  • 当服务器宕机时,将丢失该服务器上的所有 Session。

Session Replication

在服务器之间进行 Session 同步操作,每个服务器都有所有用户的 Session 信息,因此用户可以向任何一个服务器进行请求。

缺点:

  • 占用过多内存;
  • 同步过程占用网络带宽以及服务器处理器时间。

Session Server

使用一个单独的服务器存储 Session 数据,可以使用传统的 MySQL,也使用 Redis 或者 Memcached 这种内存型数据库。

优点:

  • 为了使得大型网站具有伸缩性,集群中的应用服务器通常需要保持无状态,那么应用服务器不能存储用户的会话信息。Session Server 将用户的会话信息单独进行存储,从而保证了应用服务器的无状态。

缺点:

  • 需要去实现存取 Session 的代码。

原文地址:https://www.cnblogs.com/yuxiang1/p/11726920.html

时间: 2024-07-31 01:03:48

千万级流量架构下的负载均衡解析的相关文章

架构设计:负载均衡层设计方案之负载均衡技术总结篇

前言 1.概述 通过前面文章的介绍,并不能覆盖负载均衡层的所有技术,但是可以作为一个引子,告诉各位读者一个学习和使用负载均衡技术的思路.虽然后面我们将转向"业务层"和"业务通信"层的介绍,但是对负载均衡层的介绍也不会停止.在后续的时间我们将穿插进行负载均衡层的新文章的发布,包括Nginx技术的再介绍.HaProxy.LVS新的使用场景等等. 这篇文章我们对前面的知识点进行总结,并有意进行一些扩展,以便于各位读者找到新的学习思路. 2.负载均衡层的核心思想 2-1.一

架构设计:负载均衡层设计方案(8)——负载均衡层总结上篇

1.概述 很明显通过前面的八篇文章的介绍,并不能覆盖负载均衡层的所有技术,但是可以作为一个引子,告诉各位读者一个学习和使用负载均衡技术的思路.虽然后面我们将转向“业务层”和“业务通信”层的介绍,但是对负载均衡层的介绍也不会停止.在后续的时间我们将穿插进行负载均衡层的新文章的发布,包括Nginx技术的再介绍.HaProxy.LVS新的使用场景等等. 这篇文章我们对前面的知识点进行总结,并有意进行一些扩展,以便于各位读者找到新的学习思路. 2.负载均衡层的核心思想 2-1.一致性哈希与Key的选取

架构设计:负载均衡层设计方案(2)——Nginx安装

前一篇文章<架构设计:负载均衡层设计方案(1)--负载场景和解决方式>中我们描述了要搭设负载均衡层的业务场景和负载均衡层搭建和扩展思路.从这篇文章开始的后几篇文章,我们将详细介绍Nginx.LVS和Nginx+Keepalived.LVS+Keepalived和LVS+Nginx+Keepalived的安装细节,以及它们的性能优化方式. Nginx和LVS都是可以独立工作的,Keepalived作为检测机制,不但可以和Nginx.LVS集成也可以和其他软件集成形成高可用方案(例如可以和MySQ

架构设计:负载均衡层设计方案(3)——Nginx进阶

上篇文章<架构设计:负载均衡层设计方案(2)——Nginx安装>(http://blog.csdn.net/yinwenjie/article/details/46620711),我们介绍了Nginx的核心设计思想.基本安装和使用.本来准备继续介绍Nginx的几个使用特性,但是奈何博文篇幅太长,只有将一篇文章拆成两篇.本文我们将承接上文,继续讲解Nginx的实用特性,包括gzip功能.rewirte功能和一个第三方的节点监测模块.本文我们还将提到Taobao团队对Nginx的深度改造Tengi

架构设计:负载均衡层设计方案(1)——负载场景和解决方式

在上一篇<标准Web系统的架构分层>文章中,我们概述了WEB系统架构中的分层架设体系,介绍了包括负载均衡层.业务层.业务通信层.数据存储层的作用和存在意义.从本片文章开始,我们将首先详细讲解负载均衡层的架构原理和选型场景. 1.不同的负载场景 我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”,那么不同的业务场景需要的负载均衡方式又是不一样的,架构师还要考虑架构方案的成本.可扩展性.运维难易度等问题.下面我们先介绍几种典型的不同业务场景,大家也可以先

架构设计:负载均衡层设计方案(4)——LVS原理

之前我们花了两篇文章的篇幅,详细讲解了Nginx的原理.安装和特性组件.请参看<负载均衡层设计方案(2)——Nginx安装>(http://blog.csdn.net/yinwenjie/article/details/46620711)和<架构设计:负载均衡层设计方案(3)——Nginx进阶>(http://blog.csdn.net/yinwenjie/article/details/46742661)两篇文章.虽然不包括Nginx的所有知识(也不可能全部包括),但是足够读者将

19个心得,明明白白说Linux下的负载均衡

一.目前网站架构一般分成负载均衡层.web层和数据库层,我其实一般还会多加一层,即文件服务器层,因为现在随着网站的PV越来越多,文件服务器的压力也越来越大;不过随着moosefs.DRDB+Heartbeat的日趋成熟,这问题也不大了.网站最前端的负载均衡层称之为Director,它起的是分摊请求的作用,最常见的就是轮询. 二.F5是通过硬件的方式来实现负载均衡,它较多应用于CDN系统,用于squid反向加速集群的负载均衡,是专业的硬件负载均衡设备,尤其适用于每秒新建连接数和并发连接数要求高的场

(转)大型网站架构系列:负载均衡详解(2)

三.负载均衡算法 常用的负载均衡算法有,轮询,随机,最少链接,源地址散列,加权等方式: 3.1 轮询 将所有请求,依次分发到每台服务器上,适合服务器硬件同相同的场景. 优点:服务器请求数目相同: 缺点:服务器压力不一样,不适合服务器配置不同的情况: 3.2 随机 请求随机分配到各个服务器.优点:使用简单: 缺点:不适合机器配置不同的场景: 3.3 最少链接 将请求分配到连接数最少的服务器(目前处理请求最少的服务器). 优点:根据服务器当前的请求处理情况,动态分配: 缺点:算法实现相对复杂,需要监

架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

1.概述 前两遍文章中,我们一直在说后文要介绍Nginx + Keepalived的搭建方式.这篇文章开始,我们就来兑现前文的承诺,后续的两篇文章我们将介绍Nginx + Keepalived和 LVS + Keepalived搭建高可用的负载层系统.如果你还不了解Nginx和LVS的相关知识,请参见我之前的两篇文章<架构设计:负载均衡层设计方案(2)--Nginx安装>(http://blog.csdn.net/yinwenjie/article/details/46620711).<