玩转Nginx篇二【IP哈希和URL哈希】
作者:mmseoamin日期:2023-12-20

IP Hash

将来自相同 IP 地址的请求分配给同一台后端服务器,实现会话保持。

配置如下

    upstream polling {
		ip_hash; 
		server 192.168.3.99:8881  weight=1 max_fails=3 fail_timeout=30s;
		server 192.168.3.99:8882  weight=1 max_fails=3 fail_timeout=30s;
		server 192.168.3.99:8883  weight=1 max_fails=3 fail_timeout=30s;
		server 192.168.3.99:8884  weight=1 max_fails=3 fail_timeout=30s;
		server 192.168.3.99:8885  weight=1 max_fails=3 fail_timeout=30s;
	}

启动nginx后使用篇一的代码和服务跑1000轮,发现服务都被分配给Server#2

玩转Nginx篇二【IP哈希和URL哈希】,第1张

再次跑1000轮测试,发现服务还是被分配给Server#2

玩转Nginx篇二【IP哈希和URL哈希】,第2张

说明相同来源的ip访问请求均会被分配至同一机器提供服务,IP哈希(IP Hash)的负载均衡方法通常在需要会话保持(Session Affinity)的应用中使用得比较多,其中有状态的连接需要保持到同一台后端服务器。

请注意,IP哈希并不是适用于所有情况的负载均衡方法,因为它可能会导致服务器不均匀负载。在使用IP哈希时,必须考虑服务器的性能和容量,以确保它们可以处理分配给它们的所有连接。此外,如果客户端IP地址在应用程序中经常变化,IP哈希可能不是一个有效的选择。

如果停掉Server#2的机器会怎么样呢 

我们停掉Server#2后在在使用代码请求nginx

玩转Nginx篇二【IP哈希和URL哈希】,第3张

玩转Nginx篇二【IP哈希和URL哈希】,第4张

玩转Nginx篇二【IP哈希和URL哈希】,第5张

停掉Server#2后跑2轮请求测试,发现服务都被分配给了Server#5,也就说使用ip Hash策略也会剔除无响应的server,但是这个时候我们将Server#2上线,看一下还会不会上第一次一样所有的服务都被分配给Server#2

玩转Nginx篇二【IP哈希和URL哈希】,第6张

上线Server#2后,所有的请求都被分配给了Server#2,和我们第一次的结果一样。

IP Hash分配的原理

IP哈希(IP Hash)的分配原理是将客户端的IP地址作为输入,通过哈希函数计算一个值,然后使用这个值来决定将请求分配给哪台后端服务器。以下是IP哈希的基本分配原理:

  1. 客户端IP地址提取:当一个请求到达负载均衡器(如Nginx),它会提取请求的客户端IP地址。

  2. 哈希计算:使用哈希函数,将客户端IP地址转化为一个固定范围的哈希值。这个哈希值通常是一个整数。

  3. 哈希值映射到后端服务器:将哈希值映射到可用的后端服务器。通常,哈希值与后端服务器的数量相除并取余数,以确定将请求路由到哪台服务器。

    例如,如果有3台后端服务器,哈希值为12,则计算:12 % 3 = 0,那么请求将路由到第一台后端服务器。

  4. 请求路由:根据计算的结果,请求被路由到特定的后端服务器,然后由该服务器来处理请求。

  5. 会话保持:对于会话保持,相同客户端IP地址的后续请求将继续被路由到同一台后端服务器,以保持用户的会话状态。

URL Hash

URL哈希的分配原理是将请求的URL作为输入,通过哈希函数计算一个值,然后使用这个值来决定将请求分配给哪台后端服务器。

配置如下

	upstream polling {
		hash $request_uri;
		server 192.168.3.99:8881  weight=1 max_fails=3 fail_timeout=30s;
		server 192.168.3.99:8882  weight=1 max_fails=3 fail_timeout=30s;
		server 192.168.3.99:8883  weight=1 max_fails=3 fail_timeout=30s;
		server 192.168.3.99:8884  weight=1 max_fails=3 fail_timeout=30s;
		server 192.168.3.99:8885  weight=1 max_fails=3 fail_timeout=30s;
	}

启动nginx后使用篇一的代码和服务跑1000轮,发现服务都被分配给Server#4

玩转Nginx篇二【IP哈希和URL哈希】,第7张

URL Hash分配原理

URL哈希的分配原理是将请求的URL作为输入,通过哈希函数计算一个值,然后使用这个值来决定将请求分配给哪台后端服务器。

  1. 提取URL:当一个请求到达负载均衡器(如Nginx),它会提取请求的URL。

  2. 哈希计算:使用哈希函数,将请求的URL转化为一个固定范围的哈希值。这个哈希值通常是一个整数。

  3. 哈希值映射到后端服务器:将哈希值映射到可用的后端服务器。通常,哈希值与后端服务器的数量相除并取余数,以确定将请求路由到哪台服务器。

    例如,如果有3台后端服务器,哈希值为12,则计算:12 % 3 = 0,那么请求将路由到第一台后端服务器。

  4. 请求路由:根据计算的结果,请求被路由到特定的后端服务器,然后由该服务器来处理请求。

URL哈希的适用场景通常包括以下情况:

  1. 缓存服务器:当使用缓存服务器(如反向代理缓存)时,URL哈希可以用于确保相同URL的请求始终被路由到同一台缓存服务器。这有助于提高缓存的效率,因为相同的资源只需在一台服务器上缓存一次。

  2. 静态资源分发:在Web应用中,通常有大量的静态资源(如图片、CSS和JavaScript文件)。使用URL哈希可以确保这些资源被均匀地分发到不同的后端服务器,以减轻负载。

  3. 内容分发网络(CDN):CDN通常使用URL哈希来确定哪个CDN节点将提供特定的内容。这有助于加速内容的分发,并确保内容尽可能接近终端用户。

  4. 分布式文件系统:在分布式文件系统中,URL哈希可以用于确定哪个节点将存储或提供特定文件。这有助于均衡文件系统的负载。

  5. API网关:在微服务架构中,API网关可以使用URL哈希来确保相同API请求的流量被路由到同一组后端微服务实例,以维护会话一致性。

URL哈希的优点是它可以提高负载均衡的粒度,确保相同URL的请求被路由到同一台服务器。这对于某些应用程序非常有用,但也需要注意,如果URL分布不均匀,会导致负载不均衡。因此,在使用URL哈希时需要仔细考虑应用程序的访问模式和URL分布。