集群

本文目录

集群

一、负载均衡

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

负载均衡器按一定的算法把用户请求转发到集群中合适的节点上。

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

高可用：负载均衡器通过健康检查发现某个节点故障时，会将用户请求转发到另外的节点上，从而保证所有服务持续可用；
伸缩性：根据系统整体负载情况，可以很容易地添加或移除节点。

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

根据负载均衡算法得到转发的节点；
进行转发。

负载均衡算法

轮询、加权轮询、随机和哈希只按事先配置的规则分配，属于静态算法；最少连接和加权最少连接按实时的连接数选择，属于动态算法。

1. 轮询（Round Robin）

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

下图中，6 个请求按 (1, 2, 3, 4, 5, 6) 的顺序到达。(1, 3, 5) 的请求会被发送到服务器 1，(2, 4, 6) 的请求会被发送到服务器 2。

该算法比较适合每个服务器的性能差不多的场景。如果服务器的性能存在差异，性能较差的服务器可能无法承担过大的负载（下图的 Server 2）。

2. 加权轮询（Weighted Round Robin）

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

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

实际实现（例如 Nginx 的平滑加权轮询）会把请求交错发送，避免连续的请求集中到同一台服务器上。它为每台服务器维护一个当前权重：每个请求到来时，各服务器的当前权重先加上自己的权值，选出最大的一台（相等时选前一台），再把它的当前权重减去权值之和 6。上图最后一行按下表算出：

请求   加上权值后 (S1, S2)   选中   减去 6 后 (S1, S2)
1      (5, 1)                S1     (-1, 1)
2      (4, 2)                S1     (-2, 2)
3      (3, 3)                S1     (-3, 3)
4      (2, 4)                S2     (2, -2)
5      (7, -1)               S1     (1, -1)
6      (6, 0)                S1     (0, 0)

6 个请求后当前权重回到 (0, 0)，之后按同样的顺序循环。用 Java 实现如下：

class Server {
    final String host;
    final int weight;
    int current;   // 当前权重，初始为 0
    Server(String host, int weight) { this.host = host; this.weight = weight; }
}

// total 是所有服务器的权值之和
synchronized String getHost(List<Server> servers, int total) {
    Server best = null;
    for (Server s : servers) {
        s.current += s.weight;
        if (best == null || s.current > best.current) best = s;
    }
    best.current -= total;
    return best.host;
}

3. 最少连接（Least Connections）

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

例如下图中，轮询把请求 1、3、5 发给服务器 1，把请求 2、4、6 发给服务器 2。请求 1、3 很快就断开连接，请求 6 到达时服务器 1 只有 1 个连接，服务器 2 还有 2 个，轮询仍然把它发给服务器 2。该系统继续运行时，服务器 2 会承担过大的负载。

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

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

4. 加权最少连接（Weighted Least Connection）

在最少连接的基础上，根据服务器的性能为每台服务器分配权重，将请求发送给“当前连接数 / 权重”最小的服务器。例如服务器 1 的权重为 3、有 6 个连接，服务器 2 的权重为 1、有 3 个连接，6 / 3 = 2 小于 3 / 1 = 3，新请求发给连接更多的服务器 1。

5. 随机算法（Random）

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

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

6. 源地址哈希法（IP Hash）

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

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

缺点是同一出口 IP 后面的大量用户会落到同一台服务器上，造成负载不均；服务器数量变化时大部分客户端的取模结果都会改变，可以改用一致性哈希。需要注意的是，Nginx 的 ip_hash 只用 IPv4 地址的前 3 个字节计算哈希，同一个 /24 网段的客户端都会落到同一台服务器上。

转发实现

1. HTTP 重定向

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

缺点：

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

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

2. DNS 域名解析

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

优点：

DNS 能够根据查询来源的位置进行域名解析，返回离用户较近的服务器 IP 地址。需要注意的是，权威 DNS 看到的是用户所用的递归 DNS 服务器的地址，递归服务器支持 EDNS Client Subnet 时才能看到用户所在的网段。

缺点：

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

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

3. 反向代理服务器

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

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

反向代理工作在应用层，属于七层负载均衡，可以根据 URL、Cookie 等内容进行转发，常用的有 Nginx、HAProxy。

例如 Nginx 用 upstream 定义一组服务器，默认按加权轮询分配，开头写 least_conn、ip_hash 或 hash $request_uri consistent 可以改为加权最少连接、源地址哈希或按 URL 的一致性哈希：

upstream order_service {
    least_conn;                                     # 不写时为加权轮询
    server 10.0.0.11:8080 weight=5;
    server 10.0.0.12:8080 weight=1 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    location /api/ {
        proxy_pass http://order_service;
    }
}

开源版 Nginx 不主动探测后端，只在转发失败时计数：fail_timeout 内失败 max_fails 次（默认 1 次、10 秒），之后的 fail_timeout 内不再向它转发。微服务之间的调用一般不经过 Nginx，由调用方从注册中心取得实例列表后自己选择，见微服务的负载均衡策略。

优点：

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

缺点：

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

4. 网络层

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

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

优点：

在内核中进行处理，性能比较高。

缺点：

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

5. 链路层

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

负载均衡服务器和源服务器配置同一个虚拟 IP（VIP），源服务器把它配置在回环等不响应 ARP 的接口上，从而不需要修改 IP 地址就可以进行转发。也正因为 IP 地址一样，所以源服务器的响应不需要转发回负载均衡服务器，可以直接转发给客户端，避免了负载均衡服务器成为瓶颈。

这是一种三角传输模式，被称为直接路由，对应 LVS 的 DR 模式，要求源服务器和负载均衡服务器位于同一个局域网内，因为只改了 MAC 地址的帧无法经过路由器转发。对于提供下载和视频服务的网站来说，直接路由避免了大量的网络传输数据经过负载均衡服务器。

网络层和链路层的方式不解析应用层协议，属于四层负载均衡：它只看 IP 和端口，同一个 TCP 连接的包都转发给同一台服务器，开销小；七层负载均衡要先和客户端建立 TCP 连接、解析出 HTTP 请求才能选择服务器，开销更大。链路层负载均衡的响应不经过负载均衡服务器，性能很好，在 Linux 平台可以使用的负载均衡服务器为 LVS（Linux Virtual Server），通常用 LVS 做四层负载均衡，再用 Nginx 做七层负载均衡。

二、集群下的 Session 管理

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

Sticky Session

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

缺点：

当服务器宕机时，将丢失该服务器上的所有 Session；
服务器不再是无状态的，不利于伸缩。

Session Replication

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

缺点：

占用过多内存；
同步过程占用网络带宽以及服务器处理器时间，因此只适合规模很小的集群。

Session Server

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

优点：

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

缺点：

需要去实现存取 Session 的代码（Spring Session 等框架已经封装）；
Session Server 本身需要保证高可用。

这是目前最常用的方式。

客户端保存

把用户信息签名后放在 Cookie 或者 JWT 中，由客户端保存，服务端只需要验证签名和有效期。

缺点：

在过期之前无法主动让某个会话失效，需要服务端另外维护黑名单等状态，见 JWT。

参考资料

在阅读器中可以用目录和搜索、切换深色模式、练习这篇笔记中的面试题：打开《集群》