如何保持会话粘性，看看 Nginx 怎么做的( 二 ) _Nginx

我的测试结果如下：

A服务 -> down 之后, 192.168.1.10 发送过来的请求会分配给 B 。
A服务-> 去掉 down之后，192.168.1.10 发送过来的请求会重新分配 A 来处理。

ip_hash 有哪些坑1. 不适用于负载不均衡的情况：ip_hash主要用于在多个后端服务器之间实现会话粘性，但它不会考虑服务器的负载。如果服务器之间的负载不均衡，某个服务器可能会处理更多的请求，而其他服务器则可能处于空闲状态。这可能导致资源利用不均衡。
2. 有限的负载均衡能力：ip_hash并不是一个全功能的负载均衡解决方案。它仅仅依赖于客户端IP地址，而不考虑服务器的健康状态或性能。如果您需要更复杂的负载均衡策略，可能需要考虑其他Nginx模块，如least_conn或ngx_http_upstream_module ，或者使用专门的负载均衡器。
3. 可能导致资源浪费：如果某个客户端的IP地址在一段时间内请求频率非常高，它的所有请求都将路由到同一个后端服务器。这可能导致某些服务器负载较重，而其他服务器却处于轻负载状态，从而导致资源浪费。
4. 不适用于动态IP分配：如果客户端使用动态IP地址，而且IP地址可能在短时间内变化（例如，通过DHCP），那么ip_hash可能不适用，因为客户端的IP地址可能在会话期间发生变化，导致会话状态丢失。
5. 维护会话状态：使用ip_hash可能需要维护会话状态信息，这会增加一些系统复杂性。如果您需要跨多个服务器进行无状态负载均衡，这可能不是最佳选择。
总结ip_hash 在解决会话粘性的场景中可以发挥出奇效，但是 ip_hash 也会存在一些问题，比如负载不均衡问题。

【如何保持会话粘性，看看 Nginx 怎么做的】