源地址哈希负载均衡是什么
在服务器维护过程中，经常会遇到用户访问不稳定、后端服务压力不均的问题。这时候，负载均衡就派上了用场。而源地址哈希（Source IP Hash）是其中一种常见的调度算法。它的核心逻辑很简单：根据客户端的IP地址做哈希计算，把同一个IP的请求始终指向同一台后端服务器。
比如你家小区门口有三家包子铺，每天早上大家排队买早餐。如果没有规则，今天你去这家，明天换那家，可能造成有的铺子忙不过来，有的却没人光顾。但如果规定“住在1栋的只去A铺，2栋的去B铺”，分配就稳定多了。源地址哈希就像这个分配规则。
为什么选择这种策略
某些业务场景下，保持会话一致性很重要。比如用户登录了某个服务，后续操作需要读取本地缓存或临时文件。如果每次请求被分到不同的服务器，状态对不上，体验就会出问题。使用源地址哈希后，只要用户的IP不变，他所有的请求都会落到同一台机器上，相当于“认准一个服务员办到底”。
这种情况在没有引入外部会话存储（如Redis）的传统架构中尤为常见。运维人员图省事，直接启用源地址哈希，快速解决会话粘滞问题。
配置示例
以Nginx为例，启用源地址哈希非常简单：
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}只需要在upstream块中加上ip_hash;这一行，Nginx就会自动按客户端IP进行哈希分配。注意，它对IPv4和IPv6都支持，但要注意子网掩码的影响，特别是在多层代理环境下。
需要注意的坑
这种策略也不是万能的。比如公司出口只有一个公网IP，所有员工的请求看起来都是同一个源地址。结果就是，负载全压在某一台后端服务器上，其他机器闲着看戏。这时候反而造成了严重的不均衡。
另外，如果某台后端服务器挂了，原本分给它的那些IP请求会被重新分配。虽然Nginx会尝试避开宕机节点，但切换过程可能导致部分用户短暂中断。所以在实际部署中，建议结合健康检查机制一起使用。
还有一种情况，移动网络下的用户IP经常变化。你在地铁上刷网页，信号切换基站，IP一变，就被分到另一台服务器了。这时候会话还是可能丢失，源地址哈希的效果就打了折扣。
适用场景小结
源地址哈希适合客户端IP相对固定、且数量分布较均匀的环境。比如企业内部系统、固定设备接入的服务、或者小型Web应用过渡方案。如果你的应用已经上了云，建议优先考虑更灵活的方案，比如基于Cookie的会话保持或集中式会话管理。
但在某些紧急排错或临时扩容时，加一行ip_hash就能稳住局面，这也是它至今仍被广泛使用的原因之一。