第3章哈希负载均衡

3. 哈希负载均衡：源IP哈希、目的IP哈希、五元组哈希、一致性哈希原理

聊到负载均衡，哈希算法是绕不开的话题。说实话，我在刚入行那会儿，觉得哈希不就是个数学函数嘛，把输入映射成输出就行了。直到我在一个数据中心项目里，亲眼看到因为哈希选得不对，整个集群的流量全压在一台服务器上，那场面，真是惨不忍睹。

哈希负载均衡的核心思想很简单：把数据流的某个特征（比如IP地址）扔进哈希函数，算出一个值，然后用这个值决定把流量转发到哪个后端。听起来容易，但里面的门道可不少。今天我就把几种常见的哈希方式掰开揉碎了讲给你听。

3.1 源IP哈希

源IP哈希，顾名思义，就是只看数据包的源IP地址。哈希函数对源IP进行计算，得到一个哈希值，然后根据这个值选择后端服务器。

它解决了什么问题？

说白了，就是保证会话保持。你想想看，一个用户从同一个IP发起的请求，如果每次都被分配到不同的服务器，那他的登录状态、购物车信息怎么办？源IP哈希能确保同一个源IP的所有请求，都落在同一台后端服务器上。

适用场景：

需要会话保持的Web应用
VPN网关、防火墙等需要跟踪连接状态的设备
简单的客户端-服务器架构

避坑指南：

我曾经在一个教育直播平台遇到过，大量学生通过同一个NAT网关访问，源IP都是同一个公网IP。结果所有流量都打到了一台服务器上，其他服务器闲得发慌。这就是源IP哈希的典型问题——哈希极化。如果客户端都集中在少数几个IP段，负载会严重不均。

3.2 目的IP哈希

目的IP哈希跟源IP哈希正好相反，它看的是数据包的目的IP地址。这个在什么场景下用呢？

我记得有一次帮一个CDN厂商做架构优化，他们需要把来自不同用户的请求，根据请求的目标域名（解析成目的IP）分发到不同的缓存节点。目的IP哈希就派上用场了——它能保证对同一个目标服务器的请求，始终走同一条路径。

核心价值：

在服务器集群中，保证对同一服务的请求一致性
配合ECMP（等价多路径）使用，实现链路负载均衡
在分布式缓存中，确保同一个key的请求落在同一节点

3.3 五元组哈希

五元组哈希就高级一些了。它把源IP、目的IP、源端口、目的端口、协议号这五个要素拼在一起，然后做哈希计算。

为什么要用五个要素？因为光靠IP地址，粒度太粗了。你想想，同一个用户可能同时打开多个浏览器标签页访问同一个网站，每个标签页的源端口都不一样。五元组哈希能精确区分这些不同的连接，让它们可能被分发到不同的后端服务器上。

我的经验：

在做数据中心内部的负载均衡时，我强烈推荐五元组哈希。它的均匀性是最好的。因为端口号是随机的，哈希结果的分布非常均匀。我在一个万兆网络环境中测试过，五元组哈希的负载不均衡度能控制在5%以内，而源IP哈希可能高达30%。

五元组哈希的计算示例：

// 伪代码示例
uint32_t five_tuple_hash(packet) {
    // 将五个字段拼接成一个字符串
    string input = packet.src_ip + packet.dst_ip + 
                   packet.src_port + packet.dst_port + 
                   packet.protocol;
    
    // 使用CRC32或MurmurHash等算法
    uint32_t hash = crc32(input);
    
    // 映射到后端服务器
    return hash % backend_count;
}

3.4 一致性哈希

前面讲的三种哈希，都有一个共同的痛点：当后端服务器数量发生变化时，大部分映射关系都会失效。比如你有10台服务器，突然挂了一台，剩下9台。用普通的哈希取模，90%的请求会被重新映射到不同的服务器上。这在缓存系统中是灾难性的——缓存会大面积失效，所有请求都穿透到数据库。

一致性哈希就是来解决这个问题的。

原理其实不复杂：

把哈希值空间想象成一个环，范围是0到2^32-1
每台服务器根据它的IP或名称，计算哈希值，放在环上的某个位置
每个请求也计算哈希值，然后沿着环顺时针找，遇到的第一个服务器就是目标

当一台服务器宕机时，只有它和它逆时针方向上一台服务器之间的那些请求，会被重新映射到下一台服务器。其他请求不受影响。说白了，影响范围被限制在了一个很小的区间内。

一致性哈希的核心优势：

服务器增减时，只有少量请求需要重新映射
适合缓存系统、分布式数据库等场景
配合虚拟节点技术，可以解决负载不均的问题

虚拟节点是怎么回事？

嗯，这里要注意。如果服务器数量很少，比如只有两三台，一致性哈希的负载可能很不均匀。因为哈希环上的位置是随机的，可能几台服务器挤在一起。解决方案就是给每台服务器创建多个虚拟节点——比如一台物理服务器对应100个虚拟节点，分布在环上。这样负载就能均匀很多。

// 一致性哈希的简化实现
class ConsistentHash {
    // 虚拟节点数量
    int virtual_nodes = 100;
    // 哈希环，key是哈希值，value是服务器
    TreeMap<Integer, Server> ring;
    
    void add_server(Server s) {
        for (int i = 0; i < virtual_nodes; i++) {
            int hash = hash(s.ip + ":" + i);
            ring.put(hash, s);
        }
    }
    
    Server get_server(String key) {
        int hash = hash(key);
        // 找到环上第一个大于等于hash的节点
        Map.Entry<Integer, Server> entry = 
            ring.ceilingEntry(hash);
        if (entry == null) {
            // 如果没找到，取第一个节点（环的特性）
            entry = ring.firstEntry();
        }
        return entry.getValue();
    }
}

我曾经踩过的坑：

有一次做Redis集群扩容，从3个节点扩到6个。我用了一致性哈希，觉得万无一失。结果上线后发现，有大约20%的key访问超时。排查了半天才发现，是哈希函数选得不对——我用的是Java默认的hashCode()，这个函数在不同JVM版本下结果不一致。后来换成了MurmurHash，问题就解决了。所以记住：一致性哈希的哈希函数必须保证跨平台一致性。

3.5 四种哈希方式的对比

哈希方式	输入要素	均匀性	会话保持	增减服务器影响	典型场景
源IP哈希	源IP	差（NAT场景）	好	大	简单会话保持
目的IP哈希	目的IP	一般	一般	大	CDN、服务路由
五元组哈希	五元组	优秀	好	大	数据中心负载均衡
一致性哈希	自定义key	良好（加虚拟节点）	好	小	缓存、分布式存储

3.6 知识体系总览

说了这么多，我画了一张图帮你理清思路。这张图展示了四种哈希方式的核心逻辑和它们之间的关系。

最后说一句，没有万能的哈希方案。你得根据实际场景来选。如果后端服务器数量固定不变，五元组哈希是最稳妥的选择。如果服务器会动态扩缩容，那就得上一致性哈希。记住我当年踩过的坑，选对哈希函数，做好虚拟节点配置，你的负载均衡系统就能稳稳地跑下去。