Nginx+tomcat 配置负载均衡动静分离,再强大一些,多个 Tomcat 之间实现共享 Session。
#user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # for CDN DDNS (static content) upstream dynamic_node { #server dnsserverid:80; # main DNS node server 127.0.0.1:8080; # 因没有DDNS,临时 } # for application server cluster upstream clustering { server 127.0.0.1:8080 srun_id=a; server 127.0.0.1:8180 srun_id=b; jvm_route $cookie_JSESSIONID reverse; } upstream backend { server 127.0.0.1:8080 srun_id=a; server 127.0.0.1:8180 srun_id=b; jvm_route $cookie_JSESSIONID reverse; } server { listen 80; server_name localhost; location ~* \.(gif|jpg|jpeg|png|wmv|avi|mpg|mpeg|mp4|htm|html|js|css|mp3|swf|ico|flv)$ { proxy_set_header X-Real-IP $remote_addr; proxy_pass http://dynamic_node; proxy_store /D/cache/cdn/root$uri; proxy_store_access user:rw group:rw all:r; } location / { index index.shtml; access_log off; proxy_next_upstream http_502 http_504 error timeout invalid_header; proxy_pass http://clustering; 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; } } }
=========================================================================
在构建能够灵活地进行水平扩展、高可用性的Java Web应用程序时候,对http session的处理策略很大程度决定了应用程序的扩展性、可用性。一般而言对http session有如下的处理方案:
1、在服务器端不保存Session,完全无状态
对于不需要保持用户状态的Web应用,采用Stateless是最为恰当的,因此就不存在Session共享的问题。REST(Representational State Transfer)算是最为典型的例子。
2、基于浏览器Cookie的Session共享
此种方案把用户相关的Session信息存储到浏览器的Cookie中,也称为客户端Session。
采用Flash Cookie、URL重写的方式传递Session信息的方案也可以归为此类。
缺点:只能够存储字符串、数值等基本类型的数据;Cookie大小存在限制;安全性;带宽及数据解压缩、网络传输性能问题。
3、基于数据库的Session共享,实现分布式应用间Session共享
此种方案把Session信息存储到数据库表,这样实现不同应用服务器间Session信息的共享。诸如Websphere Portal、Weblogic Portal都采用了类似的方案。
Tomcat Persistent Manager的JDBC Based Store提供了类似实现机制,表结构如下:
create table tomcat_sessions(session_id varchar(100)not null primary key,valid_session char(1)not null,max_inactive int not null,last_access bigint not null,app_name varchar(255),session_data mediumblob,KEY kapp_name(app_name));
优点:实现简单
缺点:由于数据库服务器相对于应用服务器更难扩展且资源更为宝贵,在高并发的Web应用中,最大的性能瓶颈通常在于数据库服务器。因此如果将Session存储到数据库表,频繁的增加、删除、查询操作很容易造成数据库表争用及加锁,最终影响业务。
4、基于应用服务器/Servlet容器的Clustering机制
一些常用的应用服务器及Servlet容器的Clustering机制可以实现Session Replication的功能,例如Tomcat Clustering/Session Replication、Jboss buddy replication。
缺点:基于Clustering的Session复制性能很差,扩展性也很不行。
5、基于NFS的Session共享
通过NFS方式来实现各台服务器间的Session共享,各台服务器只需要mount共享服务器的存储Session的磁盘即可,实现较为简单。但NFS对高并发读写的性能并不高,在硬盘I/O性能和网络带宽上存在较大瓶颈,尤其是对于Session这样的小文件的频繁读写操作。
基于磁盘阵列/SAN/NAS等共享存储的方案道理也类似。
6、基于Terracotta、Ehcache、JBossCache等Java Caching方案实现Session共享
如果系统架构是Java体系,可以考虑采用Terracotta、Ehcache、JbossCache、Oscache等Java Caching方案来实现Session共享。
缺点:架构用于非java体系很不方便;对于是诸如静态页面之类的缓存,采用Memcached的方案比Java更为高效
7、基于Memcached/Tokyo Tyrant等Key-Value DB的Session共享
整体说来此种方案扩展性最好,推荐使用。
原理:Tomcat服务器提供了org.apache.catalina.session.StandardManager和org.apache.catalina.session.PersistentManager用于Session对象的管理,可以自定义PersistentManager的
Store类来实现自己Memcached、Tokyo Tyrant、Redis等Key-Value DB的客户端。
========================================================================
重新编辑,多个 tomcat 共享 session,tomcat 强壮了许多。
方案: Tomcat +memcached + msm
(1)Tomcat 7.0.22 +msm1.5
(2)下载和复制 5 个文件到 tomcat/lib
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" sticky="true" memcachedNodes="n1:localhost:11211 n2:localhost:11212" failoverNodes="n1" requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$" sessionBackupAsync="false" sessionBackupTimeout="100" transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory" customConverter="de.javakaffee.web.msm.serializer.kryo.JodaDateTimeRegistration,de.javakaffee.web.msm.serializer.kryo.WicketSerializerFactory" />
(4)下载 msm 的样本文件,替换掉 lib/msm-kryo-serializer-1.4.1.jar 为 msm-kryo-serializer-1.5.1.jar。
(5)启动两个 tomcat ,成功
(6)注意:如果使用没有 msm 样本文件的webapp 可能会报启动错误。在 conf/Catalina/localhost/msm.xml 下配置独立的应用 context 可以避免该错误。
<?xml version="1.0" encoding="UTF-8"?> <Context path="/msm" docBase="../temp/msm" antiResourceLocking="false" privileged="true" > <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" sticky="true" memcachedNodes="n1:localhost:11211 n2:localhost:11212" failoverNodes="n1" requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico)$" sessionBackupAsync="false" sessionBackupTimeout="100" transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory" customConverter="de.javakaffee.web.msm.serializer.kryo.JodaDateTimeRegistration,de.javakaffee.web.msm.serializer.kryo.WicketSerializerFactory" /> </Context>
(7)移植到其他的 webapp ,需要将 msm 样本程序 lib 中的 jar 包复制到目标 webapp,然后在配置 app context 文件,同上。
参考:
http://code.google.com/p/memcached-session-manager/
http://blog.sina.com.cn/s/blog_4d6c7dea0100uqqd.html
优点:在 tomcat 级自动复制,对应用程序隔离,相当于 tomcat 高效集群
=====================================================================
使用 terracotta +ehcache 复制 tomcat 和 jetty 的 session,实现 tomcat 和 jetty 的集群 。
=====================================================================
Voldemort 实现 jetty session 复制
https://github.com/jaysoo/jetty-session-voldemort