一、为何要集群
单台App Server再强劲,也有其瓶劲,先来看一下下面这个真实的场景。
其时这个工程是这样的,tomcat这一段被称为web zone,内里用spring+ws,还装了一个jboss的法则引擎Guvnor5.x,全部是ws没有service layer也没有dao layer。
然后App Zone这边是weblogic,传输用的是spring rmi,然后App Zone这块全部是service layer, dao layer和数据库打交道。
用户这边用的是.net,以ws和web zone连的。
时间一长,数据一多,就出问题了。
拿Loader Runner跑下来,觉察是Web Zone这块,App Server已经被用到极限了。因为客户钱不多,所以其时的Web Zone是2台处事器,且都是32位的,昆山软件开发,内存不少,有8GB,测试下来后觉察cpu loader又不高,可是web server这边的吞吐量始终上不去,且和.net客户端何处响应越来越慢。
阐明白一下原因:单台tomcat可以或许遭受的最大负载已经到头了,单台tomcat的吞吐量就这么点,还要承担Guvnor的运行,Guvnor内有数百条业务法则要执行。
再看了一下其它方面的代码、SQL调优都已经到了极限了,所以最后没步伐,客户又不愿拿钱投在内存和新呆板上可能是再买台Weblogic,只能取舍一下,搞Tomcat集群了。
二、集群分类
Tomcat作集群的逻辑架构是上面这样的一张图,要害是我们的production情况还需要筹划好我们的物理架构。
2.1 横向集群
好比说,有两台Tomcat,别离运行在2台物理机上,长处是最大的即CPU扩展,内存也扩展了,处理惩罚本领也扩展了。
2.2 纵向集群
即,两个Tomcat的实例运行在一台物理器上,充实操作原有内存,昆山软件开发,CPU未获得扩展。
2.3 横向照旧纵向
一般来说,广为人们接管的是横向扩展的集群,可做大局限集群布署。可是我们这个case受制于客户即:
可是呢,通过压力测试陈诉我们可知:
因此,我们只能做熊掌与鱼不能兼得的事,即回收了:纵向集群。
2.4 Load Balance与High Available
简称LB即负载平衡,相当于1000根线程每个集群节点:Node认真处理惩罚500个,这样的效率是最高的。
简称HA即高可用性,相当于1000根线程照旧友给一台呆板去逐步处理惩罚,假如这台呆板崩了,另一台呆板顶上。
三、集群架构中需要办理的问题
集群筹划好了怎么分,这不便是就可以开始实现集群了,一旦你的系统实现了集群,随之而来的问题就会呈现了。
我们原有系统中有这样几个问题,在集群情况中是需要办理的,来看:
3.1 办理上传文件同步的问题
集群后就是两个Tomcat了,即和两个线程读同一个resource的问题是一样的,还好,我们原有上传文件是专门有一台文件伺服器的,这个问题不大,两个tomcat都往一台file server里上传,文件伺服器已经帮我们办理了同名文件斗嘴的这个问题了,假如原先的做法是把文件上传到Tomcat的目次中,那问题就大了,来看:
集群情况中,对付用户来说一切操纵都是透明的,他也不知道我有几个Tomcat的实例运行在何处。
用户一点上传,大概上传到了Tomcat2中,可是下次要显示这个文件时,大概用到的是Tomcat1内的jsp可能是class,对差池?
于是,因为你把图片存在了Tomcat的目次中,因此导致了Tomcat1在显示图片时,取不到Tomcat2目次中存放的图片。
因此我们在工程一开始就强调存图片时要用一台专门的文件处事器可能是FTP处事器来存,就是为了制止未来呈现这样的问题。
3.2 办理Quartz在集群情况中的同步问题
我们的系统用到一个Quartz(一个按时处事组件)来按时触发一些自念头制,此刻有了两个Tomcat,粗想想每个Tomcat里运行本身的Quartz不就行了?
可是问题来了,假如两个Quartz在同一时间都触发了处理惩罚同一条定单,即该条定单会被处理惩罚双方。。。这不是影响效率和增加堕落机率了吗?
因为自己Quartz所遭受的压力险些可以忽略不计的,它只是按时会触发剧本去运行,要害在于这个按时剧本的同步性,一致性的问题上。
我们曾想过的办理要领:
我们可以让一个Tomcat布署Quartz,另一个Tomcat里不布署Quartz
但这样做的功效就是假如布署Quartz的这个Tomcat瓦解掉了,这个Quartz是不是也崩啦?
最后办理的步伐: