3. 负载均衡技术：流量分发的艺术

各位同学，今天我们来聊聊负载均衡。说实话，这是风控系统高可用设计里最基础也最关键的一环。你想想看，没有负载均衡，你的服务就像只有一个收银台的超市——顾客一多，立马瘫痪。

3.1 负载均衡到底在干什么？

说白了，负载均衡就是「把流量均匀地分给多台机器」。但它的作用远不止「均匀」这么简单。我个人习惯把它的核心价值归纳为三点：

• 提升吞吐量：单机扛不住，那就多机一起扛。我见过一个风控系统，单机QPS只能到2000，加了4台机器做负载均衡后，直接冲到8000+。
• 保证可用性：某台机器挂了？负载均衡自动把它踢出集群，流量不会发过去。用户无感知，这才是高可用的精髓。
• 弹性伸缩：大促期间流量暴涨，加几台机器就行。活动结束，缩回去。负载均衡让这一切变得透明。

3.2 常见算法：选哪个？为什么？

算法这东西，没有绝对的好坏，只有合不合适。我把自己用过的几种算法给大家拆开讲讲。

3.2.1 轮询（Round Robin）

最简单，也最常用。请求按顺序轮流发给每台机器。A -> B -> C -> A -> B -> C ...

优点：实现简单，无状态，适合所有机器配置相同的场景。
缺点：不考虑机器当前负载。如果某台机器处理慢，请求还是会发过去，导致它越来越慢。

3.2.2 最少连接（Least Connections）

动态算法。每次请求来的时候，看看哪台机器当前的连接数最少，就发给谁。

优点：能自动适应后端机器的负载差异。比如某台机器处理慢，它的连接数就会堆积，新请求就不会再发给它。
缺点：需要维护连接数状态，有一定开销。

为什么会这样？因为风控系统里，不同请求的处理时间可能差很多。有的请求查一下缓存就返回了，有的请求要跑复杂的规则引擎。这时候最少连接就比轮询更合理。

3.2.3 IP哈希（IP Hash）

根据客户端IP计算哈希值，然后映射到某台机器。同一个IP的请求，永远发到同一台机器。

优点：实现会话保持。比如用户登录后，后续请求都落在同一台机器上，不需要跨机器共享Session。
缺点：如果某台机器挂了，该IP的请求会重新哈希到其他机器，但会导致部分用户受影响。

3.3 LVS vs Nginx：实战对比

这两个是业界最常用的负载均衡方案。我两个都用过，说说我的感受。

对比维度	LVS	Nginx
工作层级	传输层（4层）	应用层（7层）
性能	极高，可支撑百万级并发	较高，万级到十万级
功能	仅做流量转发	可做反向代理、缓存、SSL卸载等
配置复杂度	较高，需要配置VIP、RS等	较低，配置文件清晰易懂
健康检查	需要额外配置keepalived	内置健康检查
适用场景	大规模、高性能场景	中小规模、需要7层功能的场景

嗯，这里要注意。LVS和Nginx不是互斥的，很多大厂是组合使用的。LVS在最前面扛流量，Nginx在后面做7层路由。

3.3.1 LVS实战配置

LVS有三种工作模式：NAT、DR、TUN。我用的最多的是DR模式，性能最好。

# 在LVS调度器上配置VIP和RS
ipvsadm -A -t 192.168.1.100:80 -s rr  # 轮询算法
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:80 -g  # DR模式
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12:80 -g

配置完记得检查：

ipvsadm -L -n
# 输出示例：
# IP Virtual Server version 1.2.1 (size=4096)
# Prot LocalAddress:Port Scheduler Flags
#   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
# TCP  192.168.1.100:80 rr
#   -> 192.168.1.10:80              Route   1      0          0
#   -> 192.168.1.11:80              Route   1      0          0
#   -> 192.168.1.12:80              Route   1      0          0

3.3.2 Nginx实战配置

Nginx的配置就直观多了。下面是一个典型的upstream配置：

upstream backend {
    least_conn;  # 最少连接算法
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 weight=1;
    server 192.168.1.13:8080 backup;  # 备用服务器
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里我用了least_conn算法，因为风控系统的请求处理时间差异大。weight参数可以调整权重，性能好的机器多分点流量。

3.4 知识体系总览

下面这张图是我自己画的，把负载均衡的核心知识点串起来了。你仔细看看，应该能对整体有个把握。

3.5 总结与避坑

好了，这一章的内容就这些。我最后再啰嗦几句：

• 不要迷信算法：没有最好的算法，只有最适合你场景的算法。先搞清楚你的请求特点，再选。
• 健康检查必须做：负载均衡器如果不知道后端机器挂了，流量还是会发过去。LVS需要配合keepalived，Nginx自带健康检查。
• 监控不能少：我见过一个系统，负载均衡配置没问题，但某台机器内存泄漏，负载均衡还是把流量发过去，导致部分请求超时。所以，后端机器的监控和负载均衡的健康检查要联动。

负载均衡是风控系统高可用的基石。把这一章吃透了，后面的内容你会学得更轻松。

---

公众号:蓝海资料掘金营，微信deep3321