NGINX_九 nginx_proxy代理

news2024/10/23 2:40:36

九 nginx_proxy代理

1.代理

1.1 代理原理

  • 反向代理产生的背景:

    在计算机世界里,由于单个服务器的处理客户端(用户)请求能力有一个极限,当用户的接入请求蜂拥而入时,会造成服务器忙不过来的局面,可以使用多个服务器来共同分担成千上万的用户请求,这些服务器提供相同的服务,对于用户来说,根本感觉不到任何差别。

  • 反向代理服务的实现:

    需要有一个负载均衡设备(即反向代理服务器)来分发用户请求,将用户请求分发到空闲的服务器上。

    服务器返回自己的服务到负载均衡设备。

    负载均衡设备将服务器的服务返回用户。

1.2 正/反向代理的区别

那么问题来了,很多人这时会问什么是反向代理?为什么叫反向代理?什么是正向代理?我们来举例说明

  • 正向代理:

    举例:贷款

    正向代理的过程隐藏了真实的请求客户端,服务器不知道真实的客户端是谁,客户端请求的服务都被代理服务器代替请求。我们常说的代理也就是正向代理,正向代理代理的是请求方,也就是客户端;比如我们要访问youtube,可是不能访问,只能先安装个FQ软件代你去访问,通过FQ软件才能访问,FQ软件就叫作正向代理。

1561616889383

FQ软件就是正向代理

1561617051925

正向代理中,proxy和client同属一个LAN

反向代理:

反向代理的过程隐藏了真实的服务器,客户不知道真正提供服务的人是谁,客户端请求的服务都被代理服务器处理。反向代理代理的是响应方,也就是服务端;我们请求www.baidu.com时这www.baidu.com就是反向代理服务器,真实提供服务的服务器有很多台,反向代理服务器会把我们的请求分转发到真实提供服务的各台服务器。Nginx就是性能非常好的反向代理服务器,用来做负载均衡。

访问www.baidu.com是正向代理的过程

1561617154985

反向代理中,proxy和server同属一个LAN

1561617180382

正向代理和反向代理对比示意图

两者的区别在于代理的对象不一样:

正向代理中代理的对象是客户端,proxy和client同属一个LAN,对server透明;

反向代理中代理的对象是服务端,proxy和server同属一个LAN,对client透明。

1561618001304

  1. 

1.3 代理模块

ngx_http_proxy_module

1.4 代理配置

  • 代理

    语法
    syntax:		proxy_pass URL;	 # 代理的后端(真实)服务器URL
    默认值
    default:	-
    在哪配置?
    context:	location, if in location, limit_except
    
  • 缓冲区

    Syntax:		proxy_buffering on | off;
    Default:	proxy_buffering on;			   #缓冲开关
    Context: 	http, server, location
    
    Syntax:		proxy_buffer_size size;
    Default:	proxy_buffer_size 4k|8k;	   #缓冲区大小
    Context:	http, server, location
    
    Syntax:		proxy_buffers number size;
    Default:	proxy_buffers 4k|8k;		   #缓冲区数量
    Context:	http, server, location
    
    Syntax:		proxy_busy_buffers_size size;
    	# 忙碌的缓冲区大小控制同时传递给客户端的buffer数量
    Default:	proxy_busy_buffers_size 8k|16k;
    Context: 	http, server, location
    

    ​ proxy_buffering 开启的情况下,nignx 会把后端返回的内容先放到缓冲区当中,然后再返回给客户端
    (边收边传,不是全部接收完再传给客户端)。

    ​ Nginx 全局配置中的 tcp_nopush 的作用就是数据包会累计到一定大小之后才会发送 。而 tcp_nodelay 是尽快发送数据。

    ​ 所以若你启用了 buffer,建议关闭 tcp_nodelay。

  • 头信息

    Syntax:		  proxy_set_header field value;
    Default:	  proxy_set_header Host $proxy_host;			#设置真实客户端地址			
    			 proxy_set_header Connection close;
    Context: 	  http, server, location
    
  • 超时

    Syntax: 	proxy_connect_timeout time;
    Default: 	proxy_connect_timeout 60s;		#链接超时
    Context: 	http, server, location
    
    Syntax: 	proxy_read_timeout time;
    Default: 	proxy_read_timeout 60s;
    Context: 	http, server, location
    
    			# nginx进程向fastcgi进程发送request的整个过程的超时时间
    Syntax: 	proxy_send_timeout time; 
    Default: 	proxy_send_timeout 60s;
    Context: 	http, server, location
    

    3.1.buffer工作原理

    1. 所有的 proxy buffer 参数是作用到每一个请求的。每一个请求会按照参数的配置获得自己的 buffer 。proxy buffer 不是 global 而是 request 的。

    2. proxy_buffering 是为了开启 response buffering of the proxied server(代理服务),开启后 proxy_buffers 和 proxy_busy_buffers_size 参数才会起作用。

    3. 无论 proxy_buffering 是否开启,proxy_buffer_size(main buffer)都是工作的,proxy_buffer_size 所设置的buffer_size的作用是用来存储 upstream 端 response 的 header。

    4. 在 proxy_buffering 开启的情况下,Nginx 将会尽可能的读取所有的 upstream 端传输的数据到buffer,直到 proxy_buffers 设置的所有 buffer 们 被写满或者数据被读取完(EOF)。此时 nginx 开始向客户端传输数据,会同时传输这一整串 buffer 们。同时如果 response 的内容很大的话,Nginx 会接收并把他们写入到 temp_file 里去。大小由 proxy_max_temp_file_size 控制。如果 busy 的 buffer 传输完了会从 temp_file 里面接着读数据,直到传输完毕。

    5. 一旦 proxy_buffers 设置的 buffer 被写入,直到 buffer 里面的数据被完整的传输完(传输到客户端),这个 buffer 将会一直处在 busy 状态,我们不能对这个 buffer 进行任何别的操作。所有处在 busy 状态的 buffer size 加起来不能超过 proxy_busy_buffers_size ,所以 proxy_busy_buffers_size 是用来控制同时传输到客户端的buffer数量的。

1.5 架构

image-20240618192015016

1.6 实验过程

编辑node1的配置文件:
[root@nginx-2 ~]# vim /etc/nginx/conf.d/default.conf
server {
    server {
    listen       80;
    server_name  localhost;

    location / {
    proxy_pass http://10.0.105.199:80;
    proxy_redirect default;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    #proxy_set_header REMOTE-HOST $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_connect_timeout 30;
    proxy_send_timeout 60;
    proxy_read_timeout 60;

    proxy_buffering on;
    proxy_buffer_size 32k;
    proxy_buffers 4 128k;
    proxy_busy_buffers_size 256k;
    proxy_max_temp_file_size 256k;
    }
}
重新加载nginx配置文件
[root@nginx-server ~]# nginx -s reload

# nginx proxy 具体配置详解
proxy_pass:			真实服务器的地址,可以是ip也可以是域名和url地址
proxy_redirect:		 如果真实服务器使用的是的真实IP:非默认端口。则改成IP:默认端口。
proxy_set_header:	 重新定义或者添加发往后端服务器的请求头
proxy_set_header X-Real-IP: 		启用客户端真实地址(否则日志中显示的是代理在访问网站)
proxy_set_header X-Forwarded-For:	记录代理地址

proxy_connect_timeout:	后端服务器连接的超时时间发起三次握手等候响应超时时间
proxy_send_timeout:		后端服务器数据回传时间就是在规定时间之内后端服务器必须传完所有的数据
proxy_read_timeout:		nginx接收upstream(上游/真实) server数据超时, 默认60s, 如果连续的60s内没有收到1个字节, 连接关闭。像长连接

proxy_buffering on:						开启缓存
proxy_buffer_size:proxy_buffer_size:	只是响应头的缓冲区
proxy_buffers 4 128k:					内容缓冲区域大小
proxy_busy_buffers_size 256k:	从proxy_buffers划出一部分缓冲区来专门向客户端传送数据的地方
proxy_max_temp_file_size 256k:	超大的响应头存储成文件。

准备两台服务器 node1,node2

hostIP备注
客户端192.168.65.65
node1192.168.65.201代理服务器
node2192.168.65.202网站服务器

node1,node2 安装 nginx

vim /etc/yum.repos.d/nginx.repo
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
[root@node1 ~]# yum install -y nginx
<==node1==>
[root@node1 ~]# vim /etc/nginx/conf.d/default.conf
server {
    listen       80;
    server_name  _; #_表示全部
    #access_log  /var/log/nginx/host.access.log  main;
# 当访问http://192.168.65.202的根
    location / {
        proxy_pass http://192.168.65.202; # 转发到后端某一链接上
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}
<==重启node1==>
[root@node1 ~]# nginx -s reload
<==启动node2==>
[root@node2 ~]# nginx
<==客户端==>
[root@lvs ~]# curl http://192.168.65.201

<==查看node1的nginx访问日志==>
[root@node1 ~]# tail -f /var/log/nginx/access.log
192.168.65.65 - - [16/Jun/2024:03:05:05 +0800] "GET / HTTP/1.1" 200 615 "-" "curl/7.76.1" "-"

<==查看node2的nginx访问日志==>
[root@node2 ~]# tail -f /var/log/nginx/access.log
192.168.65.201 - - [16/Jun/2024:03:01:11 +0800] "GET / HTTP/1.0" 200 615 "-" "curl/7.76.1" "-"

可以看到:

​ 客户端访问node1,node1访问node2

​ proxy_pass http://192.168.65.202;配置的效果:

使node2只记录到代理服务器ip。

​ 此时还没有设置头部信息。

那么,接下来为代理服务器配置添加头部信息参数

<==node1==>
[root@node1 ~]# vim /etc/nginx/conf.d/default.conf
server {
    listen       80;
    server_name  _;
    #access_log  /var/log/nginx/host.access.log  main;
# http://192.168.65.202
    location / {
        proxy_pass http://192.168.65.202;
    proxy_redirect default;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    #proxy_set_header REMOTE-HOST $remote_addr;
    #给日志文件最后一字段赋值
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

重启代理,客户端访问代理node1,并查看node1和node2日志

[root@node1 ~]# nginx -s reload

[root@lvs ~]# curl http://192.168.65.201

[root@node1 ~]# tail -f /var/log/nginx/access.log
192.168.65.65 - - [16/Jun/2024:03:18:51 +0800] "GET / HTTP/1.1" 200 615 "-" "curl/7.76.1" "-"

[root@node2 ~]# tail -f /var/log/nginx/access.log
192.168.65.201 - - [16/Jun/2024:03:13:51 +0800] "GET / HTTP/1.0" 200 615 "-" "curl/7.76.1" "192.168.65.65"

# 此时后端服务器就记录到正真访问过自己的ip(客户端ip),这就是头部信息配置参数的效果。

客户端 ==> 代理 ==> 代理 ==> 真实服务器

<==node1==>
# 修改代理配置
server
    proxy_pass http://192.168.65.202;
    proxy_redirect default;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    #给日志文件最后一字段赋值
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
# 重启nginx
# 实时查看nginx访问日志
192.168.65.65 - - [16/Jun/2024:03:41:26 +0800] "GET / HTTP/1.1" 200 615 "-" "curl/7.76.1" "-"
<==node2==>
# 修改代理配置
server
    proxy_pass http://192.168.65.203;
    proxy_redirect default;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    #给日志文件最后一字段赋值
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 重启nginx
# 实时查看nginx访问日志
192.168.65.201 - - [16/Jun/2024:03:36:27 +0800] "GET / HTTP/1.0" 200 615 "-" "curl/7.76.1" "192.168.65.65"
<==node3==>
# 开启ngix
# 实时查看nginx访问日志
192.168.65.202 - - [18/Jun/2024:21:21:29 +0800] "GET / HTTP/1.0" 200 615 "-" "curl/7.76.1" "192.168.65.65, 192.168.65.201"
<==客户端访问node1==>

1.7 知识扩展1

  1. 没有使用LVS时,客户端请求直接到反向代理Nginx,Nginx分发到各个服务器,服务端响应再由Ngnix返回给客户端,这样请求和响应都经过Ngnix的模式使其性能降低,这时用LVS+Nginx解决。

  2. LVS+Nginx,客户端请求先由LVS接收,分发给Nginx,再由Nginx转发给服务器,LVS有三种方式:NAT模式(Network Address Translation)网络地址转换,DR模式(直接路由模式),IP隧道模式,路由方式使服务器响应不经过LVS,由Nginx直接返回给客户端。

    1561618131640

    1561618191407

1.8 知识扩展2

  1. HTTP Server和Application Server的区别和联系

    Apache/nignx是静态服务器(HTTP Server):

    Nginx优点:负载均衡、反向代理、处理静态文件优势。nginx处理静态请求的速度高于apache;

    Apache优点:相对于Tomcat服务器来说处理静态文件是它的优势,速度快。Apache是静态解析,适合静态HTML、图片等。

    HTTP Server 关心的是 HTTP 协议层面的传输和访问控制,所以在 Apache/Nginx 上你可以看到代理、负载均衡等功能

    HTTP Server(Nginx/Apache)常用做静态内容服务和代理服务器,将外来请求转发给后面的应用服务(tomcat,jboss,jetty等)。

    应用服务器(tomcat/jboss/jetty)是动态服务器(Application Server):

    应用服务器Application Server,则是一个应用执行的容器。它首先需要支持开发语言的 Runtime(对于 Tomcat 来说,就是 Java,若是Ruby/Python 等其他语言开发的应用也无法直接运行在 Tomcat 上)。

  2. 但是事无绝对,为了方便,应用服务器(如tomcat)往往也会集成 HTTP Server 的功能,nginx也可以通过模块开发来提供应用功能,只是不如专业的 HTTP Server 那么强大,所以应用服务器往往是运行在 HTTP Server 的背后,执行应用,将动态的内容转化为静态的内容之后,通过 HTTP Server 分发到客户端。

  3. 常用开源集群软件有:lvs,keepalived,haproxy,nginx,git,jenkins,ansible,tomcat,zabbix,rabbitmq,redis,apache,heartbeat

    常用商业集群硬件有:F5, Netscaler,Radware,A10等

2 Nginx负载均衡

2.1 负载均衡的作用

问题:

​ 如果你的nginx服务器给2台web服务器做代理,负载均衡算法采用轮询,那么当你的一台机器web程序关闭造成web不能访问,那么nginx服务器分发请求还是会给这台不能访问的web服务器,如果这里的响应连接时间过长,就会导致客户端的页面一直在等待响应,对用户来说体验就打打折扣,这里我们怎么避免这样的情况发生呢。如下图:

image-20240620102451602

​ 如果负载均衡中其中web2发生这样的情况,nginx首先会去web1请求,但是nginx在配置不当的情况下会继续分发请求道web2,然后等待web2响应,直到我们的响应时间超时,才会把请求重新分发给web1,这里的响应时间如果过长,用户等待的时间就会越长。

解决方案一:

proxy_connect_timeout 1;
proxy_read_timeout 1;
proxy_send_timeout 1;
proxy_ignore_client_abort on;

参数说明:

  • proxy_connect_timeout 1; #nginx服务器与被代理的服务器建立连接的超时时间,默认60秒
  • proxy_read_timeout 1; #nginx服务器向被代理服务器组发出read请求后,等待响应的超时间,默认为60秒。
  • proxy_send_timeout 1; #nginx服务器向被代理服务器组发出write请求后,等待响应的超时间,默认为60秒。
  • proxy_ignore_client_abort on; #客户端断网时,nginx服务器是否中断对被代理服务器的请求。默认为off。

解决方案二:

​ 使用upstream指令配置一组服务器作为被代理服务器,服务器中的访问算法遵循配置的负载均衡规则,同时可以使用该指令配置在下面异常情况发生时,会将请求顺次交由下一组服务器(正常的服务器)处理。

proxy_next_upstream timeout;  #反向代理upstream中设置的服务器组,出现故障时,被代理服务器返回的状态值。error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off

    location / {
        proxy_pass http://web01;
        proxy_next_upstream http_404;
    }

参数说明:

  • error:建立连接或向被代理的服务器发送请求或读取响应信息时服务器发生错误。

  • timeout:建立连接,想被代理服务器发送请求或读取响应信息时服务器发生超时。

  • invalid_header:被代理服务器返回的响应头异常。

  • off:无法将请求分发给被代理的服务器。

  • http_400,…:被代理服务器返回的状态码为400,500,502,等

2.2 upstream配置

upstream testapp(服务器组名字) { 
      # 此处写被代理的一组服务器,有两种写法
      server 10.0.105.199:8081;
      server 10.0.105.202:8081;
      server  http://10.0.105.199:8081;
      server  http://10.0.105.202:8081;
    }
 server {
        listen 80;
        server_name localhost;
        location / {         
           proxy_pass  http://testapp;  #请求转向 testapp 定义的服务器列表         
        } 

2.3 负载均衡算法

a.负载均衡调度算法

upstream 支持4种负载均衡调度算法:

A、轮询(默认):每个请求按时间顺序逐一分配到不同的后端服务器;

B、ip_hash:每个请求按访问IP的hash结果分配,同一个IP客户端固定访问一个后端服务器。可以保证来自同一ip的请求被打到固定的机器上,可以解决session问题。

C、url_hash:按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器。后台服务器为缓存的时候提高效率。

D、fair:这是比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡,也就是根据后端服务器的响应时间来分配请求,响应时间短的优先分配。Nginx本身是不支持 fair的,如果需要使用这种调度算法,必须下载Nginx的 upstream_fair模块。 # 课后扩展

b.配置实例
  • a.热备:backup

    ​ 如果你有2台服务器,当一台服务器发生事故时,才启用第二台服务器给提供服务。服务器处理请求的顺序:AAAAAA突然A挂啦,BBBBBBBBBBBBBB…

    upstream myweb { 
          server 172.17.14.2:8080; 
          server 172.17.14.3:8080 backup;  #热备     
        }
    
  • 轮询:

    ​ nginx默认就是轮询其权重都默认为1,服务器处理请求的顺序:ABABABABAB…

    upstream myweb { 
          server 172.17.14.2:8080;
          server 172.17.14.3:8080;
        }
    
  • 加权轮询:weight=1

    ​ 跟据配置的权重的大小而分发给不同服务器不同数量的请求。如果不设置,则默认为1。下面服务器的请求顺序为:ABBABBABBABBABB…

    upstream myweb { 
          server 172.17.14.2:8080 weight=1;
          server 172.17.14.3:8080 weight=2;
    }
    
  • ip_hash: nginx 会话保持(三种方式,目前只学一种)

    ​ nginx会让相同的客户端ip请求相同的服务器。

    upstream myweb { 
          server 172.17.14.2:8080; 
          server 172.17.14.3:8080;
          ip_hash;
        }
    
  • nginx负载均衡配置状态参数

     upstream myweb { 
          server 172.17.14.2:8080 weight=2 max_fails=2 fail_timeout=2;
          server 172.17.14.3:8080 weight=1 max_fails=2 fail_timeout=1;    
        }
    
    • down,表示当前的server暂时不参与负载均衡。

    • backup,预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候,才会请求backup机器,因此这台机器的压力最轻。

    • max_fails,允许请求失败的次数,默认为1。当超过最大次数时,返回proxy_next_upstream 模块定义的错误。

    • fail_timeout,在经历了max_fails次失败后,暂停服务的时间,单位秒。

      max_fails可以和fail_timeout一起使用。

2.4 四层tcp负载

stream {
			upstream myweb {
			hash $remote_addr consistent;
			server 172.17.14.2:8080;
			server 172.17.14.3:8080;
		}
		server {
            listen 82;
            proxy_connect_timeout 10s;
            proxy_timeout 30s;
            proxy_pass myweb;
        }
}

2.5 七层负载均衡

nginx负载均衡怎么做

hostip备注
客户端192.168.65.65
node1192.168.65.201负载均衡器
node2192.168.65.202后端nginx服务器1
node3192.168.65.203后端nginx服务器2

三台服务器安装nginx ==> 启动node2,node3 nginx ==> 测试nginx页面

[root@node2 ~]# echo "<h1>nginx_1</h1>" > /usr/share/nginx/html/index.html
[root@node3 ~]# echo "<h1>nginx_2</h1>" > /usr/share/nginx/html/index.html
[root@lvs ~]# curl node2
<h1>nginx_1</h1>
[root@lvs ~]# curl node3
<h1>nginx_2</h1>

修改node1负载均衡的nginx配置文件


3 nginx 会话保持

nginx会话保持主要有以下几种实现方式。

3.1 ip_hash

ip_hash使用源地址哈希算法,将同一客户端的请求总是发往同一个后端服务器,除非该服务器不可用。

ip_hash语法:

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
}

ip_hash简单易用,但有如下问题: 当后端服务器宕机后,session会丢失; 来自同一局域网的客户端会被转发到同一个后端服务器,可能导致负载失衡; 不适用于CDN网络,不适用于前段还有代理的情况。

3.2 sticky_cookie_insert

使用sticky_cookie_insert启用会话亲缘关系,这会导致来自同一客户端的请求被传递到一组服务器的同一台服务器。与ip_hash不同之处在于,它不是基于IP来判断客户端的,而是基于cookie来判断。因此可以避免上述ip_hash中来自同一局域网的客户端和前段代理导致负载失衡的情况。(需要引入第三方模块才能实现) # 课后扩展 语法:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    sticky expires=1h domain=3evip.cn path=/;
}

说明: expires:设置浏览器中保持cookie的时间 domain:定义cookie的域 path:为cookie定义路径

3.3 jvm_route方式

jvm_route是通过session_cookie这种方式来实现session粘性。将特定会话附属到特定tomcat上,从而解决session不同步问题,但是无法解决宕机后会话转移问题。如果在cookie和url中并没有session,则这只是个简单的round-robin负载均衡。

jvm_route的原理

  • 一开始请求过来,没有带session的信息,jvm_route就根据round robin的方法,发到一台Tomcat上面
  • Tomcat添加上session信息,并返回给客户
  • 用户再次请求,jvm_route看到session中有后端服务器的名称,他就把请求转到对应的服务器上

暂时jvm_route模块还不支持fair的模式。jvm_route的工作模式和fair是冲突的。对于某个特定用户,当一直为他服务的Tomcat宕机后,默认情况下它会重试max_fails的次数,如果还是失败,就重新启用round robin的方式,而这种情况下就会导致用户的session丢失。

3.4 其他方式

使用后端服务器自身通过相关机制保持session同步,如:使用数据库、redis、memcached 等做session复制。

说明: expires:设置浏览器中保持cookie的时间 domain:定义cookie的域 path:为cookie定义路径

3.3 jvm_route方式

jvm_route是通过session_cookie这种方式来实现session粘性。将特定会话附属到特定tomcat上,从而解决session不同步问题,但是无法解决宕机后会话转移问题。如果在cookie和url中并没有session,则这只是个简单的round-robin负载均衡。

jvm_route的原理

  • 一开始请求过来,没有带session的信息,jvm_route就根据round robin的方法,发到一台Tomcat上面
  • Tomcat添加上session信息,并返回给客户
  • 用户再次请求,jvm_route看到session中有后端服务器的名称,他就把请求转到对应的服务器上

暂时jvm_route模块还不支持fair的模式。jvm_route的工作模式和fair是冲突的。对于某个特定用户,当一直为他服务的Tomcat宕机后,默认情况下它会重试max_fails的次数,如果还是失败,就重新启用round robin的方式,而这种情况下就会导致用户的session丢失。

3.4 其他方式

使用后端服务器自身通过相关机制保持session同步,如:使用数据库、redis、memcached 等做session复制。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/1844492.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

使用Jetpack Compose和DummyJSON加速你的Android开发

使用Jetpack Compose和DummyJSON加速你的Android开发 在现代Android开发中&#xff0c;Jetpack Compose提供了一种全新的UI构建方式&#xff0c;同时DummyJSON简化了开发过程中数据获取的复杂性。本文将详细介绍一个名为firefly-compose的Jetpack Compose模板应用程序&#xf…

电脑一键还原系统,小白也能轻松操作!

电脑一键还原系统是一项非常实用的功能&#xff0c;当电脑遇到无法解决的问题或需要恢复到出厂设置时&#xff0c;用户可以通过一键还原功能快速恢复系统到之前的状态。这项功能不仅可以节省时间&#xff0c;还能有效解决系统问题。本文将介绍三种电脑一键还原系统的方法&#…

【React】Lodash---groupBy() 分组

例子 _.groupBy([6.1, 4.2, 6.3], Math.floor); // > { 4: [4.2], 6: [6.1, 6.3] }// The _.property iteratee shorthand. _.groupBy([one, two, three], length); // > { 3: [one, two], 5: [three] }思路分析 来源 定义一个名为groupBy的方法&#xff0c;通过扩展Ar…

AI界的“视频滤镜”(Stable Diffusion进阶篇-TemporalKit视频风格转化),手把手教你制作原创AI视频

大家好&#xff0c;我是向阳 在之前的文章中我也分享过如何进行AI视频的制作&#xff0c;说是AI视频其实也就是通过Stable Diffusion进行视频重绘&#xff0c;也就是将一个视频一帧一帧重绘为自己想要的画面&#xff0c;然后再连贯起来成为视频。 这个东西其实比较耗费时间和…

智能猫砂盆是养猫必需品吗?三个好用品牌让你实现铲屎自动化!

随着现代社会的快节奏和压力增大&#xff0c;许多人开始因工作、旅行或其他紧急情况需要暂时离家&#xff0c;但这样的话&#xff0c;大家又要如何确保猫咪的猫砂盆在无人照料的情况下依旧保持清洁&#xff1f;尤其在炎热的季节&#xff0c;猫砂盆若长时间未得到清理&#xff0…

英伟达中国特供芯片降价背后:巨头与市场的较量

英伟达&#xff0c;这家曾经在人工智能芯片领域独领风骚的巨头&#xff0c;近期在中国市场遭遇了一些挑战。为了应对来自华为等中国本土企业的竞争&#xff0c;英伟达不得不采取降价策略&#xff0c;调整其专为中国市场打造的H20芯片价格&#xff0c;甚至低于华为的同类产品。这…

数据可视化实验五:seaborn绘制进阶图形

目录 一、绘制动态轨迹图 1.1 代码实现 1.2 绘制结果 二、使用seaborn绘制关系图 2.1 绘制散点图分析产品开发部已离职的员工的评分与平均工作时间 2.1.1 代码实现 2.1.2 绘制结果 ​编辑 2.2 基于波士顿房价数据&#xff0c;绘制房间数和房屋价格的折线图 2.2.1 代码…

人工智能产品经理,行业巨头争夺的稀缺人才

前言 在当今这个由数据驱动的时代&#xff0c;人工智能&#xff08;AI&#xff09;正迅速成为推动各行各业创新的核心力量。随着行业巨头纷纷布局人工智能领域&#xff0c;对于专业人才的需求也日益增长。特别是人工智能产品经理这一岗位&#xff0c;缺口高达6.8万&#xff0c…

mac安装高版本git(更新git)

问题 问题&#xff1a;新下载的idea&#xff0c;此idea的版本较高&#xff0c;但是在工作发现这个版本的git存在一定漏洞会导致一些信息泄露问题。 1.安装Homebrew 对于Mac更新git&#xff0c;最简单的就是使用brew命令。所以我们首先下载homebrew。已下载的同学忽略直接下一…

基于Java的留守儿童爱心网站

你好呀&#xff0c;我是计算机学姐码农小野&#xff01;如果有相关需求&#xff0c;可以私信联系我。 开发语言&#xff1a;Java 数据库&#xff1a;MySQL 技术&#xff1a;B/S结构&#xff0c;SpringBoot框架 工具&#xff1a;MyEclipse&#xff0c;Navicat&#xff0c;To…

《深入理解Spark RDD缓存机制》(第4天)

文章目录 前言一、小试牛刀&#xff1a;解剖RDD缓存机制&#xff1f;1. 什么是Spark RDD缓存策略1.1 为什幺RDD要做缓存1.2 缓存相关API&#xff1a;1.3 缓存案例解析:1.4 图解缓存效果: 2. 什么是checkpoint缓存2.1 为什么要做checkpoint缓存2.2 checkpoint相关API:2.3 checkp…

车载测试面试项目看这一套就够了!车载测试___自我讲解项目

面试官您好&#xff0c;我叫xx来自安微&#xff0c;今年xx岁&#xff0c;毕业于安微新华学院&#xff0c;我是从2017年开始接触软件测试行业&#xff0c;目前从事软件测试工作有5年多时间&#xff0c;第一家公司做了电商和进销存项目app和web都有做过&#xff0c;上家公司做了车…

流程图工具评测:十大热门软件对比

流程图是一种用图形符号和箭头表示工作流程的图形表示方法。它展示了一系列相互关联的步骤&#xff0c;以显示过程中数据或物质的流动、决策点和操作步骤。流程图广泛用于各种领域&#xff0c;包括业务流程、软件开发、工程等&#xff0c;以帮助人们更好地理解和分析工作流程。…

大数据助力电商发展||电商API接口接入

伴随互联网尤其是移动互联网的高速发展&#xff0c;电子商务已经成为人们生活中不可或缺的一部分&#xff0c;人们的购物理念和消费模式正在发生颠覆性的转变。基于天然的数据优势&#xff0c;电子商务平台利用大数据计算技术不断实施数据的累积、分析和处理&#xff0c;消费者…

xshell使用vi命令:bash:vim:command not found

你们好&#xff0c;我是金金金。 场景 此时我通过xshell客户端连接到了远程的虚拟机。想用vi命令编辑一个文件时&#xff0c;显示&#xff1a;bash: vim: command not found 排查 看报错提示就可以知道&#xff0c;没找到vim命令 解决 使用包管理器 apt 来安装 vim 更新你的软…

Faiss:加速大规模数据相似性搜索的利器

在机器学习和数据挖掘领域&#xff0c;相似性搜索是一项基本且重要的任务&#xff0c;它涉及到在大型数据集中找到与特定对象最相似的对象。Faiss是一个由Facebook AI Research开发的库&#xff0c;专门用于高效地进行相似性搜索和聚类&#xff0c;它之所以重要&#xff0c;是因…

视频服务网关的特点

一、视频服务网关的介绍 视频服务网关采用Linux操作系统&#xff0c;可支持国内外不同品牌、不同协议、不同设备类型监控产品的统一接入管理&#xff0c;同时提供标准的H5播放接口供其他应用平台快速对接&#xff0c;让您快速拥有视频集成能力。不受开发环境、跨系统跨平台等条…

Linux系统:线程概念 线程控制

Linux系统&#xff1a;线程概念 & 线程控制 线程概念轻量级进程 LWP页表 线程控制POSIX 线程库 - ptherad线程创建pthread_createpthread_self 线程退出pthread_exitpthread_cancelpthread_joinpthread_detach 线程架构线程与地址空间线程与pthread动态库 线程的优缺点 线程…

【ajax核心01】ajax底层原理

一:XMLHttpRequest对象 节选自MDN网站 XMLHttpRequest&#xff08;XHR&#xff09;对象用于与服务器交互。通过 XMLHttpRequest 可以在不刷新页面的情况下请求特定 URL&#xff0c;获取数据。这允许网页在不影响用户操作的情况下&#xff0c;更新页面的局部内容。XMLHttpReque…

Excel入门必备:掌握单元格引用,轻松应对数据处理

文章目录 概述引用单个单元格&#xff1a;引用单元格范围&#xff1a;相对引用&#xff1a;绝对引用&#xff1a;混合引用&#xff1a; 概述 在 Excel 中&#xff0c;单元格引用是指引用工作表中的单个单元格或单元格范围。单元格引用通常用于在公式中使用单元格的值或进行数据…