Nginx+Tomcat+memcached高可用会话保持,看不看你决定！

失职之人

一、概述
之前文章已经形貌了企业高可用负载相干的架构及实现,此中常用的nginx或haproxy,LVS联合keepalived做前端高可用调理器;但之前没有提到会话高可用保持;
本文通过 Tomcat Session Replication Cluster(tomcat自带)和tomcat联合memcat及第三方组件实现Tomcat Memcache Session Server高可用会话缓存服务;
实现的结果:
同一客户端访问业务网站,颠末调理器负载调理到达后端,不管选择的是谁人后端,session ID都稳定,都生存在两台或多台的memcached缓存中(负载冗余);以保持持会话;
架构图:


阐明:客户端哀求时nginx通过负载调理算法将哀求调理至某一后端服务器;tomcat 把会话通过组播的方式复制到集群各节点;全部节点共享会话;


阐明:客户端哀求时nginx通过负载调理算法将哀求调理至某一后端服务器;并把session存储到两台memcached中;客户端革新(不换欣赏器)时,哀求换成另一个后端服务器相应时session ID保持稳定;
测试情况:
nginx: CentOS7 epel 安装nginx WAN:172.16.3.152 LAN:192.168.10.254
tomcat A: CentOS7 node1.san.com epel 安装 tomcat 7 openjdk-1.8.0 memcached(实际情况中单独服务器)
tomcat B: CentOS7 nodde2.san.com epel 安装 tomcat 7 openjdk-1.8.0 memcached 实际情况中单独服务器)
测试客户端ubuntu 16.04

大数据、Python学习资料分享群：596471005，我本身整理的一份最新的得当2018年学习的大数据开辟和零底子入门教程已经上传到群文件。接待初学和进阶中的小同伴。也可以关注我。

办理方案
1)会话sticky(粘性):分为source_ip 基于源ip和cookie
source_ip在差别的调理器上有差别的实现方式:
lvs:sh算法;
nginx:ip_hash或hash $request_uri consistent(同等性哈希算法)
haproxy: source
cookie:
nginx:hash 或 hash $cookie_name consistent;
haproxy:cookie
2)会话集群(session cluster):delta session manager
3)session server: redis(store),memcached(cache)
以下基于tomcat自带会话集群与memcached实现会话保持 功能;


四、Tomcat Memcache Session Server高可用设置
原理阐明:
客户端哀求到达前端nginx调理器并分配到后端某tomcat节点时,tomcat会优先利用本机内存生存session，当一个哀求竣事后，tomcat会通过第三方组件(kryo,javolution,xstream,flexjson)把session序列化并发送到memcached节点上存放作备份，第二次哀求时，假如当地有session就直接返回，第二次哀求竣事，把session修改后的信息更新到后端的memcached服务器，以如许的方式来保持当地的session与memcached上的session同步。当这个tomcat节点宕机时，那么用户的下一次哀求就会被前端的负载平衡器路由到另一个tomcat节点上，而这个节点上并没有这个用户的session信息，这个节点就从memcached服务器上去读取session，并把session生存到当地的内存，当哀求竣事，session又被修改，再送回到memcached举行存放备份
当后端设置了多台memcached时，tomcat在更新session信息时会同时向多个memcached节点更新session，当一个memcached节点故障时，tomcat可以从选择一个正常工作的memcached节点读取session信息来发送给用户的欣赏器，让其重置session信息，如许，memcached也到达了高可用的目标;
以下操纵均在两台node上操纵