tomcat 负载均衡

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/hosts10.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 OffProxyVia OnProxyPreserveHost OnProxyPass / balancer://lbtomcats/ProxyPassReverse / balancer://lbtomcats/
</VirtualHost><Proxy balancer://lbtomcats>BalancerMember http://node2.cwy.com:8080 loadfactor=1BalancerMember http://node3.cwy.com:8080 loadfactor=2
</Proxy>
#loadfactor设置为1:2，便于观察。观察调度的结果是轮询的。

使用session黏性

[root@node1 ~]# vim /etc/httpd/conf.d/vhost.confHeader add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<VirtualHost *:80>ProxyRequests OffProxyVia OnProxyPreserveHost OnProxyPass / balancer://lbtomcats/ProxyPassReverse / balancer://lbtomcats/
</VirtualHost><Proxy balancer://lbtomcats>BalancerMember http://node2.cwy.com:8080 loadfactor=1 route=Tomcat1BalancerMember http://node3.cwy.com:8080 loadfactor=2 route=Tomcat2ProxySet stickysession=ROUTEID
</Proxy>
~

测试发现Session不变了，一直找的同一个Tomcat服务器。

ajp调度

[root@node1 ~]# vim /etc/httpd/conf.d/vhost.conf<VirtualHost *:80>ProxyRequests OffProxyVia OnProxyPreserveHost OnProxyPass / balancer://lbtomcats/ProxyPassReverse / balancer://lbtomcats/
</VirtualHost><Proxy balancer://lbtomcats>BalancerMember ajp://node2.cwy.com:8080 loadfactor=1 route=Tomcat1BalancerMember 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-memcachedmc = 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数据是有时效性的，是否需要这样做，视情况而定。