基于terracotta集群式web系统单节点故障屏蔽与服务优化

BACHELOR'SDEGREETHESISOFWUHANUNIVERSITYTheLoad-balancingAndMalfunctionRestoringWithTerraCotta Directedby郑重本人呈交的，是在导师的指导下，独立进行研究工作所取得的成果，所有数据、资料真实可靠。尽我所知，除文中已经注明的内容外，本的研究成果不包含他人享有著作权的内容。对本所涉及的研究工作做出贡献的其他个人和集体，均已在文中以明确的方式标明。本的知识归属于培养单位。本人签名 日期 高并发条件下，WEB服务器集群着几个重要的问题。第一是负载均衡问题，即如何将超大负载合理地分布在整个集群中；第二是单节点故障问WEB存在着多种联系，在于单节点故障问题的技术与服务优化。本文的主要目的，即通过基于表述性状态转移(REST)的服务器资源，TerraCotta本文在第一章简述了WEB服务器集群在高并景下的主要问题，以及本文第二章总结了高并发情景下，WEB服务器单节点故障问题的影响以技术的基本原理及其与布隆过滤器技术的应用结合。第四章分析了WEB服务器负载均衡及恢复策略。本文第五章详细介绍了利用开源TerraCotta的WebSession管理功能进行单节点故障的原理，并以Apache、Tomcat为例，结合TerraCotta提供了搭建具有负载均衡和单节点故障功能的集群服务器的方法及详细配置步骤。第六章则分析对比了现行的资源，并利用资源，提出了在WebWeb：集群；负载均衡；单节点故 IntheconditionofClusterWebServer,theclusterhasbeenfacingseveralproblemswhicharemakingtheclustermoreandmoreunstable.Theofallisthemethodofload-balancing,thatis,howtodistributethewholeloadinthecluster.Thesecondistheproblemofsingleserverbreakdown.Tosolvethisproblem,weshouldfindawaytorecoverthesessionswhentheserverholdingthesesessionsisdown.ThelastoneistheimprovementofWebService.Theproblemisaboutthereduplicaterequests.Thisp rwillintroducesometraditionalmethodstoimplementthecategoryofload-balancing.Afterthat,IwillspendthemostwordsonhowtouseTerraCottatoimprovethemethodofsingleserverbreakdown.AndIwillexplainhowtobuildasystemwithApache,TomcatandTerraCotta.Theintroductionofthebasictechniquewillbeinthisparttoo.ComingtotheproblemofimprovementofWebservice,thisp introducessometipsofResourceDescriptionFramework(RDFS)andBloomFilter.Basedonthesetips,somemethodtoimprovethewebservicewillbementioned,withoutanyimplementation.Keywords:cluster;load-balancing;malfunction-restoring;service 第一章绪 第二章信息简 信息的意 布隆过滤器（Bloom REST简 第三章负载均衡及恢复策 基于session的单节点故障方 第四章基于TerraCotta的单节点故障及实 TerraCotta的故障方案原 第五章集群式Web系统请求处理的优 第六章总 参考文 第一章绪论选题的背景及webDB（图1.1。大量的终端通过负载均衡器了系统所提供的大量服务和信息。然而，随着网络硬件条件快速发展以及云概念的兴起和成熟，应用程序本身由客户端向服务器的转移、海量信息由客户端向云的转移也将。作为前者的例证，业界中已经出现了众多服务，又称为SaaS（Software-service，获得服务的形式，获得的功能；而后者的现实例子，最典型的就是为了实P2P多不可忽视的影响，并对经典的Web系统结构提出了诸多方面的。本文将Web行改进，并最终从理论上提出一个改良了的、能够应对上述的Web系统结高并发情景下WEB服务器集群的主要问WebC-S90WEBWEBWEB务器的承载能力，除了应对的泛红式以外，免于接受最严酷的负载能力考验。然而，21世纪初，由于以“人人参与”为的Web2.0的兴起，网络信息的来源迅速扩大，信息总容量开始呈式增长，进而带来了信息的时代，这使得传统的C-S体系由于服务器重负而难以维系，进而产生了P2PWeb2.0，Web3.0成了“人人创造”，从而将“信息”变成了“应用”，并完全模糊了应用与服务之间的概念。开放平台，API应用开发等都是非zip-like提下，一个Web服务器可能在某个瞬间规模远超平时的海量，进而导致服务器即服务体系的。2009年的“贴吧爆吧事件”作为典型的zip-like分布实例，无疑给Web运营商的负载能力和恢复能力敲响了警钟。综上所述，经典的集群式Web服务器以下三个显而易见的问题：第二：单节点故障第二：Web本文的分析完全基于(图1.1)Web第二章高并发情景下单节点故障问题的影响与处理技术简在电子商务诞生之初，一浪高过一浪的高并发用户就一直给着这个行这个领域争雄的几个巨头间技术实力的象征性指标。例如，Amazon圣诞节期间呈现zipf分布[1]的爆发式用户而大规模扩大服务器集群并开发相应的并发处理技术，从而建立了最早的企业云“AmazonCloud”[6]。并以此为基础，从众多竞争对手中赢得了“圣诞购物，成长为互联网零售业的巨头。而实际上，互联网用户行为呈现zipf分布特点[2]早已成为公认的事实，且已经有很多为了应对由此带来的高并发的成熟解决方案。情景下的负载均面对爆发式用户，互联网应用中服务器集群的负载均衡在更早的时候已经成为Apache等组织的研究对象，并拥有大量成通用解决方案[3][4][24]。目前来说，负载均衡已经不是处理高并发的瓶颈。为了在具情景下的数据库并由于高并发带来的数据库的并发控制的重要性却日益凸显。虽然主要发控制之间似乎总是一对体，需要设计在数据安全和事务并发处理性情景下的“处理互联除了浏览器端的展示外，在服务器端的程序归属于“处理”的范畴。一般来说“处理”可以分成“事务处理”（OLTP，OnLineTransactionProcess）和“分析处理”（OLAP，OnLineytics（unitACID一般来说，不具备ACID属性的处理都可以称之为OLAP，这不意味着OLAPOLTPOLAP作，需到强大的计算资源支持。OLTP和OLAP是评估“处理”的一个角在OLAP中，因为每个处理过程之间都是相对独立的，不具有OLTP的都有不同的解决方案。而这样的误区造成相当一部分电子商务从初期的低情景下的单节点故障及其影高并发情境下，单节点故障往往发生于用户最为集中的节点上。由于现代服务器资源虚拟化技术的广泛应用，用户的资源往往更为集中、最高的服务器节点，其节点的负载一般也比较高。再次情况下，如果其中一个节点发生故障，将会有大量的用户请求和被分散到周围节点上，而周障，也可能因为负载过高造成迟缓，导致用户的重复请求和刷新动作，从因此，通过适当的技术，有效单节点故障，成为了该并发情景下Web情景下的用户（ZipF）曲定律(Zipf’sLaw)与福定律(Bradford’sLaw)及洛卡定律(Lotka’sLaw)一起被称为计量学在文献分布领域中最重要的三大定律。定律的最初版本是一个文献计量学基本定律。哈佛大学教G．K．（G．K．Zipf）1935年通过对文献词频规律的研究，认为：若把篇较长的文章中每个词出现的频次从高到低进行递减排列，其数量关系特征呈双曲线分布。该定律应用于检索用的词表的编制和检索系统中文档结从根本上讲,定律可以表述为,在自然语言的语料库里,一个单词出现的频率与它在频率表里的成反比.所以,频率最高的单词出现的频率22powerlawprobabilitydistributions物的参考。定律是一个实验定律,而非理论定律.分布可以在很多现定律。例如，高并发情境下的用户分布，也符合定律。可以1.绝大部分的，都是由少数活跃用户产生的。例如，2009年的雅虎音乐数据挖掘结果发现，90%5%的用户产生的。2.绝大部分的，都集中在少数服务器资源上。例如2003年战80%附近。3.绝大部分的，都集中发生在某个较短时间内。例如2010年的贴吧爆吧事件和2013年的“点”事件。情境下单节点故障随着服务器制造技术和运行技术的提升，大部分服务器在正常情况下都可以长期稳定工作。大部分的服务器故障，都来自的爆发式增长。例如，热点导致的“点”效应，发生于2009年的著名的爆吧事件就是非常好的例子。由于社交网络的多个意见用户引导大量用户在特定贴吧集中发帖，导致该贴吧所在的物理机负载过高最终异常，进而造成了单节(snapshot)”，保留状态、有助于恢复。这种虚拟服务器映像可以用来迅速配置新的服务器实例。越来越多的公司甚至开始提供虚拟服务器映像第三章基于表述性状态转移(REST)的服务器简本章将简要介绍现有的信息REST标准，其次介绍布隆过滤器以及其应用情况。在第五章中将利用本章所介绍的技术Web服务的优化。3.1信息的意信息的必要性，来自于Web2.0带来的“信息”，海量信息大信息的检索带来了极大。一定程度的信息冗余可以提高检索速度，但无规则地冗余和重复，使得大量内容一致的信息元素为地在不同的资源单下，计算机和网络不得不认为具有不同标识符或者的文件具有不同的内容。因而，这种无规则的冗余和重复在信息总量有限的情况下，将使得云3.2布隆过滤器（Bloom布隆过滤器的提出是在于1970年,提出者是..布隆（BurtonBloom0/1布隆过滤器是为了有效应对哈希函数的而。传统的哈希函数判Hash围内，如果的位阵列长度为m个点，那么如果想将率降低到例如1%,m/1001%或者100倍或者更高的标志位空间。3.2.1布隆过滤器简介及应用案由于分布式结构中信息量越来越大，的速度仍然有可能降低，尤其是在存在大量无效的情况下，大量的无效可能导致服务器重复地检索其内容，从而导致有效请求无法得到及时响应。因而，用非检索的方式迅速判定请求是否有效，即请求的数据是否存在成为了无效请求的必要。哈希函数由于其极低的时间复杂度成为了这能的首选实现，即用一个位数组上。当标志位为1时，表示资源存在，并进行检索；当标志位为0时，哈希函数的最大问题是和为了控制率造成的空间浪费。假设Hash函数是良好的，如果的位阵列长度为m个点，那么如果想将率降低到例如1%,m/100空间浪费。在散列表只是标志位时这种浪费在比率上虽然达到900%，但由1（Bit）,因而浪费在总量上仍不算明显。但这个散列表经常要进行必要的扩展，比如一部分用于信息检索的信息以降低检索图2.1布隆过滤器 方案举而布隆过滤器正是为了解决这一问题而产生的。其基本原理是将一个元素的关键字用K个哈希函数到散列表中的K个位上。当这些位均为1时，则该元素存在，反之该元素不存在。哈希函数的本质是不同的资源被到同一个标志位，而在布隆过滤器中，当不同的资源被到同一个标志位时，解决的方法是将将标志位置为1.这样，即从根源上消灭了哈希算法的问题。从而不用为了降低率而扩大散列表长度。3.2.2布隆过滤器的性质与布隆过滤器无疑解放了散列表，从而使得散列表从实际上获得了扩展的可能。而布隆过滤器在用“同位相与”的方法解决哈希的同时，也带来了的性质，即假阳性可能（falsepositivepossible）和假不可能(falsenegativeimpossible)。假阳性可能（falsepositivepossible）是指在布隆过滤器中，可能出现假不可能（falsenegativeimpossible）则与假阳性不可能相反，即0表长度m和哈希函数个数K的适当搭配而控制在极低的范围内。相对于解放散其中k表示哈希函数的个数，m表示散列表的长度，而n表示经过布隆过滤布隆过滤器的操作是成功的，因为操作实际上就是将元素的所有标志位设置为1。而当某些标志位已经被置为1时，过滤器可以不用做出经典的布隆过滤器是没有删除操作的，因为你否只有要删除的元素到了该位。为了能解决布隆过滤器的删除问题，许多隆过滤器中删除的元素，从而利用反向布隆过滤器的“假不可能”性质来对于会多次产生删除的布隆过滤器，通过将散列表中的标志位扩展为s位来表示该位被多个元素。当一个元素被删除时，则从其每个标志位单元中的s位中置1位为0。该方案避免了删除可能造成的“假可能”（falsenegativeimpossible。与此同时，该方案虽然无法消除被删除的元素存在误m,n个元素和ks率p与m、k、snn正比，当nn3.3REST简RepresentationalStateTransfer用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST出了一些设计概念和准则：网络上的所有事物都被抽象为资源每个资源对应一个唯一的资源标识（resource通过通用的连接器接口（genericconnectorinterface）对资源 不会改变资源标识所有的操作都是无状态的（staess）Required requiredapi_keystringapi_keymethodstringRequired requiredapi_keystringapi_keymethodstring stringsecretKey的一个MD5值,vstringAPIoptional stringResponse的格式,XMLJSONXMLREST技术在国内著名的SNS社交人人网应用开发中已经成功的得以运RESTURLURLRESTURL据资源的集合，并对其进行操作，进一步获得自己所需要的资源。下面的REST人人网Rest数据服务器地址 2.2Rest第四章负载均衡及恢复策负载均衡与恢复是密不可分的两个部分。恢复的方案，本质上是以相互配合，一遍在故障发生时，最大限度地恢复和服务。在灾难恢复时，指的是除负载均衡服务器之外的服务器集群的负载均衡。LB负载均衡的产生及意由于网络量的迅速增加，传统的单一WEB服务器虽然性能不断提升，但务集群，为用户提供和数据服务，以降低单个服务器的压力。负载均衡是指将网络的负载以某种策略分发给集群内的各个服务节点传统负载均衡策Robin：务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器权重轮循均衡（WeightedRoundRobin：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A1，B3，C6，则服务器A、B、C10%、30％、60％到的使用率，避免低性能的服务器负载过重。（Random：RandomTime：探测请求（例如，然后根据中各服务器对探测请求的最快响应时间Connection到真正的负载均衡。最少连接数均衡算法对中需负载的每一台服务器都有FTP。处理能力均衡：此种均衡算法将把服务请求分配给中处理负荷（根据CPUCPU）最轻的服务器，由于考虑到了服务器的处理能力及当前网络运行状况，所以此种均衡DNS（FlashDNSInternetHTTP、FTP的服务请求，客户端一般都是通过解析来找到服务器确切的IP地址的。在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的解析请求，并在同一时间内把此解析成各自相对应服务器的IP地址（即与IP）并返回给客户端，则客户端将以最先收到的解析IP地址来继续请求服务，而忽略其它的IP地址Apachesessionsession,即会话的方式进行sessionApacheSessionwebsessionsession然，在web服务器结点之间分配session的算法可以进行改进。这需要开发新的负载均衡。这个方案同时也无法保证对单结点故障的。尽管可以通处理性的单结点故障，但却无法处理由物理原因导致的单结点故障。这对于一个一般的而言，也许并不起眼，用户只需要重新登录就可以开启一个新的session，但对于一个无人值守GIS应用终端而言，可能是性的。比如一个具有计数功能的公共交通指示牌，可能在维修到达前，都无法排除故障，即便其故障排除，其所的即时信息，也可能无法恢复。3.3单节点故障的概念及意服务器集群可能存在着性能和任务不同的服务器节点，而由于负载均衡策略的设置可能使得某些服务器节点在某些平衡策略允许的情况下超出自故障对需要长期session的Web应用影响巨大因为session的丢失意味着用户的上下文无法恢复。会话，即Session，其英文原意是“会话，”。在Web服务结构中，会话即Session的含义是指用户与服务器的一次交互的过程。从数据角度讲，是一中。Session中的是跟用户有关的一些数据，由Web应用具体管理其中的内因而可以说，服务器端可以通过Session知道用户的状态，因而，单节点故障屏Session基于session的单节点故障方完全session方案实现单节点故障这个方案从理论上而言，是在粘session方案的基础上，为了实现单节点故nsession(n-1)session户端之间发生。显而易见这个方案在单结点故障方面非常有效，因为session的冗余非常高，除非整个集群停止服务，否则不会出现会话丢失不可恢复的情况。假设服务器集群有nmsession，而两个节点间进行一次单个sessiont,sessionsessiont0=(n-1)*tsession为t1(n-1)*t*m;部分session方案实现单节点故障由于session方案中，在所有的服务器节点上大量的session的同步非常且没有必要，因而出现了部分session的方案，即将将服务器集群在逻辑上划分为数个更小的集群，在这些小的集群采取session假设集群nSmsessions了msession更新所需要的时间为t2=(n/s-1)*tSession方案的缺陷和问session方案容易导致巨大集群的网络负载，并增加了单节点故障session20000WEB20000session部分session方案对完全的session方案改进了很多，但在将所sessionsession时，每个子集群为了有效单节点故障，必须维持一定的负载能力冗余，并且使子集群点的数量维持在一定水平，这仍然没有解决session大量同时上述分析忽略了一个情况——这个系统可能是7*24式地有大量终端同时在运行。这样的情况下，系统的量将呈现不规律的（可能是时间上的 session故障期产生巨大的网络负载，部分单节点可能导致的单结点故障。如果系统处于饱和状态，几次大范围的session分发可能导致性的后无论是完全session还是部分session，都还是通过大量冗余的式来保证可恢复。而维持大量的session冗余，是因为负载均衡服务器控制请求转发时，并不能够有效地判断session冗余到底存在于哪些节点上，因而只有通过提高session冗余来提高 第五章基于TerraCotta的单节点故障及实Terracotta集群技简要介Terracotta是一款由Terracotta公司开发的著名开源Java集群平台。Terracotta公司成立于2003年创始人AriZilka原本是 师，该产品于2006年左右趋于成熟。Terracotta在JVM与Java应用之间实现了单机Java应用向集群化应用的无缝迁移使得用户可以专注于商业逻辑的开发，由Terracotta负责实现高性能、高可用性、高稳定性的企业级Java集群[5]。Terracotta平台是一个基于JVM的集群解决方案，允许用户在不修改代码的情况下把单机Java应用程序运行在多JVM⑴实现单机Java⑵允许Java程序就像本地数据一样集群共享数据，并且实现对共享数据的集群范围内的同步⑶提供给予网络的虚拟内存管理允许Java程序超过其内存空（heap）⑷数据保存在服务器端，因此客户端JVMJVM⑺服务器分片，实现服务器数据及数据吞吐量横向扩⑻通过JMX开放服务器信⑼提供可视化和管理界面，大大方便对整合集群的共享数据、性能数据、软硬件指标等的实施、调试、优化Terracotta平台DSO集群结构如图图 Terracotta平台DSO集群结构图TerracottaDSO平台提供了一个稳健、高效、高可用、易用、易管理的Java集群平台Terracotta为了进一步帮助J2EE开发充分利用其平台提供的各项特性，针对Java开发常用的Java技术平台提供了一系列快捷模（ExpressMode）的解决方案，包括Ehcache分布式缓存、Hibernate分布式二级缓存、WebSession集群、分布式JavaQuartz等等。Terracotta些特定的项目中甚至可以使用Terracotta来代替关系型数据库。对于集群中的Java对象来说，使用关系型数据库进行持久化，对象必须要实现序列化，从获得行序列化Terracotta就能够在集群范围内对Java对象进行高效率的持久化，Terracotta毕竟不是对象型数据SQLTerracotta的通用管理能力也有所欠缺，换句话说，Terracotta没有提供通用的工具来管理其管理的Java对象。目前，在大多数使用Terracotta进行数据的场合中，还是使用以关系型数据库为主，Terracotta为辅的方式。比如，Terracotta使用高性能的分布式Terracotta中，客户能嵌入一个无缝可调的实体中。简单Ehcache标准接口的单服务器，转变成多节点Terracotta缓解数据库压力、TerracottaTerracottaServer42.2：2.2的数据不会丢失。这种配置提供了一定的恢复（Failover）的能力，但是还是无法做到高可用性（HA2.3：2.3（mirroring：一般由两台或者多台物理服务器互为镜2.4：2.4双机或者多机镜像⑷服务器阵列分片模式（ServerArrayStri这是TerracottaFX系列产1G5台服务器做分片，每一台服务器可以2Terracotta服务器的负载均衡。这种数据分片的策略，也就是说哪个数据对象保存在哪个服务器上，对开发和实施人对共享数据和应用系统中的数据算法进行优化也可以简单地增加阵列分片为镜像，让多个镜像再组阵列分片。这样每个镜像做到高可用性，多个镜像2.5：图2.5服务器阵列分片模式（ServerArrayStriTerracotta配置文TerracottaXMLsystem,serversclientsandapplication.每个部分都提供了一系列相关的配置选项。配置文件中有些变量值会被Terracotta2.3：表 Terracotta配置文件系统替代变IP%（系统属性名称system部分、serversclients部分三个部分的部分元素属性/tc:tc-config/system/configuration-model元素指明配置相关信息是必须来自服务器还是每个Client都可能有本地化的配置，该属性有'development'和'production'两个值development模式中每个Client都可以有本地化的配置，Clients关信息，Client第一次连接服务器的时候会探测服务器的配置模式，如果是productionClient可以通过语句-Dtc.config=serverHost:dsoPort设置名为'tc.config'的系统属性来指定配置信息的来源。默认的模式是development。Terracotta服务器，可以定义一个或者多个服务器实行为每一个Terracotta服务器都需要知道其配置文件的来源如果一台Terracotta启动时则必须在命令行下通过-nname指定Terracotta⑴/tc:tc-配置文件中一个server段封装了一个Terracotta服务器实例的配置信息，server元素有三个可选属性，默认情况下，若用户省略host、name、bind属性的host值为%i即主机名称，name值为%i:dso-port即“主机名称：dsobind<server<serverhost="myotherhostname"name="server1"表 server元素的三个可选属值托管Terracotta服务器的主机ID主机的IP主机的IPTerracotta服务器的ID，可被用在启动Terracotta服的-nTerracottaClient的网络接口，接口的IP/tc:tc-config/servers/server/data与/tc:tc-data和logs元素分别指定了Terracotta服务器的数据和日志的位置。值得注意的是stderr:或stdout也可作为配置文件中logs元素的值。⑶/tc:tc-该部分指明了服务器集群的active-passive群内所有的服务器都适用，这部分如果省略，集群内的服务器会以disk-basedactive-passive模式运行。/tc:tc-config/servers/ha/mode元素指定服务器以'disk-based-active-passive'还是'networked-active-passive模式运行，默认的是'disk-<serverhost="%i"<serverhost="%i"⑷/tc:tc- 使用mirrroup段绑定多组rrotta服务器实例到一个服务器集群阵总结了mirrroup包含的元素：表2.5 roups>包含元<mirr无<mirrgroup-name可以被赋给无无无该部分指定了Clients的配置相关信息/tc:tc-config/clients/logs指定了Clients配置为类似client-logs-%h的值并在名为host1的主机上运行客户端，那么在该值被使用前将会被替换为client-logs-host1如果为/tc:tc-config/clients/logs指定的 ，那么该值会被解析为当前使用Terracotta服务的客户端的启动 。默认情况下/tc:tc-config/clients/logs的值是logs-%i即将日志信息在调用Terracotta服务的客户端程序的运行下的logs-%i下，其中%iIPstderr:stdout也可作为配置文件中logs元素的值。TerraCotta的单节点故障方TerraCottaTerraCotta是一款由TerraCotta公司开发的著名开源Java集群JVMJavaJavaTerraCottaJavaTerraCotta公司目前在、欧洲、澳大利亚、等地有近百名员工，为TerraCotta商业用户提供7x24技术支持、解决方案咨询等服务。同时在TerraCotta开源产品之上提供适用于企业用户的高端产品。TerraCotta公司在2009年收购了著名的Java开源缓存项目Ehcache以及Java任务调度项目Quartz。经过对该项目的深度整合，TerraCotta推出了易用性更高的分布式缓存、分布式任务调度以及分布式WebSession等快捷解决方案，进一步方便了 开发分布式Java应用。TerraCottaJVMJavaWebTerraCottaJavaTerracotta的时候，TerracottaTerracottaCPUsessiontomcat化，既避免了对数据库的依赖，又能达到负载均衡和恢复的效果。在对比TerracottaTomcat8TerraCottaSessionsessionTerraCotta并不是复杂平衡，它并不能替代典型的负载均衡诸如Apache等的作用，但其所提供的集群化策略，却可以与经典负载均衡相合，进而实现更好的负载均衡和恢复功能。TerraCotta的故障方案原TerraCotta的故障方案是其WebSession功能组件的一部分，其主要特点是利用分布式内存和javasessionSessionTomcatsessionTerraCottaTomcat节点之间Session以进行会话恢复，而是将恢复session的任务交TerraCottasessionTerraCottasessionsession4.1TerraCottaTerraCotta与Apache、Tomcat的整合原ApacheApache是一款跨平台的网页服务器，由最初由伊利诺伊大学香槟分校的国家超级电脑应用中心（NCSA）开发。在开源后，经过Apache开源的Apache2.xNCSA子，成为一款全新的网页服务器，在最多的时候，占有了全世界73%的网ApacheJSP因而往往在作为服务器时，需要Tomcat的支持。Apache的典型用途为作为JSP服务集群的负载均衡，其默认端口为80，并支持定向包协议（ApacheJServProtocolAJP8009.这使Apache（HTML）服TomcatAJPTomcat是一款开源的jsp容器，其作用就是将JSP页面编译解析并返回给显示层。Tomcat是Apache的Jakarta项目的一个子项目。由于其JSPTomcat在使用时，往往作为一项服务，在服务器系统内，默认的8080。Tomcat(ApacheJServProtocolAJP8009.AJPTomcatApache作为负载均衡服务器的页服务器集群中。终终PDA设PC终移动终负载均衡服务AJP/1.3协TerraCotta服务Session集中管Web服务器及计算集数据库集Figure:4-2具有TerraCotta功能sessoin管理功能的集群式Web服务图4.2Apache转发与TerraCotta单节点故障的基本原TerraCotta与Tomcat、Apache的整合及故障过TomcatjspWebApache，TerraCottaTomcatTomcat节点在启动后将自己至TerraCotta服务器在接收到Session后，TomcatsessionTerraCottasessionTerraCotta在接收到Session后，将session按照tomcat节点的名称进行标记，并加载至TerraCotta所的共享内存中，并不断检查各个Tomcat节点的状态。当TerraCotta发现某个Tomcat节点停止服务后，按照用户设置的恢复方案将把内存中原本由该节点的Session给集群中其他节点或部分节点。从而实现的恢复。Apache在检测到Tomcat节点失败后，将向其他节点转发用户的请求，而此时，这些用户已经在TerraCotta处获得了故障节点所的所有session.从而实现了故障。在某个tomcat节点向TerraCotta更新了故障节点的sessionTerraCotta将通知其余节点放弃该session，从而使得故障节点的Session被平均地分配在同时，TerraCotta还可以利用其Ehcache组件所提供的分布式缓存功能，提sessionTerraCotta与Apache、Tomcat整合的配置步4.3ApacheAJP/1.3TerraCottaSessionApacheApache-Httpd-jspApache本身是提供静态页面服务的服务器作为负载均衡服务器时，tomcatApache,所需要的功能模块为mod_jk，也简称为JK，这是一款Apache用来连接后台Tomcat的模块，支持集群和负载均衡 的mod_jk.so文件并拷贝Apahce的 下配置jsp分发功能的语句应该写在Apache根 中，该文件结构如下表Table4-1所示<IfModuleSSLRandomSeedstartupSSLRandomSeedconnect#Include该配置文件（mod_jk.conf）的内容如下表Table4-2#tomcat#JkLogFile#JkLogLevel#JkLogStampFormat"[%a%b%d%H:%M:%S%Y]JkOptionspat-#JkRequestLogFormat"%w%V##JkMount 拟概念，是指用于控制Tomcat节点分发的逻辑规则。该逻辑规则由上面所说的WpertiesTable4-2-2 #ajp tomcat#tomcat#ajp13 #server ertiesTable4-3Worker节点（根节点，唯一，指Apache本身Router节点（分发控制器，可以有多个，含有数个tomcat节点Tomcat节点（可以有多个，以Ip:Port地址定位worker,listroutertomcat由于tomcat节点依靠ip：port技术进行唯一标识，所以可以将多个tomcat（lbfactor）来控制各个节点之间的负载权重，以满足不同性能的节点。节点A在所有节点中的分发权重计算方法lbfactor/lbfactor*100%”。TerraCottaTerraCotta-3.4.1此处需要注意由于该版本TerraCotta源代码中不能识别带有空格的路径，TerraCottaTerraCottaTerraCotta节点的配置文件为tc-config.xml，可以命名，并放置在TerraCottaTerraCotta用是连接Tomcat和TerraCotta。其内容主要包括了TerraCotta本身应有的配置信息和用于连接Tomcat节点的第模块的位置及配置。ServersTable4-<!—serverserver设置各个ClientsTable4-该节点主要说明TerraCotta将加载怎样的第插件，以保证Tomcat节点能够向TerraCotta提交session内容并进行托管TerraCotta中的session是由客户端即Tomcat节点主动提交的TerraCotta在将session集中管理时会在session上标记来源节点的信息，因而这里不用配置tomcat节点方面的信息。也因为如此，TerraCotta可以在工作状态下，增加所的Tomcat节点数为了支持该插件，需要该插件tim-api-1.3.0.jar并拷贝至TerraCottalibTerraCottaTable4-6set该代码段中第二行，-f参数指定了配置文件tc-confign则指定了该服务器节点的名称。由于tc-config中可以定义多个TerraCotta的节点配置，因而这里的-n参数需要与tc-config.xml中<servername=’”>name属性匹配，以获取一个具体的TerraCottaTomcatTomcatAJPApacheApachesessionsessionTerraCotta因而，Tomcat首先要配置ajp定向包协议的端口和转发端口来接收请求并向ApacheterraCottaTerraCottaTerraCottasession。Tomcat其中Server.xml主要配置Tomcat作为jsp服务器时的各项配置信息,主要参数诸如解析方法文件 等等Context主要作为辅助内容，配置Tomcat运行的第环境，如插件等等首先要在Server.xml中配置Tomcat根据定向包协议接受来自Apache的请求。AJP定向包协议中的转发对象是按照ip:port地址来确定的，因而每个tomcat除了其运行机本身具有一个ip地址外，还需要配置特定的接受和返回端AJPServer.xml<service>下配置信息。这里的port属性一定要与Apache配置中worker.router.tomcat节点的port属性一致，而该节点的ip也一定要和Apache配置文件perties中的worker.router.romcat节点的host属性一致，即采用相对固定的内网ip地址。从而形成一个稳定的ip：port其次，要在Context节点中配置TerraCotta的运行环境，并指明其用于session管理的服务端口。代码如下，其中提到的className是实现该功能所TerraCottaTable4-8 tcConfigUrl="localhost:9510"/>因此，还要为Tomcat提供用于与TerraCotta进行通讯的插件包terracotta-session-terracotta-toolkit-1.1-runtime-这些插件包后，要放在Tomcat 的lib文件夹下，TomcatTerraCotta4.4系统的启动方式与错误处由于Apache2.2.3中的分发器是Apache完成的，而Tomcat启动时又需要加载TerraCotta的模块并从TerraCotta节点处获取配置信息因而三者启动TerraCotta、Tomcat、Apache.上面的实例中，Apache、TerraCotta均安装在本机，而Tomcat安装在两台机器TerraCottaTerraCotta下表Table4-9是在TerraCotta 下cmd中的启动命令 Bin/serviceinstallservice_name (将tomcat为服务，service_name为服务名)Netstart Tomcat在Tomcat根 下命令行启动命令如下表Table4-10所示第三步：启动Apache负载均衡服务器节点。在Apache 下cmd中的启动命令如下表Table4-11所Bin/serviceinstall Netstart (Apacheservice名字要与上文所定一致TerraCotta4.5TerraCottaTerraCottatc-start.bat4.6TerraCotta这是由于在tc-config.xml中定义的不同TerraCotta镜像之间共用了同一个日志。而这些日志资源是不可共享的，在TerraCottaTomcat图 Tomcat常见错TerraCotta 下找到/bin/tc-config.xml文件。这需要在Tomcat根startUp.batApacheHttpd时可以，并返回静态页面Itworks！JSP404503TomcatApacheTomcatApache够按照其的节点列表到所有节点，并认为该节点故障，从而放弃向该第六章集群式Web系统请求处理的优对于存在大量重复数据的Web系统而言，一个重要的情况就是服务器与数据库之间的信息存取可能成为新的瓶颈。第二章已经论证了客户请求往往同时满足时间范围、数据范围上的Zipf-like分布，服务器的最的状况应该是再短时间对少量资源的大量。这一瓶颈在数据采用海量分布式时，这一瓶颈可能会表现得尤为明显。web应对重复数据的基本策将用户请求精确的分解为记录级别的数据库信息并做“并集运算”，将是每个a)中所说的单元，都必须具有一个的资源标现行的#RESTweb会对的数据库开发提出新的要求。经请求分析整合的系统如图5.1,经过分析整合的系统如图5.2,很明显，经过请求分析处理，省去了重复的数据库资源请求，数据库所承受的资源请求数量明显减少。5.2对现有系统的改进方在4.1中论证了对数据请求进行分析的必要性，但这一分析工作必须由专门的分析组件部署于系统的某个位置完成。在本节中比较几个分析组件将数据库资源的结构直接给用户，造成了数据的不安全导致C\S方案二：webweba）加大web服务器集群的计算量，或者说，也许需要一个新的集群。c）WebDB方案三：DB据安全。因为这种方案不会将资源地址给用户综合而言，在方案二、三之间进行折中可能产生一个更好的方案(图5.3)即部分的请求分析放在web服务器层，这些请求将被分解为数据对象级别，而数据库根据情况将这些请求继续分解为记录级别的请求，并返回完整的数据集合到web服务器。这种方案可能有助于在数据的分布呈现zipf-like分布的前提下改善的缓存性能。在下一个部分进行。WEB服务器集群以及客户端之间的网络负载问网络负载方面，主要的瓶颈应该位于web服务器集群和客户端之间。降低5.3派生数据指由基本数据计算组合生成的新数据。这意味着要将计算任务HttpWebHttpWeb服务提供商的模式问题，派生数据的概念对于现行的绝大部分HttpWeb服的。因为这将浪费许多客户端资源和计算能力。适当地为某一类客户端开发相应的客户端程序将是有利的，也并不违背安全性原则。这是一个非常有效而成方案。因为GIS系统中数据的在数据范围上zipf-like并良好的客户端的缓存方案将有效地降低客户端与web服务器端的网络负载。当然，这个方案的前提是用户并不要求的动态数据。否则，频繁的缓降低web服务器和数据库的响应时间的方值得注意的是不应该因为过分强调响应时间而牺牲必要的计算。因为webwebweb可能在绝大部分时候都是闲置的。而相比之下数据库服务器则可能要承担数据更新和的工作。所以，将计算工作放置在web服务器层面可能是一种比较好的选择。同时，这将使得拥有、更灵活的方式为用户反映所请求的数据。这个优势在业务逻辑不断扩展的情况下，将逐渐显出优势。因为这个方web多级缓存技术的，是通过适当地部署、调度位于各级web服务器和客是降低了服务器的响应时间和响应成本。但这一方案的前提是，zipf-like峰值期间用户海量的只是数量上的增加，但集中度较高。多级缓存的技术，主要有两种模式，三级缓存、反向缓三级缓存是指在客户端、web服务器和数据服务器各一个缓存。客户端webweb存主要是根据zipf-like分布确定的频度最高的数据。三级缓存最适用于对数据的范围较为广泛，即数据范围上zipf-likeWeb而反向缓存是基于反向技术的多级分布式缓存。反向是指以服务器来接受网络上的连接请求，然后将请求转发给网络上的服务器，并将从服务器上得到的结果返回给网络上请求连接的客户端，此时服务器对外就表现为一个服务器。所谓反向缓存，就是将WEB服务器上的缓存或者通过某种算法同步调度到扮演服务器的服务器上。这样，就实现了缓存的分布式和。反向缓存可以极大地提高Web系统的响应时间，但却难以进行缓存之间的同步、调度以及。因而适用于zipf-likeWebzipf-likeWeb利用布隆过滤器减少无效在进行了信息定位的前提下，可以对来自客户端的数据请求进行验证，当数据库服务器在分布式数据库中进行轮询的时候，不用每一个器，以 图5.4以布隆过滤器无效请隆过滤器的特点，可以很容易地将布隆过滤器与硬件相结合，而DB服务器的时间复杂度的增加。具体实现方案如图图5-4。而“信息”和“应用”给服务器以及服务器集群带来的同时，决的根本问题之一。因而，无效信息的快速判定和删除是现代Web系统必须考虑在负载和信息过量问题的同时，仍有大量信息仍必须持久化在设备中。由于海量信息通过云的形式给用户，而用户可能产生大量重复的，这些重复的如果直接由Web网络抵达数据设备必将导致对设备的大量。而超大容量的系统受限于物理原因，不可避免的存在性能问题，并势必成为网络性能的瓶颈所在。因而，通过合理地优化网络服务以减少底 设备的次数，也是一个优秀的Web系统所必备的。第七章总在Web2.0导致的“信息”和Web3.0导致的“应用”面前，由大量客户端、WebC/S进发展。而由P2P和分布式计算发端的云和云计算将很好地解决服务器能现行最广泛流行的Web服务体系结构为基础，依次了上述几个问题，并对现有的Web服务体系提出相应的改进方案。这些改进方案都从Web系统的达到逐步改进现有Web系统的目的。这些方案没有考虑商业应用的成本问题，无论网络结构如何发展，Web服务器作为服务的和数据的根本来源，都必须负载均衡和恢复的问题。第三章中着重了在传统Web服务模式下负载均衡的方案和恢复的措施。并在呈zipf-like分布的情况下可以确定的是，将大量的计算机和客户端纳入云范围，通过高性能的网络算法合理分配、利用其计算能力是是在必行的，同时也将带来海量信息的充分共享，进而互联网的计算、潜力。而为了达到海量信息的有效共享，必须对现有的互联网信息进行有效、完善、可扩展的元数据封装；为了提高海量信息的效率，必须有一套行之有效的互联网资源。而且，这一应该与信息的元数据封装相结合。第五章中，结合ss布隆滤器（BloomFilter）和REST对信息封装和做了较为详细的介绍。Web式，在不断改进中继续发挥作用，并应对海量的数据。为了应对这一挑参考文VipinKumar,DouglasChubb,GregTurner,ShashiShekhar,SivakumarRavada,SivakumarRavada.DeclusteringandLoad-BalancingMethodsForParallelizingWebSystem[J/OL] HVJagadish. Linearclusteringofobjectswithmultipleattributes[J/OL]，，，.数字地球中影像数据的Zipf_like分布及应用分析[N].大学报-信息科学版2010-3NO.3.DanyelFisher.HowWeWatchtheCity:PopularityandOnlineMaps[J/OL]Researchpdf2007-SingleHTMLVersionofProductation15-，谢长生.对象系统的合作缓存方案[J].华技大学学报(信息科学版).2008(11),NO.11.，朱欣焰，，.WebGIS空间数据的分布式缓存[N]大学学报-信息科学版2005-12Vol.30No.12. ApacheHttpServer 2008.ApacheTheApacheTomcatConnector-AJPProtocol2011-Apache.Tomcat6.0DocsAnd2006-曾武，，地理信息系统中的集群缓存华技大学学报(自然科学版),2009-9,Vol.37No.9.GibsonG,Gorbett PNFSProblemStatement[R]RFC3668R. UpgradingtoTLSWithinRFC-28172000-5.,,.Namenode单点故障解决方案研究[J].计算机工程,2012,38(21):40-44.赵鑫,,,等.共享式Web应用服务器集群的资源整合方法研究[J].计算机科学与探索,2013,7(1):25-34.[J].大学学报(信息科学版,2013,38(9).时磊,,王红梅,等.基于布隆过滤器的事务架构中的高速缓[J].微电子学与计算机,2011,28(3):141-笱,,单征,等.基于计数布隆过滤器的负载均衡算法[J].计算机工程,2010,36(17):111-113,116.,萱,张永平,等.一种基于内容的数据分发网络及算法[J].计算机科学,2013,40(4):64-68.,时勘,,等.基于突发事件集群行为感知实验杂志,2013,32(5):32-,张昱,汪晨,等.一种动态共享数据结构的并发控制分析方[J].中国科学技术大学学报,2011,41(2):164-LAAdamic,