python使用redis实现session_SpringBoot+Redis实现Session数据共享

1.需求

在传统的Web小规模并发的情况下，单个Tomcat容器往往就能胜任请求的负载与处理，如图1所示的方案一。方案一的好处在于，部署简单，维护方便，在Web服务发生变更之后，能够快速升级；除此之外，在用户Session管理方面也十分简单：将所有Session存储至本地服务器即可。但是该方案存在并发规模小、单点故障等原因。

图1 单节点Tomcat示意图

针对方案一存在的负载小、单点故障等因素，方案二进行了大规模的改进。首先，使用NGINX+keepalived取代原来的单节点Tomcat，同时以NGINX作为反向代理服务器，管理多个Tomcat服务节点。如图2所示。

图2 多节点Tomcat部署示意图

从图2可以看出，单节点部署的用户请求负载，从单个Tomcat服务器转移到了Nginx负载(还有其他负载均衡方式)下的多个Tomcat节点，从而实现了单个Web服务的负载均衡与备份。而各个Tomcat节点与NGINX之间，则是采用反向代理的形式进行通信，具体方法有以下五种：

**1、轮询(默认)

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstream backserver {

server 192.168.0.14;

server 192.168.0.15;

} **

**2、指定权重

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

upstream backserver {

server 192.168.0.14 weight=10;

server 192.168.0.15 weight=10;

} **

**3、IP绑定 ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstream backserver {

ip_hash;

server 192.168.0.14:88;

server 192.168.0.15:80;

}

**

**4、fair(第三方)

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream backserver {

server server1;

server server2;

fair;

} **

**5、url_hash(第三方)

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

upstream backserver {

server squid1:3128;

server squid2:3128;

hash $request_uri;

hash_method crc32;

} **

具体NGINX+Keepalived+Tomcat的负载均衡搭建请参考我的另一篇博客。

2.带来的问题