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

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

1、负载均衡

集群中的应用服务器（节点）一般被设计成无状态，用户能够请求任何一个节点。

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

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

• 高可用：当某个节点故障时，负载均衡器会将用户请求转发到另外的节点上，从而保证全部服务持续可用；
• 伸缩性：根据系统总体负载状况，能够很容易地添加或移除节点。

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

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）。

参考：

• Comparing Load Balancing Algorithms
• Redirection and Load Balancing

2、集群下的 Session 管理

一个用户的 Session 信息若是存储在一个服务器上，那么当负载均衡器把用户的下一个请求转发到另外一个服务器，因为服务器没有用户的 Session 信息，那么该用户就须要从新进行登陆等操做。

Sticky Session

须要配置负载均衡器，使得一个用户的全部请求都路由到同一个服务器，这样就能够把用户的 Session 存放在该服务器中。

缺点：

• 当服务器宕机时，将丢失该服务器上的全部 Session。

 

 

 

Session Replication

在服务器之间进行 Session 同步操做，每一个服务器都有全部用户的 Session 信息，所以用户能够向任何一个服务器进行请求。

缺点：

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

 

 

 

Session Server

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

优势：

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

缺点：

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

 

 

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