问题客户内网系统部署两个后台节点,前面使用Nginx做负载均衡 。但出现的问题是, 一台服务器承担了几乎所有流量,而另一台服务器基本上没有任何流量 。
分析问题出在Nginx的负载均衡策略上面 。配置的两个节点负载均衡,采用的是ip_hash策略,即基于客户端IP地址来确定访问哪个服务节点的策略 。算法是根据请求所属客户端IP计算得到一个数值,然后把请求发往该数值对应的后端 。所以同一个客户端的请求,都会发往同一个后台服务节点 。除非该节点不可用了 。Ip_hash策略的优点是能够保持会话 。
那么这个策略有什么问题呢?这个问题出在Nginx对Ip_hash的算法上 。这段算法的核心部分如下:
for (i = 0; i < 3; i++) {// iphp->addr[i]为ip的点分十进制法的第i段hash = (hash * 113 + iphp->addr[i]) % 6271; }
通过客户端ip计算得到一个值 。但是问题就出在这段算法上,可以看到,这段算法循环了三次,而正常的IP地址有四个部分,这里只是将IP的前三个部分作为参数加入hash函数 。因此,如果前三部分是一样的话,那么意味着他们都会被分配到同一台服务器上 。
那么为什么Nginx要这样设计呢?因为IP地址前三位相同一般意味着来自同一个局域网或者相领区域,使用相同的后端服务能够让Nginx在一定程度上更具有一致性 。
所以因为客户的内网用户端多在同一个网段,所以最终的结果就是在同一个网段的请求都被Nginx分发到了一个节点上,导致了两个节点的流量不均衡 。
【Nginx的负载均衡没起作用?原来原因在这里】
推荐阅读
- Nginx的HTTPS部署与安全性能优化
- 一文带您了解线性回归:多个变量之间的最佳拟合线的算法
- 一张图片产生五感的AI模型,究竟如何做到的?
- 什么是计算机技术中的特征金字塔
- 从AI发展时间表回顾人工智能的历史
- 你以为的USB充电线 居然是带Wi-Fi的黑客电脑
- linux上SQL Server 配置管理器的使用
- AIGC赋能,颠覆你的社交体验,与世界奇妙连接
- Kubernetes 是我的正确选择吗?
- 解决MySQL数据库字段超长问题的终极指南:一劳永逸的解决方案!