负载均衡：从DNS到动态权重的实战之路
负载均衡这个话题，我聊起来特别有感触。刚入行那会儿，我以为负载均衡就是弄个Nginx转发一下请求。后来在线上被流量冲垮过几次，才真正明白——负载均衡是整个系统可靠性的第一道防线。
今天咱们把这块掰开揉碎了讲。从DNS到硬件，从软件到一致性哈希，再到动态权重调整，每个环节我都会结合自己的踩坑经历来说。
DNS负载均衡：最容易被忽视的入口
DNS负载均衡，说白了就是让不同的用户解析到不同的IP上。你想想看，用户访问你的网站，第一步就是DNS解析。这一步做好了，后面的压力能小很多。
核心原理：通过DNS轮询，把同一个域名解析到多个IP地址。
我记得有个项目，刚开始只用了两台服务器做Web服务。DNS里配了两个A记录，心想这总该够了吧？结果双十一那天，流量直接打满了一台，另一台却闲得很。
为什么会这样？因为DNS缓存。很多运营商的DNS服务器会缓存解析结果，导致大量用户被路由到同一个IP上。
避坑指南：我曾经遇到过DNS解析生效慢的问题。后来发现，TTL值设得太长了。建议生产环境TTL设置在60-300秒之间，既保证缓存效果，又能快速切换。
DNS负载均衡的优点很明显：
- 实现简单，不需要额外设备
- 地理分布友好，可以按区域解析
- 成本低，几乎零维护
缺点也突出：
- 无法感知后端健康状态
- 粒度太粗，只能到IP级别
- DNS缓存导致切换延迟
硬件负载均衡：贵但稳
说到硬件负载均衡，我第一个想到的就是F5。当年在金融公司做架构，机房里两台F5做双活，那价格够买一辆车了。
硬件负载均衡的优势在于性能。它用专用芯片处理网络包，吞吐量能达到几十Gbps。而且功能丰富，SSL卸载、健康检查、会话保持，样样都行。
| 对比项 | 硬件负载均衡 | 软件负载均衡 |
|---|---|---|
| 性能 | 极高（专用芯片） | 中等（依赖CPU） |
| 功能 | 丰富 | 灵活 |
| 成本 | 高（数万到数十万） | 低（开源免费） |
| 扩展性 | 有限 | 极强 |
我个人习惯，在核心交易链路用硬件负载均衡。比如支付网关、订单系统这些，丢一个请求可能就是几十万的损失。但如果是内部系统或者非核心服务，用软件方案就足够了。
小技巧：硬件负载均衡的会话保持功能很实用。我建议开启基于Cookie的会话保持，而不是基于源IP。因为很多用户会切换网络，源IP会变。
软件负载均衡：Nginx与LVS的抉择
软件负载均衡，现在用得最多的就是Nginx和LVS。这两个我都深度用过，说说我的感受。
Nginx：七层负载均衡，能看懂HTTP协议。可以做URL路由、限流、缓存。我习惯用它做反向代理，后面挂一堆应用服务器。
# Nginx负载均衡配置示例
upstream backend {
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=2;
server 192.168.1.12:8080 backup;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}LVS：四层负载均衡，工作在传输层。性能比Nginx高，但功能少。我记得有个视频直播项目，每秒几万个连接，Nginx扛不住，换成LVS就稳了。
怎么选？我的经验是：
- 需要HTTP层面的处理（路由、限流、缓存）→ 用Nginx
- 只需要TCP/UDP转发，追求极致性能 → 用LVS
- 两者结合用：LVS做入口，Nginx做业务分发
一致性哈希：解决缓存雪崩的利器
一致性哈希，这名字听着高大上，其实核心就一句话：让请求尽量落在同一个节点上。
你想想看，如果做缓存分片，用普通的哈希取模。节点一变化，大部分缓存都失效了。这就是缓存雪崩的根源。
一致性哈希怎么解决？它把哈希值空间组织成一个环。每个节点在环上占据一个位置。请求来了，找到环上最近的节点。
关键点：一致性哈希只影响环上相邻节点的数据，其他节点不受影响。节点增减时，只有少量缓存需要重新分布。
我在项目中遇到过一个问题：节点太少时，哈希环分布不均匀。后来加了虚拟节点，每个物理节点对应多个虚拟节点，分布就均匀多了。
# 一致性哈希的虚拟节点实现思路
class ConsistentHash:
def __init__(self, nodes=None, virtual_nodes=150):
self.virtual_nodes = virtual_nodes
self.ring = {}
self.sorted_keys = []
if nodes:
for node in nodes:
self.add_node(node)
def add_node(self, node):
for i in range(self.virtual_nodes):
key = self._hash(f"{node}:{i}")
self.ring[key] = node
self.sorted_keys.append(key)
self.sorted_keys.sort()
def get_node(self, key):
if not self.ring:
return None
hash_key = self._hash(key)
# 二分查找最近的节点
for ring_key in self.sorted_keys:
if ring_key >= hash_key:
return self.ring[ring_key]
return self.ring[self.sorted_keys[0]]注意：虚拟节点数量不是越多越好。我测试过，150个虚拟节点已经能保证很好的均匀性。再多了反而增加计算开销。
动态权重调整：让负载均衡更智能
静态权重配置，说白了就是拍脑袋。你给服务器A配权重3，给B配权重2，但实际A可能性能差、负载高。这时候就需要动态权重调整。
动态权重的核心思路：根据后端服务器的实时状态，动态调整分发权重。
我常用的指标有：
- CPU使用率
- 内存使用率
- 连接数
- 响应时间
举个例子，Nginx配合健康检查模块，可以实现简单的动态调整：
# Nginx动态权重配置思路
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
# 使用第三方模块实现动态权重
# 根据响应时间自动调整权重
least_conn;
}更高级的做法，是用注册中心配合负载均衡器。比如Consul + Nginx，Consul检测到某台服务器负载高了，就通知Nginx降低它的权重。
实战经验：动态权重调整要设置上下限。我曾经遇到过权重降到0的情况，那台服务器直接不接收请求了。后来加了最小权重限制，保证每台服务器至少能接收少量请求，避免流量完全倾斜。
总结一下
负载均衡不是选一个方案就完事了。我建议这样组合：
- 入口层：DNS负载均衡，做地理级别的流量分发
- 接入层：硬件负载均衡或LVS，处理海量连接
- 应用层：Nginx，做业务路由和限流
- 缓存层：一致性哈希，保证缓存命中率
- 动态调整：结合监控数据，实时调整权重
嗯，这套组合拳打下来，系统的可靠性会有质的提升。下次咱们聊聊熔断和限流，那也是我踩过不少坑的领域。