文章目录
一. Nginx 负载均衡策略
1. 轮询(默认策略)
服务器平均的将浏览器请求进行一个个分配, 他会默认的将一个一个请求进行分配, 如下, 按照特定的顺序平均分配服务器资源.
我们修改 两台tomcat的 首页(ROOT/index.jsp), 如下, 刷新后, tomcat1 和 tomcat2 轮流分配.
2. 加权轮询 (默认是 1)
直接在 server配置之后添加 weight 权重: weight=? , ? 越大, 权重越高, 默认是1
3. ip_hash
将ip进行hash处理, 即每个用户在上游服务器都正常运转的情况下(即运作期间没有宕机和新添的上游服务器), 总是会找到一台固定的服务器来处理自己的请求, 以此来提高自己的访问效率.
因为总是自己的请求打在稳定的特定的服务器上, 所以这样就会保证用户的会话 session 就不会跑到其他的服务器中了, 如果该用户的ip动态的发送变化, 就会导致请求会话跑到其他的服务器中了.
注意1: 在使用ip_hash时, 如果一台服务器宕机, 我们在配置中不能直接删除, 而是要标记为down.
注意2: 使用ip_hash可以会有恶意的用户进行大量的高并发访问, 这样就会导致处理该请求的服务器的性能急剧下降, 甚至宕机.
===============================================================
ip_hash算法原理(addr.length=3, 表示处理IPv4的前三个部分值)
ip_hash是根据上游服务器的ip值的ipv4的前三部分进行判断的, 即下面的案例访问到的服务器都是一台.
只有Ipv4地址的前三部分的值不同, 才会进行hasp匹配, 打到不同的服务器上.
源码分析:
直观解释:
使用配置如下:
通过设置的 server_name 的 ip 进行访问
4. url_hash
相比较于 ip_hash, ip_hash是根据用户的ip地址进行的分配, 那么 url_hash就是根据用户请求的url链接进行的分配, 其原理就是根据所请求的控制器不同(不同业务对应的不同url链接)来进行url的hash处理, 从而分配到不同的上游服务器中.
进行配置
简单项目进行测试:
注意: 路径http://www.tomcats.com/nginx-url-hash/hello 与http://www.tomcats.com/nginx-url-hash/hello/ 经过url_hash算法, 会处理到不同的服务器上, 原因是后者多了一个/, 导致了hash值不同.
5. least_conn (根据哪一台服务器的连接数少, 就去优先访问该上游服务器)
进行配置
====================================================================
二. upstream 指令参数
1. max_conns(表示设置最大的连接数)
用于限制一台上游服务器的最大连接数, 默认是 0, 不做任何限制
注意: 如果是使用到了多个 works 进程的时候, 会涉及到 共享内存, 连接总数一定会超过这个 max_conns.
- 配置 beyond.conf
- 配置好 nginx.conf, 将 worker 设置为1 即可
- 使用JMeter 进行测试
测试配置如下:
我的服务器不太行…, 意思到了即可哈, 可以观察观察结果树, 应该正常是 没两次成功请求, 然后失败, 这样往复
2. slow_start (缓慢启动)不适用于hash 和 随机的负载均衡方式
(该参数是在付费商业版使用的, 开源的会报错~~)
slow_start=time, 默认是0, 即表示关闭慢启动
3. down (标记的服务器使之无法访问)
4. backup(标记后, 表示该服务器是一台备用机, 即开始时候不会使用, 只有服务器宕机之后, 才会启用该标记的上游服务器)
对不起, 服务器不够, 土豪可以无视, 继续玩下去
5. max_fails(设置最大的失败次数. 默认为1)
如果该服务器接收到的请求总是失败, 且失败的次数达到了我们设置的最大失败次数, 那么这台服务器就会被标记为宕机状态, 其他后续的请求就不会再访问这台上游服务器了.
6. fail_timeout(设置失败的时间时长. 默认为 10秒)
在我们设置了max_fails=2 后, 若设置 fail_timeout=15s , 则表示请求到达该上游服务器的失败次数最大为二, 当失败请求达到2的时候, 服务器并不会宕机, 而是会再等待15秒(我们设置的fail_timeout), 在这15秒内不会有请求到达该服务器, 而是去找正常的服务器. 当这15秒过后, 会有新的请求继续尝试访问该服务器, 如果失败, 继续找正常运作的服务器…就这样循环, 直到该服务器被修复.
使用JMeter 进行测试
