标签归档：Upstream

Redisson 缓存 Tomcat Redis Session Manager 变量

1条回复

部署负载均衡时，使用一台Nginx作为前端服务器，多台Tomcat作为后端服务器。Nginx 会根据负载策略把请求分发给Tomcat服务器。默认Tomcat服务器的session(共享会话)是不可跨越服务器的，若是同一个用户的不同请求被分发到不同的Tomcat服务器，就会造成 session 变量丢失，需要用户重新登录。在讲解Redisson之前，我先来分析以下两种方案的Session会话共享。

方案一：Nginx原生 Upstream ip_hash

ip_hash 是根据请求的IP进行分发，对于同一个IP的请求会转发到同一台Tomcat服务器。

1.Nginx 配置如下：《Nginx 1.3 集群负载均衡器 反向代理安装配置优化》

 upstream webservertomcat {
 ip_hash;
 server 10.10.204.63:8023 weight=1 max_fails=2 fail_timeout=2;
 server 10.10.204.64:8023 weight=1 max_fails=2 fail_timeout=2;
 #server 127.0.0.1:8080 backup;
 }
 server {
 listen 80;
 server_name www.myname.com myname.com;
 location / {
 proxy_pass //webservertomcat;
 proxy_redirect off;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 client_max_body_size 10m;
 client_body_buffer_size 128k;
 proxy_connect_timeout 90;
 proxy_send_timeout 90;
 proxy_read_timeout 90;
 proxy_buffer_size 4k;
 proxy_buffers 4 32k;
 proxy_busy_buffers_size 64k;
 proxy_temp_file_write_size 64k;
 add_header Access-Control-Allow-Origin *;
 }
 }

以上配置生产环境不建议使用，原因有二：

1.Nginx可能不是最前端的服务器，如Squid或CDN作为前端缓存，则Nginx实际是拿Squid或CDN服务器的IP地址，达不到根据客户端请求IP分流的效果。
2.有些机构是使用动态虚拟IP或有多个出口IP，用户访问会切换IP，则无法将某个用户的请求固定到同一个Tomcat服务器。

方案二：Nginx_Upstream_jvm_route

Nginx_upstream_jvm_route 是一个第三方 nginx 扩展模块，该模块通过 session cookie 实现 session 会话粘性，如果在cookie和url中并没有session，则这只是个简单的round-robin 负载均衡。

实现方法：用户初次请求分发到后端Server时；会把响应的Server标识添加到名称为JSESSIONID的cookie中，再次请求时；jvm_route看到session中有后端服务器的名称，它就把请求转到对应的服务器上。模块地址：//code.google.com/archive/p/nginx-upstream-jvm-route/

1.Nginx配置如下：

 upstream tomcats_jvm_route {
 server 10.10.204.63:8023 srun_id=tomcat1;
 server 10.10.204.64:8023 srun_id=tomcat2;
 jvm_route $cookie_JSESSIONID|sessionid reverse;
 }

2.在多个Tomcat的server.xml添加配置如下：

 <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
 <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat2">

3.配置后，请求的名称为JSESSIONID的cookie末尾会被添加服务器标识，如下：

 JSESSIONID=33775B80D8E0DB5AEAD61F86D6666C45.tomcat2;

4.生产环境不建议使用，原因：

4.1根据tomcat的特性，当server.xml配置文件中加了jvmRoute值后，会给sessionid加上jvmRoute值的后缀，根据这一特性 nginx_upstream_jvm_route对每次访问请求中的sessionId的值自动匹配对应的server。这样就会每次都访问都会到同一个Tomcat Server，这样就解决了访问不同tomcat节点session发生变化的问题。但是这种方式会出现一个问题，当一直被访问的Tomcat服务器宕机后，负载就会将用户分配到其他Server，这样就会造成session发生变化，从而就需要重新登录。

方案三：Tomcat Redis Session Manager

使用 Redis 共享 session，也就是本节中重点讲解的部分。以上两种方案均是将Session存储在Tomcat容器中，当请求从一个Tomcat转发到另一个Tomcat时，Session就会失效，因为Session在各个Tomcat中不能共享。如果使用Redis等缓存数据库系统存储Session，就可以在Tomcat实例之间实现Session共享。

Java框架redisson实现Tomcat会话管理器（Tomcat Session Manager），支持Apache Tomcat 6.x，7.x和8.x。配置方法如下：

1.编辑 TOMCAT_BASE/conf/context.xml 文件节点，添加以下内容：

<Manager className="org.redisson.tomcat.RedissonSessionManager"<Manager className="org.redisson.tomcat.RedissonSessionManager"  configPath="${catalina.base}/redisson-config.json" />

注：configPath – 是指的Redisson的JSON或YAML格式的配置文件路径。配置文件详见这里。

2.拷贝相应的***两个***JAR包到指定的TOMCAT_BASE/lib目录下：

适用于 JDK 1.8+

redisson-all-3.5.0.jar

for Tomcat 6.x

redisson-tomcat-6-3.5.0.jar

for Tomcat 7.x

redisson-tomcat-7-3.5.0.jar

for Tomcat 8.x

redisson-tomcat-8-3.5.0.jar

3.按照 [Single instance mode]单实例模式的说明，创建编辑 Json 格式的 redisson-config.json 文件，添加以下内容，并将其上传到TOMCAT_BASE下，重载Tomcat服务即可。

{
 "singleServerConfig":{
 "idleConnectionTimeout":10000,
 "pingTimeout":1000,
 "connectTimeout":10000,
 "timeout":3000,
 "retryAttempts":3,
 "retryInterval":1500,
 "reconnectionTimeout":3000,
 "failedAttempts":3,
 "password":null,
 "subscriptionsPerConnection":5,
 "clientName":null,
 "address": "redis://127.0.0.1:6379",
 "subscriptionConnectionMinimumIdleSize":1,
 "subscriptionConnectionPoolSize":50,
 "connectionMinimumIdleSize":10,
 "connectionPoolSize":64,
 "database":0,
 "dnsMonitoring":false,
 "dnsMonitoringInterval":5000
 },
 "threads":0,
 "nettyThreads":0,
 "codec":null,
 "useLinuxNativeEpoll":false
 }

4.开始测试session。创建session.jsp并添加以下代码，上传到TOMCAT_BASE/webapps/ROOT/下。

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>shared session</title>
</head>
<body>
<br>session id=<%=session.getId()%>
</body>
</html>

5.浏览器访问会出现以下会话信息

 session id=1D349A69E8F5A27E1C12DEEFC304F0DC

6.现在查看Redis中是否存储了该值，如果存在会话值，此时你重启Tomcat后，该会话值也不会发生变化。

 # redis-cli
 127.0.0.1:6379> keys *
 1) "redisson_tomcat_session:1D349A69E8F5A27E1C12DEEFC304F0DC"

已经存储成功。

如果是Redis集群或多实例模式，可参阅以下更多资料进行配置：

//github.com/redisson/redisson/wiki/14.-Integration%20with%20frameworks#144-tomcat-redis-session-manager
//github.com/redisson/redisson/wiki/2.-Configuration
//github.com/redisson/redisson/wiki/2.-%E9%85%8D%E7%BD%AE%E6%96%B9%E6%B3%95 （中文文档）

Nginx 1.3 集群负载均衡器 反向代理安装配置优化

发表评论

什么是负载均衡？简言之：负载平衡是指通过一组后端服务器（也称为服务器集群或服务器池）有效地分发传入的网络流量。就像交通信号灯一样，横跨能够履行最大化速度和容量的利用率，确保没有任何一台服务器是超负荷状态，并在所有服务器上路由客户端请求。如果单个服务器关闭或出现故障则可能会降低性能，负载平衡器会将流量重定向到其余的在线服务器。当新的服务器被添加到服务器组时，负载均衡器会自动开始向其发送请求。

环境：
OS:CentOS Linux release 7.3.1611 (Core) x86_64
Web server:nginx version: nginx/1.13.3

10.10.204.62 Load Balancing
10.10.204.63 Nginx Web server
10.10.204.64 Nginx Web server
10.10.204.65 File Storage

1.Nginx Web server安装，我就不在叙述，请参阅《Nginx安装篇》。

2.分别修改4台服务器的主机名，一般都是IP地址，修改完成后重启服务器。

[root@localhost ~]# vim /etc/hostname

3.10.10.204.62 Load Balancing Nginx完整配置文件。注;观察红色部分；

[root@10-10-204-62 ~]# cat /usr/local/nginx/conf/nginx.conf
 user www www;
 worker_processes 1;

 #error_log logs/error.log;
 #error_log logs/error.log notice;
 #error_log logs/error.log info;

pid /usr/local/nginx/logs/nginx.pid;

worker_rlimit_nofile 65535;

events {
 use epoll;
 worker_connections 65535;
 }

http {
 include mime.types;
 default_type application/octet-stream;
 server_tokens off;
 #log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 # '$status $body_bytes_sent "$http_referer" '
 # '"$http_user_agent" "$http_x_forwarded_for"';
 #access_log logs/access.log main;

 sendfile on;
 tcp_nopush on;

 server_names_hash_bucket_size 128;
 client_header_buffer_size 32k;
 large_client_header_buffers 4 32k;
 client_max_body_size 8m;
 tcp_nodelay on;
 keepalive_timeout 65;
 fastcgi_connect_timeout 300;
 fastcgi_send_timeout 300;
 fastcgi_read_timeout 300;
 fastcgi_buffer_size 64k;
 fastcgi_buffers 4 64k;
 fastcgi_busy_buffers_size 128k;
 fastcgi_temp_file_write_size 128k;

 gzip on;
 gzip_min_length 1100;
 gzip_buffers 4 16k;
 gzip_http_version 1.0;
 #gzip压缩的等级，0-9之间，数字越大，压缩率越高，但是cpu消耗也大。
 gzip_comp_level 9;
 gzip_types text/plain text/html text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;
 gzip_vary on;
 #
 upstream webserverapps {
 ip_hash;
 server 10.10.204.63:8023 weight=1 max_fails=2 fail_timeout=2;
 server 10.10.204.64:8023 weight=1 max_fails=2 fail_timeout=2;
 #server 127.0.0.1:8080 backup;
 }
 server {
        listen 80;
        server_name www.myname.com myname.com;
 location / {
     proxy_pass //webserverapps;
     proxy_redirect off;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     client_max_body_size 10m;
     client_body_buffer_size 128k;
     proxy_connect_timeout 90;
     proxy_send_timeout 90;
     proxy_read_timeout 90;
     proxy_buffer_size 4k;
     proxy_buffers 4 32k;
     proxy_busy_buffers_size 64k;
     proxy_temp_file_write_size 64k;
     add_header Access-Control-Allow-Origin *;
       }
    }
 }

4.Nginx Web server 服务器配置：10.10.204.63 & 10.10.204.64。

server {
 listen 8989;
 server_name IP地址;
 location / {
 root /home/web/wwwroot/;
 index index.html index.htm index.php;
 #获取Client端IP需要Nginx支持http_realip_module模块
 set_real_ip_from 10.10.204.0/24;
 real_ip_header X-Real-IP;
     }
 }

5.Nginx做负载均衡需要用到 upstream 是Nginx的HTTP Upstream模块。

Nginx 的负载均衡 upstream 模块目前支持 6 种调度算法，下面进行分别介绍，其中后两项属于第三方调度算法。

轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某台服务器宕机，故障系统被自动剔除，使用户访问不受影响。Weight 指定轮询权重值，Weight 值越大，分配到的访问机率越高。
ip_hash：每个用户请求按访问 IP 的 hash 结果分配，这样来自同一个 IP 的访客固定访问一个后端服务器，有效解决了动态网页存在的 session 共享问题。
fair：比上面两个更智能的负载均衡算法。此算法可以根据&加载时间的长短智能进行负载分配，根据后端服务器响应时长分配请求，响应时间越短就会优先分配。
url_hash：此方法按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率。
least_conn：最少连接负载均衡算法，简单来说就是每次选择的后端都是当前最少连接的一个 server(这个最少连接不是共享的，是每个 worker 都有自己的一个数组进行记录后端 server 的连接数)。
hash：这个 hash 模块又支持两种模式 hash, 一种是普通的 hash, 另一种是一致性 hash(consistent)。

6.在HTTP Upstream模块中，可以通过server指令指定后端服务器的IP地址和端口，同时还可以设定每个后端服务器在负载均衡调度中的状态。常用的健康状态有：

down：表示当前的 server 暂时不参与负载均衡。
backup：预留的备份机器。当其他所有的非 backup 机器出现故障或者忙的时候，才会请求 backup 机器，因此这台机器的压力最轻。
max_fails：允许请求失败的次数，默认为 1 。当超过最大次数时，返回 proxy_next_upstream 模块定义的错误。
fail_timeout：在经历了 max_fails 次失败后，暂停服务的时间。max_fails 可以和 fail_timeout 一起使用。

注:当负载调度算法为 ip_hash 时，后端服务器在负载均衡调度中的状态不能是 backup。

注:stream 是定义在 server{ } 之外，不能定义在 server{ } 内。定义好upstream后，用 proxy_pass 引用即可。此外每一次修改nginx.conf配置文件都需要重新加载Nginx服务。

7.关于 session 共享问题有更多解决方案，请继续参阅《Redis 缓存 PHP 7.2 session 变量共享》。

8.文件服务器

注意：其实大家可能会有个疑问，那么多服务器分布计算，他们需要的文件从哪里来，不仅要保证数据的一致性，还要保证数据的安全性。这个时候就要用到文件存储服务器了，只需要将10.10.204.65文件服务器的数据文件共享给 10.10.204.63 & 10.10.204.64 即可。通常由NFS网络文件系统完成文件共享，我这里已经安装完成。若你还没有安装，请参阅《Nginx 集群负载均衡：NFS文件存储共享安装配置优化篇》。