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
再次跑1000轮测试,发现服务还是被分配给Server#2
说明相同来源的ip访问请求均会被分配至同一机器提供服务,IP哈希(IP Hash)的负载均衡方法通常在需要会话保持(Session Affinity)的应用中使用得比较多,其中有状态的连接需要保持到同一台后端服务器。
请注意,IP哈希并不是适用于所有情况的负载均衡方法,因为它可能会导致服务器不均匀负载。在使用IP哈希时,必须考虑服务器的性能和容量,以确保它们可以处理分配给它们的所有连接。此外,如果客户端IP地址在应用程序中经常变化,IP哈希可能不是一个有效的选择。
如果停掉Server#2的机器会怎么样呢
我们停掉Server#2后在在使用代码请求nginx
停掉Server#2后跑2轮请求测试,发现服务都被分配给了Server#5,也就说使用ip Hash策略也会剔除无响应的server,但是这个时候我们将Server#2上线,看一下还会不会上第一次一样所有的服务都被分配给Server#2
上线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
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分布。