NginxHttpd负载均衡tomcat配置教程

Nginx/Httpd负载均衡tomcat配置教程

本文主要介绍Nginx/Httpd负载均衡tomcat的配置方法。本文以图文并茂的形式为您详细介绍，对您的学习或工作有一定的参考价值。有需要的朋友可以参考一下。

在之前的博客中，我们谈到了使用Nginx和httpd来配置后端tomcat服务。请参考https://www.cnblogs.com/qiuhom-1874/p/13334180.html的评论。今天就来说说用Nginx和httpd来负载均衡tomcat集群，以及需要注意的点。前面的演示和配置都是用单个tomcat配置和使用的；但是，单个tomcat无法支持生产中的大规模访问。这时候就需要考虑把多个Tomcats做成集群，对外提供服务。当多个tomcat被集群起来提供外部服务时，必须有一个调度器来调度客户机的请求。常用的调度器有nginxhttpdhaproxylvs等。使用这些调度程序来平衡tomcat和其他web服务器的负载没有本质的区别。我们都可以将tomcat配置为web服务器；

1。环境准备

运行docker启动两个tomcat容器作为后端tomcat服务器，将两个tomcat容器的web目录以存储卷的形式映射到/tomcat/doc/tomcat1和tomcat1目录。

提示:上面运行了两个tomcat容器，tct1和tc2，我们把/usr/local/tomcat/webapps/myapp映射到主机的/tomcat/doc/tomcat1和tomcat2，这样就可以直接把网页脚本放在主机上这个目录下，把网页部署到Tomcat默认的虚拟主机上；

编辑两个容器的主页文件的内容。

提示:以上分别为tomcat1和tomcat2提供了测试主页；

现在分别播放tomcat1和tomcat2，看看对应的主页是否可以访问。

提示:可以看到tomcat1和tomcat2可以访问，之后tomcat环境就准备好了；接下来，我们来配置nginx对它们进行负载均衡；

2.将nginx配置为负载平衡tomcat

提示:上面的配置是将两个tomcat容器合并到tcsevs组中，然后访问这个组而不是/。默认情况下，此配置正在轮询；

验证:访问主机上的80端口，看看能否访问后端两个tomcat容器分别提供的主页？

检查nginx配置文件的语法格式并启动nginx。

访问主机的80端口，看能不能访问后端tomcat提供的页面？

提示:可以看到主机80端口可以正常访问后端tomcat服务器，也可以看到默认轮询调度的效果；但是，这里有一个问题。当同一个用户访问主机的80端口时，响应结果是不同的，这意味着nginx没有跟踪用户的状态信息。http请求的会话id是无状态的。为了让服务记录用户的状态信息，我们可以基于源ip在nginx上进行调度。什么意思，就是说同一个源ip地址，nginx都把请求调度到同一个后端服务器上，这样同一个用户访问的状态信息总是可用的。

Nginx维护基于源ip的会话

提示:ip_hash和hash$remote_addr都表示对源ip进行哈希处理，然后对得到的结果和总权重进行模数化。如果结果落在那个节点，它将被分派到那个节点；你什么意思？如上图，有两个后端服务器，它们的权重都是1，所以它们的权重和是2。ip_hash和hash$remote_addr对客户端ip地址的前三段进行哈希运算，然后将得到的值加到权重和上做取模运算。显然，模后端的结果不是0就是1。如果取模后的结果是1，那么nginx使用其中的对应关系来计算客户端ip地址的值。

测试:重启niginx，访问主机的端口80，看是否所有请求都调度到同一个后端服务器？

提示:可以看到，访问主机的80端口现在不是轮询，而是一直调度给服务器tomcatA响应；但是，当我们访问127.0.0.1的端口80时，它又被安排到tomcatB。这是因为nginx的调度算法中的hash$remote_addr和ip_hash是ip地址的前24位，所以如果你的IP的前三段是相同的，nginx会认为是和nginxserver是同一个局域网，所以会把请求调度到同一个局域网，再响应请求的后端服务器；当然，除了我们可以哈希源地址，我们也可以哈希其他头。原理差不多，就是把对应头的值散列，然后用权值和进行模运算；然后根据nginx的内部对应关系，将取模后端结果相同的请求调度到同一个后端服务器。基于这个原理，客户端和后端服务器绑定在一起，实现会话绑定。

Httpd在tomcat上执行负载平衡

Httpd作为负载均衡器，需要确认httpd是否启用了proxy_http_module、proxy_module和proxy_balancer_module。如果需要ajp，还需要确认proxy_ajp_module模块是否启用。以及调度算法的三个模块，即lbmethod_bybusyness_module、lbmethod_byrequests_module和lbmethod_bytraffic_module以上模块可以用于或启用调度算法，对于http或ajp也是如此；拿到就启用，不用不用都无所谓；

提示:你可以看到我们需要的模块都启用了；

将httpd配置为负载平衡后端tomcat。

提示:从上面的配置来看，其实感觉和nginx的配置逻辑很像。首先，将后端服务器合并到一个组中，然后将请求代理到定义的组。这里先说一下调度算法。proxysetlbmethod用于指定调度算法。默认情况下，如果没有编写byrequests，则使用它。该算法是httpd中的轮询调度算法。当然，为每个balancermember添加一个权重会使它成为一个加权轮询。除了这个调度算法，我们还可以使用bytraffic，根据与后端服务器的传输流量进行调度。如果一个服务器传输流量大，它会把请求调度给传输流量相对较小的服务器；调度算法bybusy根据后端服务器的繁忙程度进行调度；类似nginx中的least_conn的最小连接算法；对于balancermember，我们也可以像nginx一样单独设置一个属性，在后面写对应的属性就可以了；常用的属性包括status，表示对应的balancermember处于什么状态。状态有六个值；d表示在不提供任何请求的情况下禁用相应的服务器；s表示手动识别不可用；I表示强制在线模式(强制忽略错误模式)；h表示热备模式(相当于nginx中的备份，只有在组内其他服务器不可用时才会被激活用于saysorrye表示被迫处于错误模式(即使没有错误，也让他处于错误)；n代表排水模式；除了status来指定balancermember的状态，还可以使用loadfactor来指定权重，类似于nginx中的权重；

停止nginx，检查httpd的配置文件语法，没有问题就启动httpd。

访问httpd提供的服务，看看能否访问后端tomcat页面。

提示:可以看出，轮询可以像nginx的访问一样实现；

Httpd基于cookie使会话粘着到后端tomcat

提示:以上配置是指在客户端请求的cookie头中添加一个标识符，ROUTEID=%{balancer_worker_route}e是指我们指定的ROUTEID标识符的值是balancermember之后的route属性指定的值；Env=BALANCER_ROUTE_CHANGED表示如果我们指定的路由的值发生变化，需要重新调度；简单来说，就是标注cookie信息；Proxysetstickysession=ROUTEID表示为组内所有成员设置的会话粘滞键名称为ROUTEID，通常对应于上述set-cookie后面的键；如果写在每个balancermember之后，则意味着单独为某个服务器设置sessionstickyKEY的名称；如果写在代理配置部分，需要用proxyset指令设置，则表示设置stickysession对于该组的所有成员；简单来说，就是声明将key作为会话粘性的基准进行调度；这个逻辑类似于haproxy中的会话保持设置；关于haproxy配置的会话保留，可以参考https://www.cnblogs.com/qiuhom-1874/p/12776261.html；

测试:检查httpd的配置文件语法，没有问题重启httpd，然后访问httpd看看会有什么变化。

用curl模拟第一次访问httpd服务器，看看响应头有什么变化？

提示:你可以看到，当你访问httpd服务器时，在响应头中会有一个set-cookie头，这个头的值就是我们之前在配置文件中配置的KEY和值；Set-cookie头主要是浏览器在下一次请求的时候，会将set-cookie头的值和cookie头一起携带访问服务器，这样服务器就可以根据客户端请求消息的cookie值来分析客户端发出的请求，如何调度后续的服务器；

使用浏览器访问并查看客户端的后续请求。您是否在第一次访问时获取set-cookie的值并请求服务器？

提示:可以看到浏览器第一次访问时，服务器会在响应头中添加一个set-cookie头；这个头的值是ROUTEID是我们后端服务器上对路由的当前响应的值；

提示:可以看到客户端在请求头cookie中携带了之前set-cookie中的所有值；此时，httpd收到客户端请求时，可以根据设置的stickysession指定的KEY，判断相应的请求应该发送到后端服务器进行响应；这样，只要客户端的cookie不变，每次访问服务器时，都会用cookie头的值告诉服务器应该调度到后端服务器；

使用curl来模拟客户端使用cookie访问服务器的请求。

提示:我们可以看到，当我们使用curl模仿客户端访问携带cookie时，set-cookie头不会在响应头中发送给我们(这里的set-cookie指的是与我们在服务器中的设置相关的头)，我们携带不同路由ID的cookie，会根据我们携带的ROUTEID的值将我们调度到不同的后端服务器进行响应；对于httpd负载均衡代理，后端tomcat带ajp的配置与http相同，只是后端服务器的http协议改为ajp，后端tomcat的端口改为ajp协议监控的端口。默认的tomcatajp协议在端口8009被监控；

配置httpd后端管理界面页面

提示:上面的配置意味着httpd管理页面被启动并绑定到uri/manager-page。uri/manager-page不使用代理，rui只能允许ip地址为192.168.0.232的主机访问它。其他主机没有权限，包括服务器本身；

验证:使用192.168.0.232以外的主机访问192.168.0.22/manager-page看是否可以访问？

提示:可以看到192.168.0.22用于访问，提示403没有权限；

用192.168.0.232访问，看能不能访问管理页面？

提示:使用192.168.0.232上的浏览器可以正常访问httpd的管理页面；

动态修改tomcat1的权重

提示:因为这个页面可以动态改变后端服务器的属性，所以通常需要访问限制；

关于Nginx/Httpd负载均衡tomcat配置的这篇文章到此为止。有关Nginx/Httpd负载平衡tomcat配置的更多信息，请搜索我们以前的文章或继续浏览下面的相关文章。希望大家以后能多多支持我们！