Tomcat集群快速入门

这一节我们学习tomcat集群,这一节非常重要,请大家仔细认真学习,首先我们看一下目录,会领着大家一起回顾一下,

第一期的tomcat配置,然后是mac和linux下的,还有一个windows下的,然后再回顾一下第一期的nginx配置,简要回顾,

首先我们思考第一个问题,tomcat集群后能带来什么,然后是tomcat集群后的实现原理,还有tomcat集群新旧架构的

对比解析,第一期我们是单服务器,单tomcat,而二期我们要用tomcat集群了,会领着大家一起把架构进行一个对比和分析,

然后再思考一个问题,tomcat集群带来了什么新问题,后边会详细的给大家一起来学习

然后讲一下tomcat单击部署多应用,多机部署多应用,什么意思呢,单机部署多应用就是说,我有一台服务器,在这台

服务器上,我开多个tomcat实例,那我们课程开两个,当然多个的方法也有讲,大家认真听讲肯定能搞定,多机部署多应用呢,

就是说假设我有A,B,C三条服务器,然后我在A,B,C这三台服务器上,每一个机器安装了一个tomcat,然后把这三台做成一个

集群,对于学习来说,单机部署多应用,更富有挑战性,而且考虑到大家并没有那么多电脑,开多个虚拟机电脑也容易卡,在阿里云

购买多个阿里云服务器的时候,毕竟还要付出一定的成本,我们会重点讲一下nginx的一些配置,策略,场景及特点,这点非常重要,

前两个讲完之后,就会讲nginx+tomcat集群,然后就是tomcat集群的验证,目录虽然少,但是干货非常多,我们一起来往下看

tomcat集群能带来什么,挑重要的两句话来讲,这两句话就是,第一提高服务的性能,并发能力,以及高可用性,

当然实际公司的线上环境,都会选择一台机器部署一个tomcat,毕竟一个机器部署一个tomcat,他们还是有共享

瓶颈的,如他们的网卡公用一个,他们的内存是公用的,他们的磁盘IO等等性能,那么在实际的生产环境呢,会把

他们进行一个隔离,一台机器部署一个tomcat,并发能力很简单,一台tomcat的http线程池,是有限的,根据你机器的

性能,那两台我能承载的,http线程就变成了二倍,高可用性这个也非常好理解,什么叫高可用呢,那简单理解,nginx

下面挂了多台tomcat,当tomcat1挂掉的时候,我们可以把这个节点,从nginx负载均衡,tomcat集群的配置当中摘掉,

ngxin还会搭到可用的tomcat服务器上,并不影响我们提供的服务器,tomcat就能带来一定的可用性,第二个非常重要,

提供项目架构的横向扩展能力,如何理解横向扩展能力,假设我又一台服务器,我通过不断地升级他的内存,CPU换成

固态硬盘,这种我们认为是一种纵向,纵向提高机器的配置,来达到提高tomcat所提供服务的一个性能,那随着硬件的

不断提高,其实这个成本是上升的,这个在一期架构演进上,有讲,那tomcat能带来一个横向扩展能力,很简单,打个比方,

例如说天猫的双十一,双十一是一个非常重要的,对于天猫来说,平时的访问量可能没有那么高,那双十一的时候,访问量是

非常的高,tomcat集群OK之后呢,我们就可以做一个横向扩展,只要去加tomcat节点,就可以了,根据实际的数据,以及对历史

数据做一个评估,当然这个还有一定的动态能力,就是说我根据实际情况,动态的增加几个节点,让nginx进行一个热部署,

就把新增的节点加入到这个节点当中,这两点很重要,大家好好理解这两点,我们继续

我们继续,tomcat集群实现的原理,咱们课程一定是本着最简单的学习,来学习复杂的知识,所以一句话概括,

我们通过nginx负载均衡,对多个tomcat,进行请求转发,来实现我们二期的tomcat集群,接下来比较重要,开始

进行新旧架构对比,一期架构和二期架构的对比,我们先看看一期的架构,上面三个圆圈,123代表用户,他们访问nginx,

也就是说,nginx对外开放80端口,然后nginx把这个请求,转发到下面的tomcat app server,然后我们部署到tomcat

服务器上的javai项目呢,下面连着DB,右边连着ftp file server,ftp服务器,在项目当中呢,提供图片的上传,下载,

浏览等功能,然后有session,因为我们一台服务器,所以session直接存在server里面,用的servlet原生的一个session,

那这个时候,我们看一下,我们把tomcat进行横向扩展的一个架构

我们把tomcat http server横向扩展之后的架构,那就来到了想当然的二期架构,我们一起来看一下,user 1 2 3来请求

server,就是说nginx,然后nginx进行一个load balance,负载均衡,然后下边挂着三个节点,三个tomcat,下面连着DB,右侧

呢,是ftp file server,这个时候,我来提问一个问题,大家想一下,user1顺着这个路径往下找,他请求了web server,然后负载

均衡到第一台web server上,那这个请求呢,是登陆请求,登陆请求,他把session信息存在第一台tomcat上,user1的登陆信息,

存到了这里,user1这个时候呢,发起下单,生成订单,我们的逻辑是说,想生成订单之前,必须是已登录状态,而它这一次请求,

生成的订单,通过web server,也就是nginx,请求到了第二台tomcat上,这个session并没有user1的登陆信息,它会让user1重新

登陆,那其实已经中断了我们的下单流程,从用户体验上呢,user1其实是已经登陆了,他不了解你下边的技术原理实现,他总之

会认为,我已经登陆了,为什么还要让我登陆,那除非是user1这个用户,所有的请求都达到第一台tomcat上,那能保证这个流程是顺畅的,

这个的弊端,以及均衡的配置,后边会有详细的讲,想当然二次架构就会出现这个问题,我们的session没有共享,那我们要解决这个

问题,我们继续看

带来了什么新问题,一句话,session登陆信息,存储及读取的问题,还有服务器定时任务并发的问题,咱们项目在

下完订单之后,如果没有付款,需要自动关闭,自动关闭这个订单,当然呢,会有一个定时器,他下单之后,多久没有

付款,然后来关闭这个订单,并把库存释放出来,定时器假设我们配置的,是每分钟跑一次,监听这一分钟,需要关闭

的订单,那我们的tomcat是多态服务器,一到这个时间点的时候,所有机器都启动了这个定时任务,他们一起去读取

SQL,然后判断订单,这个是一个非常简单的配置,首先我们这个逻辑非常的简单,并不会造成线上的严重的故障,

那如果遇到非常复杂的场景呢,非常容易造成我们线上的数据错乱,并且该更新的更新不上,他们之间有一个竞争关系,

这个是非常严重的,而且在查问题的时候呢,还不是太好查,然后是....,对于不同的场景会有很多的问题,这个要阐述

什么呢,就是随着我们项目架构的演进,从架构层面的变化,会引起代码层面的变化,以及解决方案的变化,千万不要想当然的

认为,集群就是多部署几个TOMCAT就OK了,这个都要根据实际的业务场景,去分析,去改变,去演进,所以大家在学这个课的时候,

希望大家的思考力,思考问题的深度,广度还有角度呢,都有所提高,我们不能再做单纯的小白,希望大家学完这个课,从技术,

思想,方面都有提高

我们看一下解决方案,如果单纯的想解决登陆的问题,我们可以用nginx ip hash这么的一个策略,他的优点很简单,

就是可以不改变现有的技术架构,直接实现横向扩展,两个字,省事,也就是说,根据请求的IP,那user1有一个ip,他的ip

进行一个hash取模,hash之后他指定到指定的服务器,那么这个ip发过来的请求,都会请求到这台服务器上,当然呢他也有

缺点,这种方式在实际的公司,生产环境用的是非常少的,他的缺点是什么呢,第一导致服务器请求,负载不平均,完全依赖

hash ip的结果,很简单我们用局限的思维简单的考虑一下,假设有两个人,这两个人的服务器,ip hash之后,全部请求到

第一台tomcat上,那这个时候呢,假设就两个人来访问,而我们有两个tomcat,那我们这个服务,对我们的用户来说,tomcat2

其实是没用的,因为这两个ip hash,只会请求到第一个tomcat上,一台服务器使两个请求都达到这里,另外一台服务器闲的蛋疼,

一个请求都没有,那还有一个缺点,在IP变化的环境下,无法服务,如果你的网络环境,IP经常变化,那我这次哈希到tomcat1上,

过了一会又变化了,又hash到tomcat2上,那对于这个用户来说,我们的服务无法给她提供一个正常的服务,在用户体验上呢,

也是非常不好的,那我们来看一下,我们二期的真架构是什么样的

这个图一打眼看上去, 比一期的要复杂多了,但是听我慢慢地给大家讲,首先上面是用户,这个是一个web server nginx,

load balance,那http请求转发呢,转发到这三台服务器上,tomcat app server,ABC ok,那下面还是DB,三条路径来请求DB,

右侧请求一个ftp file server,这里要强调一下,架构绝对不是一蹴而就的,所以我们项目慢慢演进,高可用性也会不断提高,

例如文件服务器组成分布式的,我们nginx也会做一个集群,项目架构会一点点演进,并且呢随着演进,会产生代码的演进,这个

过程,是弥足珍贵,并且是非常重要的,所以呢我们还是脚踏实地的,一步一步的来,先把我们二期课程,学明白,理解透,学精,

然后我们来看一下左侧,多了一个分布式的redis,session server,那tomcat abc,请求session的时候呢,全部指向这个分布式

的redis session server,那就很容易理解了,user1请求过来,无论达到abc哪台机器上,我都会把session信息,存储到redis

的session服务器当中,第二次请求无论打到任何一台机器上,都会从这个分布式redis,session服务器当中,获取他的登陆信息,

因为我们做了分布式,redis的一个session server,所以我们还要做一个单点登陆,后面的章节就有讲,然后我们还会利用这个

分布式redis,做一个分布式锁,来解决我们tomcat abc,在同一个时间点启动,定时任务的一个问题,先不管他们会不会对数据

或逻辑,造成问题,那么从另外一个角度,如果不去做分布式锁的话,其实已经造成CPU内存的浪费,因为在同一个时间点,需要一台

机器启动一个定时任务就可以了,其他机器不需要启动,并且随便那一台都OK,那在线上的生产环境,由于请求对于某些业务逻辑,

处理的一个放大,那其实我们一点点的优化,对整个架构都会有比较大的正向作用,那我们这一期会领着大家,搭建reids,然后呢,

讲一下redis的分布式原理,怎么用redis做一个分户式锁,还有讲一下,redis的一个主从,希望我所讲的一切,都被小伙伴们吸收

百分之一百,那再说一点,如果是学过一期的小伙伴,之前肯定看过,如果是学过二期的小伙伴,也不用担心,我有一个大型架构的

一个演进,那个是一个文本总结,小伙伴们一定不要着急,架构都是一步一步来的,把tomcat进行集群之后,我们有很多的点需要

进行修改,优化,提高,慢慢的包括队列