玩转Nginx篇二【IP哈希和URL哈希】-Toy模板网

这篇具有很好参考价值的文章主要介绍了玩转Nginx篇二【IP哈希和URL哈希】。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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_hash,Nginx专栏,nginx

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

nginx ip_hash,Nginx专栏,nginx

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

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

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

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

nginx ip_hash,Nginx专栏,nginx

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

nginx ip_hash,Nginx专栏,nginx

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

IP Hash分配的原理

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

客户端IP地址提取：当一个请求到达负载均衡器（如Nginx），它会提取请求的客户端IP地址。
哈希计算：使用哈希函数，将客户端IP地址转化为一个固定范围的哈希值。这个哈希值通常是一个整数。
哈希值映射到后端服务器：将哈希值映射到可用的后端服务器。通常，哈希值与后端服务器的数量相除并取余数，以确定将请求路由到哪台服务器。

例如，如果有3台后端服务器，哈希值为12，则计算：12 % 3 = 0，那么请求将路由到第一台后端服务器。
请求路由：根据计算的结果，请求被路由到特定的后端服务器，然后由该服务器来处理请求。
会话保持：对于会话保持，相同客户端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_hash,Nginx专栏,nginx

URL Hash分配原理

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

提取URL：当一个请求到达负载均衡器（如Nginx），它会提取请求的URL。
哈希计算：使用哈希函数，将请求的URL转化为一个固定范围的哈希值。这个哈希值通常是一个整数。
哈希值映射到后端服务器：将哈希值映射到可用的后端服务器。通常，哈希值与后端服务器的数量相除并取余数，以确定将请求路由到哪台服务器。

例如，如果有3台后端服务器，哈希值为12，则计算：12 % 3 = 0，那么请求将路由到第一台后端服务器。
请求路由：根据计算的结果，请求被路由到特定的后端服务器，然后由该服务器来处理请求。

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

缓存服务器：当使用缓存服务器（如反向代理缓存）时，URL哈希可以用于确保相同URL的请求始终被路由到同一台缓存服务器。这有助于提高缓存的效率，因为相同的资源只需在一台服务器上缓存一次。
静态资源分发：在Web应用中，通常有大量的静态资源（如图片、CSS和JavaScript文件）。使用URL哈希可以确保这些资源被均匀地分发到不同的后端服务器，以减轻负载。
内容分发网络（CDN）：CDN通常使用URL哈希来确定哪个CDN节点将提供特定的内容。这有助于加速内容的分发，并确保内容尽可能接近终端用户。
分布式文件系统：在分布式文件系统中，URL哈希可以用于确定哪个节点将存储或提供特定文件。这有助于均衡文件系统的负载。
API网关：在微服务架构中，API网关可以使用URL哈希来确保相同API请求的流量被路由到同一组后端微服务实例，以维护会话一致性。

URL哈希的优点是它可以提高负载均衡的粒度，确保相同URL的请求被路由到同一台服务器。这对于某些应用程序非常有用，但也需要注意，如果URL分布不均匀，会导致负载不均衡。因此，在使用URL哈希时需要仔细考虑应用程序的访问模式和URL分布。文章来源地址https://www.toymoban.com/news/detail-762962.html

到了这里，关于玩转Nginx篇二【IP哈希和URL哈希】的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！