1、负载均衡
动态服务器的问题,往往就是并发能力太弱,往往需要多台动态服务器一起提供服务。如何把并发的压力分摊,这就需要调度,采用一定的调度策略,将请求分发给不同的服务器,这就是Load Balance负载均衡。
当单机的Tomcat,演化出多机多级部署的时候,一个问题便凸显出来,这就是Session。而这个问题的由来,都是由于HTTP协议在设计之初没有想到未来的发展。
2、HTTP的无状态,有连接和短连接
-
无状态:指的是服务器端无法知道2次请求之间的联系,即使是前后2次请求来自同一个浏览器,也没有任何数据能够判断出是同一个浏览器的请求。后来可以通过cookie、session机制来判断。
-
浏览器端第一次HTTP请求服务器端时,在服务器端使用session这种技术,就可以在服务器端产生一个随机值即SessionID发给浏览器端,浏览器端收到后会保持这个SessionID在Cookie当中,这个Cookie值一般不能持久存储,浏览器关闭就消失。浏览器在每一次提交HTTP请求的时候会把这个SessionID传给服务器端,服务器端就可以通过比对知道是谁了
-
Session通常会保存在服务器端内存中,如果没有持久化,则易丢失
-
Session会定时过期。过期后浏览器如果再访问,服务端发现没有此ID,将给浏览器端重新发新的SessionID
-
更换浏览器也将重新获得新的SessionID
-
-
有连接:是因为HTTP1.x基于TCP协议,是面向连接的,需要3次握手、4次断开。
-
短连接:Http 1.1之前,都是一个请求一个连接,而Tcp的连接创建销毁成本高,对服务器有很大的影响。所以,自Http 1.1开始,支持keep-alive,默认也开启,一个连接打开后,会保持一段时间(可设置),浏览器再访问该服务器就使用这个Tcp连接,减轻了服务器压力,提高了效率。
服务器端如果故障,即使Session被持久化了,但是服务没有恢复前都不能使用这些SessionID。
如果使用HAProxy或者Nginx等做负载均衡器,调度到了不同的Tomcat上,那么也会出现找不到SessionID的情况。
3、会话保持方式
3.1 session sticky会话黏性
Session绑定
- nginx:source ip
- HAProxy:cookie
优点:简单易配置
缺点:如果目标服务器故障后,如果没有做sessoin持久化,就会丢失session
3.2 session复制集群
Tomcat自己的提供的多播集群,通过多播将任何一台的session同步到其它节点。
缺点
- Tomcat的同步节点不宜过多,互相即时通信同步session需要太多带宽
- 每一台都拥有全部session,内存占用太多
3.3 session server
session 共享服务器,使用memcached、redis做共享的Session服务器。
4、验证测试
4.1 规划
IP | 主机名 | 服务 | |
---|---|---|---|
10.10.100.101 | node1 | 调度器 | Nginx、HTTPD |
10.10.100.102 | node2 | tomcat1 | JDK8、Tomcat8 |
10.10.100.103 | node3 | tomcat2 | JDK8、Tomcat8 |
4.2 配置
每台主机添加域名解析
vim /etc/hosts
10.10.100.101 node1.cwy.com node1
10.10.100.102 node2.cwy.com node2
10.10.100.103 node3.cwy.com node3
node2及node3配置
#环境变量配置
vim /etc/profile.d/tomcat.sh
export CATALINA_HOME=/usr/local/tomcat
export PATH=$CATALINA_HOME/bin:$PATH
#项目路径配置
mkdir -pv /data/webapps/ROOT
#编写测试jsp文件
<%@ page import="java.util.*" %>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>lbjsptest</title>
</head>
<body>
<div>On <%=request.getServerName() %></div>
<div><%=request.getLocalAddr() + ":" + request.getLocalPort() %></div>
<div>SessionID = <span style="color:blue"><%=session.getId() %></span></div>
<%=new Date()%>
</body>
</html>
node2虚拟主机配置
<Engine name="Catalina" defaultHost="node2.cwy.com">
<Host name="node2.cwy.com" appBase="/data/webapps" unpackWARs="true" autoDeploy="true" />
</Engine>
node3虚拟主机配置
<Engine name="Catalina" defaultHost="node3.cwy.com">
<Host name="node3.cwy.com" appBase="/data/webapps" unpackWARs="true" autoDeploy="true" />
</Engine>
4.3 nginx调度
#node1 nginx配置
upstream tomcats {
server node2.cwy.com:8080;
server node3.cwy.com:8080;
}
server {
location ~* \.(jsp|do)$ {
proxy_pass http://tomcats;
}
}
测试http://node1.cwy.com/index.jsp 可以看到是轮询调度效果。
使用ip_hash开启黏性
upstream tomcats {
#使用ip_hash开启黏性
ip_hash;
server node2.cwy.com:8080;
server node3.cwy.com:8080;
}
在upstream中使用ip_hash指令,使用客户端IP地址Hash。这个hash值使用IP v4地址的前24位或全部的IPv6地址。
配置完reload nginx服务。测试可以看到同一ip访问始终调度到同一台服务器。
4.4 Httpd调度
使用httpd -M可以看到proxy_balancer_module,用它来实现负载均衡。
方式 | 依赖模块 |
---|---|
http负载均衡 | mod_proxy mod_proxy_http mod_proxy_balancer |
ajp负载均衡 | mod_proxy mod_proxy_ajp mod_proxy_balancer |
#关闭httpd默认主机
[root@node1 conf.d]# vim /etc/httpd/conf/httpd.conf
注释掉 #DocumentRoot "/var/www/html"
[root@node1 conf.d]# cd /etc/httpd/conf.d
[root@node1 conf.d]# vim vhosts.conf
[root@node1 conf.d]# httpd -t
[root@node1 conf.d]# systemctl start httpd
httpd负载均衡配置说明
配置代理到balancer
ProxyPass [path] !|url [key=value [key=value …]]
Balancer成员
BalancerMember [balancerurl] url [key=value [key=value…]]
设置Balancer或参数
ProxySet url key=value [key=value …]
ProxyPass和BalancerMember指令参数
参数 | 缺省值 | 说明 |
---|---|---|
min | 0 | 连接池最小容量 |
max | 1 - n | 连接池最大容量 |
retry | 60 | apache请求发送到后端服务器错误后等待的时间秒数。0表示立即重试 |
Balancer参数
参数 | 缺省值 | 说明 |
---|---|---|
loadfactor | 定义负载均衡后端服务器权重,取值范围1 - 100 | |
lbmethod | byrequests | 负载均衡调度方法。 byrequests 基于权重的统计请求个数进行调度; bytrafficz 执行基于权重的流量计数调度; bybusyness 通过考量每个后端服务器当前负载进行调度 |
maxattempts | 1 | 放弃请求前实现故障转移的次数,默认为1,其最大值不应该大于总的节点数 |
nofailover | Off | 如果后端服务器没有Session副本,可以设置为On不允许故障转移。 Off故障可以转移 |
stickysession | 调度器的sticky session名字,根据web后台编程语言不同,可以设置为JSESSIONID或PHPSESSIONID |
ProxySet指令也可以使用上面的参数。
在tomcat的配置中Engine使用jvmRoute属性
#node2的tomcat配置中添加
<Engine name="Catalina" defaultHost="node2.cwy.com" jvmRoute="Tomcat1">
#node3的tomcat配置中添加
<Engine name="Catalina" defaultHost="node3.cwy.com" jvmRoute="Tomcat2">
这样SessionID,就变成了这样SessionID = 9C949FA4AFCBE9337F5F0669548BD4DF.Tomcat2
httpd配置
[root@node1 conf.d]# vim vhost.conf
<VirtualHost *:80>
ProxyRequests Off
ProxyVia On
ProxyPreserveHost On
ProxyPass / balancer://lbtomcats/
ProxyPassReverse / balancer://lbtomcats/
</VirtualHost>
<Proxy balancer://lbtomcats>
BalancerMember http://node2.cwy.com:8080 loadfactor=1
BalancerMember http://node3.cwy.com:8080 loadfactor=2
</Proxy>
#loadfactor设置为1:2,便于观察。观察调度的结果是轮询的。
使用session黏性
[root@node1 ~]# vim /etc/httpd/conf.d/vhost.conf
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<VirtualHost *:80>
ProxyRequests Off
ProxyVia On
ProxyPreserveHost On
ProxyPass / balancer://lbtomcats/
ProxyPassReverse / balancer://lbtomcats/
</VirtualHost>
<Proxy balancer://lbtomcats>
BalancerMember http://node2.cwy.com:8080 loadfactor=1 route=Tomcat1
BalancerMember http://node3.cwy.com:8080 loadfactor=2 route=Tomcat2
ProxySet stickysession=ROUTEID
</Proxy>
~
测试发现Session不变了,一直找的同一个Tomcat服务器。
ajp调度
[root@node1 ~]# vim /etc/httpd/conf.d/vhost.conf
<VirtualHost *:80>
ProxyRequests Off
ProxyVia On
ProxyPreserveHost On
ProxyPass / balancer://lbtomcats/
ProxyPassReverse / balancer://lbtomcats/
</VirtualHost>
<Proxy balancer://lbtomcats>
BalancerMember ajp://node2.cwy.com:8080 loadfactor=1 route=Tomcat1
BalancerMember ajp://node3.cwy.com:8080 loadfactor=2 route=Tomcat2
# ProxySet stickysession=ROUTEID
</Proxy>
ProxySet stickysession=ROUTEID先禁用看看切换效果,开启后看看黏住效果。
开启后,发现Session不变了,一直找的同一个Tomcat服务器。
虽然,上面的做法实现客户端在一段时间内找同一台Tomcat,从而避免切换后导致的Session丢失。但是如果Tomcat节点挂掉,那么Session依旧丢失。
假设有A、B两个节点,都把Session做了持久化。如果Tomcat A服务下线期间用户切换到了Tomcat B上,就获得了Tomcat B的Session,就算持久化Session的Tomcat A上线了,也没用了。
4.5 Tomcat Session集群
4.5.1 配置说明
参考:https://tomcat.apache.org/tomcat-8.5-doc/cluster-howto.html
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="230.100.100.8"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
配置说明
-
Cluster 集群配置
-
Manager 会话管理器配置
-
Channel 信道配置
- Membership 成员判定。使用什么多播地址、端口多少、间隔时长ms、超时时长ms。同一个多播地址和端口认为同属一个组。使用时修改这个多播地址,以防冲突
- Receiver 接收器,多线程接收多个其他节点的心跳、会话信息。默认会从4000到4100依次尝试可用端口(注:address=“auto”,auto可能绑定到127.0.0.1上,所以一定要改为可以用的IP上去)。
- Sender 多线程发送器,内部使用了tcp连接池。
- Interceptor 拦截器
-
Valve
- ReplicationValve 检测哪些请求需要检测Session,Session数据是否有了变化,需要启动复制过程
-
ClusterListener
- ClusterSessionListener 集群session侦听器
使用<Cluster className=“org.apache.catalina.ha.tcp.SimpleTcpCluster”/>
添加到所有虚拟主机都可以启用Session复制
添加到,该虚拟主机可以启用Session复制
最后,在应用程序内部启用了才可以使用
前提:
- 时间同步,确保NTP或Chrony服务正常运行。# systemctl status chronyd
- 防火墙规则。# systemctl stop firewalld
本次把多播复制的配置放到缺省虚拟主机里面, 即Host之下。
特别注意修改Receiver的address属性为一个本机可对外的IP地址。
4.5.2 配置验证
node2的server.xml中host配置,如下
<Host name="node2.cwy.com" appBase="/data/webapps" unpackWARs="true" autoDeploy="true" >
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="230.100.100.8"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="10.10.100.102"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
</Host>
node3的server.xml中host配置,如下
<Host name="node3.cwy.com" appBase="/data/webapps" unpackWARs="true" autoDeploy="true" >
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="230.100.100.8"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="10.10.100.103"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
</Host>
node2及node3两节点配置
#准备web.xml
cp conf/web.xml /data/webapps/ROOT/WEB-INF/
#为web.xml的<web-app>标签增加子标签<distributable/>来开启该应用程序的分布式
vim /data/webapps/ROOT/WEB-INF/web.xml
<distributable/>
重启后测试可以发现,通过负载均衡调度到不同节点,但返回的SessionID不变
4.6 session共享服务器
4.6.1 msm
msm(memcached session manager)提供将Tomcat的session保持到memcached或redis的程序,可以实现高可用。
目前项目托管在Github,https://github.com/magro/memcached-session-manager
支持Tomcat的6.x、7.x、8.x、9.x。
- Tomcat的Session管理类,Tomcat版本不同
- memcached-session-manager-2.3.2.jar
- emcached-session-manager-tc8-2.3.2.jar
- Session数据的序列化、反序列化类
- 官方推荐kyro
- 在webapp中WEB-INF/lib/下
- 驱动类
- memcached(spymemcached.jar)
- Redis(jedis.jar)
4.6.1.1 安装
https://github.com/magro/memcached-session-manager/wiki/SetupAndConfiguration
将spymemcached.jar、memcached-session-manage、kyro相关的jar文件都放到Tomcat的lib目录中去,这个目录是$CATALINA_HOME/lib/,对应本次安装就是/usr/local/tomcat/lib。
asm-5.2.jar
kryo-3.0.3.jar
kryo-serializers-0.45.jar
memcached-session-manager-2.3.2.jar
memcached-session-manager-tc8-2.3.2.jar
minlog-1.3.1.jar
msm-kryo-serializer-2.3.2.jar
objenesis-2.6.jar
reflectasm-1.11.9.jar
spymemcached-2.12.3.jar
4.6.2 Memcached
Memcached只支持能序列化的数据类型,不支持持久化,基于Key-Value的内存缓存系统。
Memcached集群,称为基于客户端的分布式集群。
Memcached集群内部并不互相通信,一切都需要客户端连接到Memcached服务器后自行组织这些节点,并决定数据存储的节点。
4.6.2.1 安装
[root@node2 tomcat]# yum install memcached
[root@node2 tomcat]# systemctl start memcached
4.6.3 sticky模式
原理
当请求结束时Tomcat的session会送给memcached备份。即Tomcat session为主session,memcached session为备session,使用memcached相当于备份了一份Session。
查询Session时Tomcat会优先使用自己内存的Session,Tomcat通过jvmRoute发现不是自己的Session,便从memcached中找到该Session,更新本机Session,请求完成后更新memcached。
部署
t1和m1部署在一台主机上,t2和m2部署在同一台。
配置
放到 $CATALINA_HOME/conf/context.xml中
特别注意,t1配置中为failoverNodes=“n1”, t2配置为failoverNodes=“n2”
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="t1:10.10.100.102:11211,t2:10.10.100.103:11211"
failoverNodes="t1"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>
</Context>
memcached的节点们;n1、n2只是别名,可以重新命名。
failoverNodes故障转移节点,n1是备用节点,n2是主存储节点。另一台Tomcat将n1改为n2,其主节点是n1,备用节点是n2。
实验
如果配置成功,可以在logs/catalina.out中看到下面的内容
- finished initialization:
- sticky: true
- operation timeout: 1000
- node ids: [t2]
- failover node ids: [t1]
- storage key prefix: null
- locking mode: null (expiration: 5s)
--------
配置成功后,网页访问以下,页面中看到了Session。然后运行下面的Python程序,就可以看到是否存储到了memcached中了。
import memcache # pip install python-memcached
mc = memcache.Client(['10.10.100.102:11211','10.10.100.103:11211'], debug=True)
stats = mc.get_stats()[0]
print(stats)
for k,v in stats[1].items():
print(k, v)
print('-' * 30)
# 查看全部key
print(mc.get_stats('items')) # stats items 返回 items:5:number 1
print('-' * 30)
for x in mc.get_stats('cachedump 5 0'): # stats cachedump 5 0 # 5和上面的items返回的值有关;0表示全部
print(x)
访问测试
可以看到浏览器端被调度到不同Tomcat上,但是都获得了同样的SessionID。
通过Python程序查看memcached保存信息
4.6.4 non-sticky模式
原理
从msm 1.4.0之后开始支持non-sticky模式
Tomcat session为中转Session,如果n1为主session,n2为备session。产生的新的Session会发送给主、备memcached,并清除本地Session
n1下线,n2转正。n1再次上线,n2依然是主Session存储节点。
memcached配置
放到 $CATALINA_HOME/conf/context.xml中,两个节点都配置一样
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="t1:10.10.100.102:11211,t2:10.10.100.103:11211"
sticky="false"
sessionBackupAsync="false"
lockingMode="uriPattern:/path1|/path2"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>
重启tomcat,访问测试
通过Python程序查看memcached保存信息
4.6.3 redis
下载jedis.jar,放到$CATALINA_HOME/lib/,对应本次安装就是/usr/local/tomcat/lib。
$CATALINA_HOME/conf/context.xml配置
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="redis://10.10.100.102:6379"
sticky="false"
sessionBackupAsync="false"
lockingMode="uriPattern:/path1|/path2"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>
5、总结
通过多组实验,使用不同技术实现了session持久机制
- session绑定,基于IP或session cookie的。其部署简单,尤其基于session黏性的方式,粒度小,对负载均衡影响小。但一旦后端服务器有故障,其上的session丢失。
- session复制集群,基于tomcat实现多个服务器内共享同步所有session。此方法可以保证任意一台后端服务器故障,其余各服务器上还都存有全部session,对业务无影响。但是它基于多播实现心跳,TCP单播实现复制,当设备节点过多,这种复制机制不是很好的解决方案。且并发连接多的时候,单机上的所有session占据的内存空间非常巨大,甚至耗尽内存。
- session服务器,将所有的session存储到一个共享的内存空间中,使用多个冗余节点保存session,这样做到session存储服务器的高可用,且占据业务服务器内存较小。是一种比较好的解决session持久的解决方案。
以上的方法都有其适用性。生产环境中,应根据实际需要合理选择。
不过以上这些方法都是在内存中实现了session的保持,可以使用数据库或者文件系统,把session数据存储起来,持久化。这样服务器重启后,也可以重新恢复session数据。不过session数据是有时效性的,是否需要这样做,视情况而定。