BACHELOR'SDEGREETHESISOFWUHANUNIVERSITYTheLoad-balancingAndMalfunctionRestoringWithTerraCotta Directedby鄭重本人呈交的，是在導(dǎo)師的指導(dǎo)下，獨(dú)立進(jìn)行研究工作所取得的成果，所有數(shù)據(jù)、資料真實(shí)可靠。盡我所知，除文中已經(jīng)注明的內(nèi)容外，本的研究成果不包含他人享有著作權(quán)的內(nèi)容。對本所涉及的研究工作做出貢獻(xiàn)的其他個人和集體，均已在文中以明確的方式標(biāo)明。本的知識歸屬于培養(yǎng)單位。本人簽名 日期 高并發(fā)條件下，WEB服務(wù)器集群著幾個重要的問題。第一是負(fù)載均衡問題，即如何將超大負(fù)載合理地分布在整個集群中；第二是單節(jié)點(diǎn)故障問WEB存在著多種聯(lián)系，在于單節(jié)點(diǎn)故障問題的技術(shù)與服務(wù)優(yōu)化。本文的主要目的，即通過基于表述性狀態(tài)轉(zhuǎn)移(REST)的服務(wù)器資源，TerraCotta本文在第一章簡述了WEB服務(wù)器集群在高并景下的主要問題，以及本文第二章總結(jié)了高并發(fā)情景下，WEB服務(wù)器單節(jié)點(diǎn)故障問題的影響以技術(shù)的基本原理及其與布隆過濾器技術(shù)的應(yīng)用結(jié)合。第四章分析了WEB服務(wù)器負(fù)載均衡及恢復(fù)策略。本文第五章詳細(xì)介紹了利用開源TerraCotta的WebSession管理功能進(jìn)行單節(jié)點(diǎn)故障的原理，并以Apache、Tomcat為例，結(jié)合TerraCotta提供了搭建具有負(fù)載均衡和單節(jié)點(diǎn)故障功能的集群服務(wù)器的方法及詳細(xì)配置步驟。第六章則分析對比了現(xiàn)行的資源，并利用資源，提出了在WebWeb：集群；負(fù)載均衡；單節(jié)點(diǎn)故 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簡 第三章負(fù)載均衡及恢復(fù)策 基于session的單節(jié)點(diǎn)故障方 第四章基于TerraCotta的單節(jié)點(diǎn)故障及實(shí) TerraCotta的故障方案原 第五章集群式Web系統(tǒng)請求處理的優(yōu) 第六章總 參考文 第一章緒論選題的背景及webDB（圖1.1。大量的終端通過負(fù)載均衡器了系統(tǒng)所提供的大量服務(wù)和信息。然而，隨著網(wǎng)絡(luò)硬件條件快速發(fā)展以及云概念的興起和成熟，應(yīng)用程序本身由客戶端向服務(wù)器的轉(zhuǎn)移、海量信息由客戶端向云的轉(zhuǎn)移也將。作為前者的例證，業(yè)界中已經(jīng)出現(xiàn)了眾多服務(wù)，又稱為SaaS（Software-service，獲得服務(wù)的形式，獲得的功能；而后者的現(xiàn)實(shí)例子，最典型的就是為了實(shí)P2P多不可忽視的影響，并對經(jīng)典的Web系統(tǒng)結(jié)構(gòu)提出了諸多方面的。本文將Web行改進(jìn)，并最終從理論上提出一個改良了的、能夠應(yīng)對上述的Web系統(tǒng)結(jié)高并發(fā)情景下WEB服務(wù)器集群的主要問WebC-S90WEBWEBWEB務(wù)器的承載能力，除了應(yīng)對的泛紅式以外，免于接受最嚴(yán)酷的負(fù)載能力考驗。然而，21世紀(jì)初，由于以“人人參與”為的Web2.0的興起，網(wǎng)絡(luò)信息的來源迅速擴(kuò)大，信息總?cè)萘块_始呈式增長，進(jìn)而帶來了信息的時代，這使得傳統(tǒng)的C-S體系由于服務(wù)器重負(fù)而難以維系，進(jìn)而產(chǎn)生了P2PWeb2.0，Web3.0成了“人人創(chuàng)造”，從而將“信息”變成了“應(yīng)用”，并完全模糊了應(yīng)用與服務(wù)之間的概念。開放平臺，API應(yīng)用開發(fā)等都是非zip-like提下，一個Web服務(wù)器可能在某個瞬間規(guī)模遠(yuǎn)超平時的海量，進(jìn)而導(dǎo)致服務(wù)器即服務(wù)體系的。2009年的“貼吧爆吧事件”作為典型的zip-like分布實(shí)例，無疑給Web運(yùn)營商的負(fù)載能力和恢復(fù)能力敲響了警鐘。綜上所述，經(jīng)典的集群式Web服務(wù)器以下三個顯而易見的問題：第二：單節(jié)點(diǎn)故障第二：Web本文的分析完全基于(圖1.1)Web第二章高并發(fā)情景下單節(jié)點(diǎn)故障問題的影響與處理技術(shù)簡在電子商務(wù)誕生之初，一浪高過一浪的高并發(fā)用戶就一直給著這個行這個領(lǐng)域爭雄的幾個巨頭間技術(shù)實(shí)力的象征性指標(biāo)。例如，Amazon圣誕節(jié)期間呈現(xiàn)zipf分布[1]的爆發(fā)式用戶而大規(guī)模擴(kuò)大服務(wù)器集群并開發(fā)相應(yīng)的并發(fā)處理技術(shù)，從而建立了最早的企業(yè)云“AmazonCloud”[6]。并以此為基礎(chǔ)，從眾多競爭對手中贏得了“圣誕購物，成長為互聯(lián)網(wǎng)零售業(yè)的巨頭。而實(shí)際上，互聯(lián)網(wǎng)用戶行為呈現(xiàn)zipf分布特點(diǎn)[2]早已成為公認(rèn)的事實(shí)，且已經(jīng)有很多為了應(yīng)對由此帶來的高并發(fā)的成熟解決方案。情景下的負(fù)載均面對爆發(fā)式用戶，互聯(lián)網(wǎng)應(yīng)用中服務(wù)器集群的負(fù)載均衡在更早的時候已經(jīng)成為Apache等組織的研究對象，并擁有大量成通用解決方案[3][4][24]。目前來說，負(fù)載均衡已經(jīng)不是處理高并發(fā)的瓶頸。為了在具情景下的數(shù)據(jù)庫并由于高并發(fā)帶來的數(shù)據(jù)庫的并發(fā)控制的重要性卻日益凸顯。雖然主要發(fā)控制之間似乎總是一對體，需要設(shè)計在數(shù)據(jù)安全和事務(wù)并發(fā)處理性情景下的“處理互聯(lián)除了瀏覽器端的展示外，在服務(wù)器端的程序歸屬于“處理”的范疇。一般來說“處理”可以分成“事務(wù)處理”（OLTP，OnLineTransactionProcess）和“分析處理”（OLAP，OnLineytics（unitACID一般來說，不具備ACID屬性的處理都可以稱之為OLAP，這不意味著OLAPOLTPOLAP作，需到強(qiáng)大的計算資源支持。OLTP和OLAP是評估“處理”的一個角在OLAP中，因為每個處理過程之間都是相對獨(dú)立的，不具有OLTP的都有不同的解決方案。而這樣的誤區(qū)造成相當(dāng)一部分電子商務(wù)從初期的低情景下的單節(jié)點(diǎn)故障及其影高并發(fā)情境下，單節(jié)點(diǎn)故障往往發(fā)生于用戶最為集中的節(jié)點(diǎn)上。由于現(xiàn)代服務(wù)器資源虛擬化技術(shù)的廣泛應(yīng)用，用戶的資源往往更為集中、最高的服務(wù)器節(jié)點(diǎn)，其節(jié)點(diǎn)的負(fù)載一般也比較高。再次情況下，如果其中一個節(jié)點(diǎn)發(fā)生故障，將會有大量的用戶請求和被分散到周圍節(jié)點(diǎn)上，而周障，也可能因為負(fù)載過高造成遲緩，導(dǎo)致用戶的重復(fù)請求和刷新動作，從因此，通過適當(dāng)?shù)募夹g(shù)，有效單節(jié)點(diǎn)故障，成為了該并發(fā)情景下Web情景下的用戶（ZipF）曲定律(Zipf’sLaw)與福定律(Bradford’sLaw)及洛卡定律(Lotka’sLaw)一起被稱為計量學(xué)在文獻(xiàn)分布領(lǐng)域中最重要的三大定律。定律的最初版本是一個文獻(xiàn)計量學(xué)基本定律。哈佛大學(xué)教G．K．（G．K．Zipf）1935年通過對文獻(xiàn)詞頻規(guī)律的研究，認(rèn)為：若把篇較長的文章中每個詞出現(xiàn)的頻次從高到低進(jìn)行遞減排列，其數(shù)量關(guān)系特征呈雙曲線分布。該定律應(yīng)用于檢索用的詞表的編制和檢索系統(tǒng)中文檔結(jié)從根本上講,定律可以表述為,在自然語言的語料庫里,一個單詞出現(xiàn)的頻率與它在頻率表里的成反比.所以,頻率最高的單詞出現(xiàn)的頻率22powerlawprobabilitydistributions物的參考。定律是一個實(shí)驗定律,而非理論定律.分布可以在很多現(xiàn)定律。例如，高并發(fā)情境下的用戶分布，也符合定律。可以1.絕大部分的，都是由少數(shù)活躍用戶產(chǎn)生的。例如，2009年的雅虎音樂數(shù)據(jù)挖掘結(jié)果發(fā)現(xiàn)，90%5%的用戶產(chǎn)生的。2.絕大部分的，都集中在少數(shù)服務(wù)器資源上。例如2003年戰(zhàn)80%附近。3.絕大部分的，都集中發(fā)生在某個較短時間內(nèi)。例如2010年的貼吧爆吧事件和2013年的“點(diǎn)”事件。情境下單節(jié)點(diǎn)故障隨著服務(wù)器制造技術(shù)和運(yùn)行技術(shù)的提升，大部分服務(wù)器在正常情況下都可以長期穩(wěn)定工作。大部分的服務(wù)器故障，都來自的爆發(fā)式增長。例如，熱點(diǎn)導(dǎo)致的“點(diǎn)”效應(yīng)，發(fā)生于2009年的著名的爆吧事件就是非常好的例子。由于社交網(wǎng)絡(luò)的多個意見用戶引導(dǎo)大量用戶在特定貼吧集中發(fā)帖，導(dǎo)致該貼吧所在的物理機(jī)負(fù)載過高最終異常，進(jìn)而造成了單節(jié)(snapshot)”，保留狀態(tài)、有助于恢復(fù)。這種虛擬服務(wù)器映像可以用來迅速配置新的服務(wù)器實(shí)例。越來越多的公司甚至開始提供虛擬服務(wù)器映像第三章基于表述性狀態(tài)轉(zhuǎn)移(REST)的服務(wù)器簡本章將簡要介紹現(xiàn)有的信息REST標(biāo)準(zhǔn)，其次介紹布隆過濾器以及其應(yīng)用情況。在第五章中將利用本章所介紹的技術(shù)Web服務(wù)的優(yōu)化。3.1信息的意信息的必要性，來自于Web2.0帶來的“信息”，海量信息大信息的檢索帶來了極大。一定程度的信息冗余可以提高檢索速度，但無規(guī)則地冗余和重復(fù)，使得大量內(nèi)容一致的信息元素為地在不同的資源單下，計算機(jī)和網(wǎng)絡(luò)不得不認(rèn)為具有不同標(biāo)識符或者的文件具有不同的內(nèi)容。因而，這種無規(guī)則的冗余和重復(fù)在信息總量有限的情況下，將使得云3.2布隆過濾器（Bloom布隆過濾器的提出是在于1970年,提出者是..布隆（BurtonBloom0/1布隆過濾器是為了有效應(yīng)對哈希函數(shù)的而。傳統(tǒng)的哈希函數(shù)判Hash圍內(nèi)，如果的位陣列長度為m個點(diǎn)，那么如果想將率降低到例如1%,m/1001%或者100倍或者更高的標(biāo)志位空間。3.2.1布隆過濾器簡介及應(yīng)用案由于分布式結(jié)構(gòu)中信息量越來越大，的速度仍然有可能降低，尤其是在存在大量無效的情況下，大量的無效可能導(dǎo)致服務(wù)器重復(fù)地檢索其內(nèi)容，從而導(dǎo)致有效請求無法得到及時響應(yīng)。因而，用非檢索的方式迅速判定請求是否有效，即請求的數(shù)據(jù)是否存在成為了無效請求的必要。哈希函數(shù)由于其極低的時間復(fù)雜度成為了這能的首選實(shí)現(xiàn)，即用一個位數(shù)組上。當(dāng)標(biāo)志位為1時，表示資源存在，并進(jìn)行檢索；當(dāng)標(biāo)志位為0時，哈希函數(shù)的最大問題是和為了控制率造成的空間浪費(fèi)。假設(shè)Hash函數(shù)是良好的，如果的位陣列長度為m個點(diǎn)，那么如果想將率降低到例如1%,m/100空間浪費(fèi)。在散列表只是標(biāo)志位時這種浪費(fèi)在比率上雖然達(dá)到900%，但由1（Bit）,因而浪費(fèi)在總量上仍不算明顯。但這個散列表經(jīng)常要進(jìn)行必要的擴(kuò)展，比如一部分用于信息檢索的信息以降低檢索圖2.1布隆過濾器 方案舉而布隆過濾器正是為了解決這一問題而產(chǎn)生的。其基本原理是將一個元素的關(guān)鍵字用K個哈希函數(shù)到散列表中的K個位上。當(dāng)這些位均為1時，則該元素存在，反之該元素不存在。哈希函數(shù)的本質(zhì)是不同的資源被到同一個標(biāo)志位，而在布隆過濾器中，當(dāng)不同的資源被到同一個標(biāo)志位時，解決的方法是將將標(biāo)志位置為1.這樣，即從根源上消滅了哈希算法的問題。從而不用為了降低率而擴(kuò)大散列表長度。3.2.2布隆過濾器的性質(zhì)與布隆過濾器無疑解放了散列表，從而使得散列表從實(shí)際上獲得了擴(kuò)展的可能。而布隆過濾器在用“同位相與”的方法解決哈希的同時，也帶來了的性質(zhì)，即假陽性可能（falsepositivepossible）和假不可能(falsenegativeimpossible)。假陽性可能（falsepositivepossible）是指在布隆過濾器中，可能出現(xiàn)假不可能（falsenegativeimpossible）則與假陽性不可能相反，即0表長度m和哈希函數(shù)個數(shù)K的適當(dāng)搭配而控制在極低的范圍內(nèi)。相對于解放散其中k表示哈希函數(shù)的個數(shù)，m表示散列表的長度，而n表示經(jīng)過布隆過濾布隆過濾器的操作是成功的，因為操作實(shí)際上就是將元素的所有標(biāo)志位設(shè)置為1。而當(dāng)某些標(biāo)志位已經(jīng)被置為1時，過濾器可以不用做出經(jīng)典的布隆過濾器是沒有刪除操作的，因為你否只有要刪除的元素到了該位。為了能解決布隆過濾器的刪除問題，許多隆過濾器中刪除的元素，從而利用反向布隆過濾器的“假不可能”性質(zhì)來對于會多次產(chǎn)生刪除的布隆過濾器，通過將散列表中的標(biāo)志位擴(kuò)展為s位來表示該位被多個元素。當(dāng)一個元素被刪除時，則從其每個標(biāo)志位單元中的s位中置1位為0。該方案避免了刪除可能造成的“假可能”（falsenegativeimpossible。與此同時，該方案雖然無法消除被刪除的元素存在誤m,n個元素和ks率p與m、k、snn正比，當(dāng)nn3.3REST簡RepresentationalStateTransfer用的設(shè)計和開發(fā)方式，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。REST出了一些設(shè)計概念和準(zhǔn)則：網(wǎng)絡(luò)上的所有事物都被抽象為資源每個資源對應(yīng)一個唯一的資源標(biāo)識（resource通過通用的連接器接口（genericconnectorinterface）對資源 不會改變資源標(biāo)識所有的操作都是無狀態(tài)的（staess）Required requiredapi_keystringapi_keymethodstringRequired requiredapi_keystringapi_keymethodstring stringsecretKey的一個MD5值,vstringAPIoptional stringResponse的格式,XMLJSONXMLREST技術(shù)在國內(nèi)著名的SNS社交人人網(wǎng)應(yīng)用開發(fā)中已經(jīng)成功的得以運(yùn)RESTURLURLRESTURL據(jù)資源的集合，并對其進(jìn)行操作，進(jìn)一步獲得自己所需要的資源。下面的REST人人網(wǎng)Rest數(shù)據(jù)服務(wù)器地址 2.2Rest第四章負(fù)載均衡及恢復(fù)策負(fù)載均衡與恢復(fù)是密不可分的兩個部分。恢復(fù)的方案，本質(zhì)上是以相互配合，一遍在故障發(fā)生時，最大限度地恢復(fù)和服務(wù)。在災(zāi)難恢復(fù)時，指的是除負(fù)載均衡服務(wù)器之外的服務(wù)器集群的負(fù)載均衡。LB負(fù)載均衡的產(chǎn)生及意由于網(wǎng)絡(luò)量的迅速增加，傳統(tǒng)的單一WEB服務(wù)器雖然性能不斷提升，但務(wù)集群，為用戶提供和數(shù)據(jù)服務(wù)，以降低單個服務(wù)器的壓力。負(fù)載均衡是指將網(wǎng)絡(luò)的負(fù)載以某種策略分發(fā)給集群內(nèi)的各個服務(wù)節(jié)點(diǎn)傳統(tǒng)負(fù)載均衡策Robin：務(wù)器，從1至N然后重新開始。此種均衡算法適合于服務(wù)器組中的所有服務(wù)器權(quán)重輪循均衡（WeightedRoundRobin：根據(jù)服務(wù)器的不同處理能力，給每個服務(wù)器分配不同的權(quán)值，使其能夠接受相應(yīng)權(quán)值數(shù)的服務(wù)請求。例如：服務(wù)器A1，B3，C6，則服務(wù)器A、B、C10%、30％、60％到的使用率，避免低性能的服務(wù)器負(fù)載過重。（Random：RandomTime：探測請求（例如，然后根據(jù)中各服務(wù)器對探測請求的最快響應(yīng)時間Connection到真正的負(fù)載均衡。最少連接數(shù)均衡算法對中需負(fù)載的每一臺服務(wù)器都有FTP。處理能力均衡：此種均衡算法將把服務(wù)請求分配給中處理負(fù)荷（根據(jù)CPUCPU）最輕的服務(wù)器，由于考慮到了服務(wù)器的處理能力及當(dāng)前網(wǎng)絡(luò)運(yùn)行狀況，所以此種均衡DNS（FlashDNSInternetHTTP、FTP的服務(wù)請求，客戶端一般都是通過解析來找到服務(wù)器確切的IP地址的。在此均衡算法下，分處在不同地理位置的負(fù)載均衡設(shè)備收到同一個客戶端的解析請求，并在同一時間內(nèi)把此解析成各自相對應(yīng)服務(wù)器的IP地址（即與IP）并返回給客戶端，則客戶端將以最先收到的解析IP地址來繼續(xù)請求服務(wù)，而忽略其它的IP地址Apachesessionsession,即會話的方式進(jìn)行sessionApacheSessionwebsessionsession然，在web服務(wù)器結(jié)點(diǎn)之間分配session的算法可以進(jìn)行改進(jìn)。這需要開發(fā)新的負(fù)載均衡。這個方案同時也無法保證對單結(jié)點(diǎn)故障的。盡管可以通處理性的單結(jié)點(diǎn)故障，但卻無法處理由物理原因?qū)е碌膯谓Y(jié)點(diǎn)故障。這對于一個一般的而言，也許并不起眼，用戶只需要重新登錄就可以開啟一個新的session，但對于一個無人值守GIS應(yīng)用終端而言，可能是性的。比如一個具有計數(shù)功能的公共交通指示牌，可能在維修到達(dá)前，都無法排除故障，即便其故障排除，其所的即時信息，也可能無法恢復(fù)。3.3單節(jié)點(diǎn)故障的概念及意服務(wù)器集群可能存在著性能和任務(wù)不同的服務(wù)器節(jié)點(diǎn)，而由于負(fù)載均衡策略的設(shè)置可能使得某些服務(wù)器節(jié)點(diǎn)在某些平衡策略允許的情況下超出自故障對需要長期session的Web應(yīng)用影響巨大因為session的丟失意味著用戶的上下文無法恢復(fù)。會話，即Session，其英文原意是“會話，”。在Web服務(wù)結(jié)構(gòu)中，會話即Session的含義是指用戶與服務(wù)器的一次交互的過程。從數(shù)據(jù)角度講，是一中。Session中的是跟用戶有關(guān)的一些數(shù)據(jù)，由Web應(yīng)用具體管理其中的內(nèi)因而可以說，服務(wù)器端可以通過Session知道用戶的狀態(tài)，因而，單節(jié)點(diǎn)故障屏Session基于session的單節(jié)點(diǎn)故障方完全session方案實(shí)現(xiàn)單節(jié)點(diǎn)故障這個方案從理論上而言，是在粘session方案的基礎(chǔ)上，為了實(shí)現(xiàn)單節(jié)點(diǎn)故nsession(n-1)session戶端之間發(fā)生。顯而易見這個方案在單結(jié)點(diǎn)故障方面非常有效，因為session的冗余非常高，除非整個集群停止服務(wù)，否則不會出現(xiàn)會話丟失不可恢復(fù)的情況。假設(shè)服務(wù)器集群有nmsession，而兩個節(jié)點(diǎn)間進(jìn)行一次單個sessiont,sessionsessiont0=(n-1)*tsession為t1(n-1)*t*m;部分session方案實(shí)現(xiàn)單節(jié)點(diǎn)故障由于session方案中，在所有的服務(wù)器節(jié)點(diǎn)上大量的session的同步非常且沒有必要，因而出現(xiàn)了部分session的方案，即將將服務(wù)器集群在邏輯上劃分為數(shù)個更小的集群，在這些小的集群采取session假設(shè)集群nSmsessions了msession更新所需要的時間為t2=(n/s-1)*tSession方案的缺陷和問session方案容易導(dǎo)致巨大集群的網(wǎng)絡(luò)負(fù)載，并增加了單節(jié)點(diǎn)故障session20000WEB20000session部分session方案對完全的session方案改進(jìn)了很多，但在將所sessionsession時，每個子集群為了有效單節(jié)點(diǎn)故障，必須維持一定的負(fù)載能力冗余，并且使子集群點(diǎn)的數(shù)量維持在一定水平，這仍然沒有解決session大量同時上述分析忽略了一個情況——這個系統(tǒng)可能是7*24式地有大量終端同時在運(yùn)行。這樣的情況下，系統(tǒng)的量將呈現(xiàn)不規(guī)律的（可能是時間上的 session故障期產(chǎn)生巨大的網(wǎng)絡(luò)負(fù)載，部分單節(jié)點(diǎn)可能導(dǎo)致的單結(jié)點(diǎn)故障。如果系統(tǒng)處于飽和狀態(tài)，幾次大范圍的session分發(fā)可能導(dǎo)致性的后無論是完全session還是部分session，都還是通過大量冗余的式來保證可恢復(fù)。而維持大量的session冗余，是因為負(fù)載均衡服務(wù)器控制請求轉(zhuǎn)發(fā)時，并不能夠有效地判斷session冗余到底存在于哪些節(jié)點(diǎn)上，因而只有通過提高session冗余來提高 第五章基于TerraCotta的單節(jié)點(diǎn)故障及實(shí)Terracotta集群技簡要介Terracotta是一款由Terracotta公司開發(fā)的著名開源Java集群平臺。Terracotta公司成立于2003年創(chuàng)始人AriZilka原本是 師，該產(chǎn)品于2006年左右趨于成熟。Terracotta在JVM與Java應(yīng)用之間實(shí)現(xiàn)了單機(jī)Java應(yīng)用向集群化應(yīng)用的無縫遷移使得用戶可以專注于商業(yè)邏輯的開發(fā)，由Terracotta負(fù)責(zé)實(shí)現(xiàn)高性能、高可用性、高穩(wěn)定性的企業(yè)級Java集群[5]。Terracotta平臺是一個基于JVM的集群解決方案，允許用戶在不修改代碼的情況下把單機(jī)Java應(yīng)用程序運(yùn)行在多JVM⑴實(shí)現(xiàn)單機(jī)Java⑵允許Java程序就像本地數(shù)據(jù)一樣集群共享數(shù)據(jù)，并且實(shí)現(xiàn)對共享數(shù)據(jù)的集群范圍內(nèi)的同步⑶提供給予網(wǎng)絡(luò)的虛擬內(nèi)存管理允許Java程序超過其內(nèi)存空（heap）⑷數(shù)據(jù)保存在服務(wù)器端，因此客戶端JVMJVM⑺服務(wù)器分片，實(shí)現(xiàn)服務(wù)器數(shù)據(jù)及數(shù)據(jù)吞吐量橫向擴(kuò)⑻通過JMX開放服務(wù)器信⑼提供可視化和管理界面，大大方便對整合集群的共享數(shù)據(jù)、性能數(shù)據(jù)、軟硬件指標(biāo)等的實(shí)施、調(diào)試、優(yōu)化Terracotta平臺DSO集群結(jié)構(gòu)如圖圖 Terracotta平臺DSO集群結(jié)構(gòu)圖TerracottaDSO平臺提供了一個穩(wěn)健、高效、高可用、易用、易管理的Java集群平臺Terracotta為了進(jìn)一步幫助J2EE開發(fā)充分利用其平臺提供的各項特性，針對Java開發(fā)常用的Java技術(shù)平臺提供了一系列快捷模（ExpressMode）的解決方案，包括Ehcache分布式緩存、Hibernate分布式二級緩存、WebSession集群、分布式JavaQuartz等等。Terracotta些特定的項目中甚至可以使用Terracotta來代替關(guān)系型數(shù)據(jù)庫。對于集群中的Java對象來說，使用關(guān)系型數(shù)據(jù)庫進(jìn)行持久化，對象必須要實(shí)現(xiàn)序列化，從獲得行序列化Terracotta就能夠在集群范圍內(nèi)對Java對象進(jìn)行高效率的持久化，Terracotta畢竟不是對象型數(shù)據(jù)SQLTerracotta的通用管理能力也有所欠缺，換句話說，Terracotta沒有提供通用的工具來管理其管理的Java對象。目前，在大多數(shù)使用Terracotta進(jìn)行數(shù)據(jù)的場合中，還是使用以關(guān)系型數(shù)據(jù)庫為主，Terracotta為輔的方式。比如，Terracotta使用高性能的分布式Terracotta中，客戶能嵌入一個無縫可調(diào)的實(shí)體中。簡單Ehcache標(biāo)準(zhǔn)接口的單服務(wù)器，轉(zhuǎn)變成多節(jié)點(diǎn)Terracotta緩解數(shù)據(jù)庫壓力、TerracottaTerracottaServer42.2：2.2的數(shù)據(jù)不會丟失。這種配置提供了一定的恢復(fù)（Failover）的能力，但是還是無法做到高可用性（HA2.3：2.3（mirroring：一般由兩臺或者多臺物理服務(wù)器互為鏡2.4：2.4雙機(jī)或者多機(jī)鏡像⑷服務(wù)器陣列分片模式（ServerArrayStri這是TerracottaFX系列產(chǎn)1G5臺服務(wù)器做分片，每一臺服務(wù)器可以2Terracotta服務(wù)器的負(fù)載均衡。這種數(shù)據(jù)分片的策略，也就是說哪個數(shù)據(jù)對象保存在哪個服務(wù)器上，對開發(fā)和實(shí)施人對共享數(shù)據(jù)和應(yīng)用系統(tǒng)中的數(shù)據(jù)算法進(jìn)行優(yōu)化也可以簡單地增加陣列分片為鏡像，讓多個鏡像再組陣列分片。這樣每個鏡像做到高可用性，多個鏡像2.5：圖2.5服務(wù)器陣列分片模式（ServerArrayStriTerracotta配置文TerracottaXMLsystem,serversclientsandapplication.每個部分都提供了一系列相關(guān)的配置選項。配置文件中有些變量值會被Terracotta2.3：表 Terracotta配置文件系統(tǒng)替代變IP%（系統(tǒng)屬性名稱system部分、serversclients部分三個部分的部分元素屬性/tc:tc-config/system/configuration-model元素指明配置相關(guān)信息是必須來自服務(wù)器還是每個Client都可能有本地化的配置，該屬性有'development'和'production'兩個值development模式中每個Client都可以有本地化的配置，Clients關(guān)信息，Client第一次連接服務(wù)器的時候會探測服務(wù)器的配置模式，如果是productionClient可以通過語句-Dtc.config=serverHost:dsoPort設(shè)置名為'tc.config'的系統(tǒng)屬性來指定配置信息的來源。默認(rèn)的模式是development。Terracotta服務(wù)器，可以定義一個或者多個服務(wù)器實(shí)行為每一個Terracotta服務(wù)器都需要知道其配置文件的來源如果一臺Terracotta啟動時則必須在命令行下通過-nname指定Terracotta⑴/tc:tc-配置文件中一個server段封裝了一個Terracotta服務(wù)器實(shí)例的配置信息，server元素有三個可選屬性，默認(rèn)情況下，若用戶省略host、name、bind屬性的host值為%i即主機(jī)名稱，name值為%i:dso-port即“主機(jī)名稱：dsobind<server<serverhost="myotherhostname"name="server1"表 server元素的三個可選屬值托管Terracotta服務(wù)器的主機(jī)ID主機(jī)的IP主機(jī)的IPTerracotta服務(wù)器的ID，可被用在啟動Terracotta服的-nTerracottaClient的網(wǎng)絡(luò)接口，接口的IP/tc:tc-config/servers/server/data與/tc:tc-data和logs元素分別指定了Terracotta服務(wù)器的數(shù)據(jù)和日志的位置。值得注意的是stderr:或stdout也可作為配置文件中l(wèi)ogs元素的值。⑶/tc:tc-該部分指明了服務(wù)器集群的active-passive群內(nèi)所有的服務(wù)器都適用，這部分如果省略，集群內(nèi)的服務(wù)器會以disk-basedactive-passive模式運(yùn)行。/tc:tc-config/servers/ha/mode元素指定服務(wù)器以'disk-based-active-passive'還是'networked-active-passive模式運(yùn)行，默認(rèn)的是'disk-<serverhost="%i"<serverhost="%i"⑷/tc:tc- 使用mirrroup段綁定多組rrotta服務(wù)器實(shí)例到一個服務(wù)器集群陣總結(jié)了mirrroup包含的元素：表2.5 roups>包含元<mirr無<mirrgroup-name可以被賦給無無無該部分指定了Clients的配置相關(guān)信息/tc:tc-config/clients/logs指定了Clients配置為類似client-logs-%h的值并在名為host1的主機(jī)上運(yùn)行客戶端，那么在該值被使用前將會被替換為client-logs-host1如果為/tc:tc-config/clients/logs指定的 ，那么該值會被解析為當(dāng)前使用Terracotta服務(wù)的客戶端的啟動 。默認(rèn)情況下/tc:tc-config/clients/logs的值是logs-%i即將日志信息在調(diào)用Terracotta服務(wù)的客戶端程序的運(yùn)行下的logs-%i下，其中%iIPstderr:stdout也可作為配置文件中l(wèi)ogs元素的值。TerraCotta的單節(jié)點(diǎn)故障方TerraCottaTerraCotta是一款由TerraCotta公司開發(fā)的著名開源Java集群JVMJavaJavaTerraCottaJavaTerraCotta公司目前在、歐洲、澳大利亞、等地有近百名員工，為TerraCotta商業(yè)用戶提供7x24技術(shù)支持、解決方案咨詢等服務(wù)。同時在TerraCotta開源產(chǎn)品之上提供適用于企業(yè)用戶的高端產(chǎn)品。TerraCotta公司在2009年收購了著名的Java開源緩存項目Ehcache以及Java任務(wù)調(diào)度項目Quartz。經(jīng)過對該項目的深度整合，TerraCotta推出了易用性更高的分布式緩存、分布式任務(wù)調(diào)度以及分布式WebSession等快捷解決方案，進(jìn)一步方便了 開發(fā)分布式Java應(yīng)用。TerraCottaJVMJavaWebTerraCottaJavaTerracotta的時候，TerracottaTerracottaCPUsessiontomcat化，既避免了對數(shù)據(jù)庫的依賴，又能達(dá)到負(fù)載均衡和恢復(fù)的效果。在對比TerracottaTomcat8TerraCottaSessionsessionTerraCotta并不是復(fù)雜平衡，它并不能替代典型的負(fù)載均衡諸如Apache等的作用，但其所提供的集群化策略，卻可以與經(jīng)典負(fù)載均衡相合，進(jìn)而實(shí)現(xiàn)更好的負(fù)載均衡和恢復(fù)功能。TerraCotta的故障方案原TerraCotta的故障方案是其WebSession功能組件的一部分，其主要特點(diǎn)是利用分布式內(nèi)存和javasessionSessionTomcatsessionTerraCottaTomcat節(jié)點(diǎn)之間Session以進(jìn)行會話恢復(fù)，而是將恢復(fù)session的任務(wù)交TerraCottasessionTerraCottasessionsession4.1TerraCottaTerraCotta與Apache、Tomcat的整合原ApacheApache是一款跨平臺的網(wǎng)頁服務(wù)器，由最初由伊利諾伊大學(xué)香檳分校的國家超級電腦應(yīng)用中心（NCSA）開發(fā)。在開源后，經(jīng)過Apache開源的Apache2.xNCSA子，成為一款全新的網(wǎng)頁服務(wù)器，在最多的時候，占有了全世界73%的網(wǎng)ApacheJSP因而往往在作為服務(wù)器時，需要Tomcat的支持。Apache的典型用途為作為JSP服務(wù)集群的負(fù)載均衡，其默認(rèn)端口為80，并支持定向包協(xié)議（ApacheJServProtocolAJP8009.這使Apache（HTML）服TomcatAJPTomcat是一款開源的jsp容器，其作用就是將JSP頁面編譯解析并返回給顯示層。Tomcat是Apache的Jakarta項目的一個子項目。由于其JSPTomcat在使用時，往往作為一項服務(wù)，在服務(wù)器系統(tǒng)內(nèi)，默認(rèn)的8080。Tomcat(ApacheJServProtocolAJP8009.AJPTomcatApache作為負(fù)載均衡服務(wù)器的頁服務(wù)器集群中。終終PDA設(shè)PC終移動終負(fù)載均衡服務(wù)AJP/1.3協(xié)TerraCotta服務(wù)Session集中管Web服務(wù)器及計算集數(shù)據(jù)庫集Figure:4-2具有TerraCotta功能sessoin管理功能的集群式Web服務(wù)圖4.2Apache轉(zhuǎn)發(fā)與TerraCotta單節(jié)點(diǎn)故障的基本原TerraCotta與Tomcat、Apache的整合及故障過TomcatjspWebApache，TerraCottaTomcatTomcat節(jié)點(diǎn)在啟動后將自己至TerraCotta服務(wù)器在接收到Session后，TomcatsessionTerraCottasessionTerraCotta在接收到Session后，將session按照tomcat節(jié)點(diǎn)的名稱進(jìn)行標(biāo)記，并加載至TerraCotta所的共享內(nèi)存中，并不斷檢查各個Tomcat節(jié)點(diǎn)的狀態(tài)。當(dāng)TerraCotta發(fā)現(xiàn)某個Tomcat節(jié)點(diǎn)停止服務(wù)后，按照用戶設(shè)置的恢復(fù)方案將把內(nèi)存中原本由該節(jié)點(diǎn)的Session給集群中其他節(jié)點(diǎn)或部分節(jié)點(diǎn)。從而實(shí)現(xiàn)的恢復(fù)。Apache在檢測到Tomcat節(jié)點(diǎn)失敗后，將向其他節(jié)點(diǎn)轉(zhuǎn)發(fā)用戶的請求，而此時，這些用戶已經(jīng)在TerraCotta處獲得了故障節(jié)點(diǎn)所的所有session.從而實(shí)現(xiàn)了故障。在某個tomcat節(jié)點(diǎn)向TerraCotta更新了故障節(jié)點(diǎn)的sessionTerraCotta將通知其余節(jié)點(diǎn)放棄該session，從而使得故障節(jié)點(diǎn)的Session被平均地分配在同時，TerraCotta還可以利用其Ehcache組件所提供的分布式緩存功能，提sessionTerraCotta與Apache、Tomcat整合的配置步4.3ApacheAJP/1.3TerraCottaSessionApacheApache-Httpd-jspApache本身是提供靜態(tài)頁面服務(wù)的服務(wù)器作為負(fù)載均衡服務(wù)器時，tomcatApache,所需要的功能模塊為mod_jk，也簡稱為JK，這是一款A(yù)pache用來連接后臺Tomcat的模塊，支持集群和負(fù)載均衡 的mod_jk.so文件并拷貝Apahce的 下配置jsp分發(fā)功能的語句應(yīng)該寫在Apache根 中，該文件結(jié)構(gòu)如下表Table4-1所示<IfModuleSSLRandomSeedstartupSSLRandomSeedconnect#Include該配置文件（mod_jk.conf）的內(nèi)容如下表Table4-2#tomcat#JkLogFile#JkLogLevel#JkLogStampFormat"[%a%b%d%H:%M:%S%Y]JkOptionspat-#JkRequestLogFormat"%w%V##JkMount 擬概念，是指用于控制Tomcat節(jié)點(diǎn)分發(fā)的邏輯規(guī)則。該邏輯規(guī)則由上面所說的WpertiesTable4-2-2 #ajp tomcat#tomcat#ajp13 #server ertiesTable4-3Worker節(jié)點(diǎn)（根節(jié)點(diǎn)，唯一，指Apache本身Router節(jié)點(diǎn)（分發(fā)控制器，可以有多個，含有數(shù)個tomcat節(jié)點(diǎn)Tomcat節(jié)點(diǎn)（可以有多個，以Ip:Port地址定位worker,listroutertomcat由于tomcat節(jié)點(diǎn)依靠ip：port技術(shù)進(jìn)行唯一標(biāo)識，所以可以將多個tomcat（lbfactor）來控制各個節(jié)點(diǎn)之間的負(fù)載權(quán)重，以滿足不同性能的節(jié)點(diǎn)。節(jié)點(diǎn)A在所有節(jié)點(diǎn)中的分發(fā)權(quán)重計算方法lbfactor/lbfactor*100%”。TerraCottaTerraCotta-3.4.1此處需要注意由于該版本TerraCotta源代碼中不能識別帶有空格的路徑，TerraCottaTerraCottaTerraCotta節(jié)點(diǎn)的配置文件為tc-config.xml，可以命名，并放置在TerraCottaTerraCotta用是連接Tomcat和TerraCotta。其內(nèi)容主要包括了TerraCotta本身應(yīng)有的配置信息和用于連接Tomcat節(jié)點(diǎn)的第模塊的位置及配置。ServersTable4-<!—serverserver設(shè)置各個ClientsTable4-該節(jié)點(diǎn)主要說明TerraCotta將加載怎樣的第插件，以保證Tomcat節(jié)點(diǎn)能夠向TerraCotta提交session內(nèi)容并進(jìn)行托管TerraCotta中的session是由客戶端即Tomcat節(jié)點(diǎn)主動提交的TerraCotta在將session集中管理時會在session上標(biāo)記來源節(jié)點(diǎn)的信息，因而這里不用配置tomcat節(jié)點(diǎn)方面的信息。也因為如此，TerraCotta可以在工作狀態(tài)下，增加所的Tomcat節(jié)點(diǎn)數(shù)為了支持該插件，需要該插件tim-api-1.3.0.jar并拷貝至TerraCottalibTerraCottaTable4-6set該代碼段中第二行，-f參數(shù)指定了配置文件tc-confign則指定了該服務(wù)器節(jié)點(diǎn)的名稱。由于tc-config中可以定義多個TerraCotta的節(jié)點(diǎn)配置，因而這里的-n參數(shù)需要與tc-config.xml中<servername=’”>name屬性匹配，以獲取一個具體的TerraCottaTomcatTomcatAJPApacheApachesessionsessionTerraCotta因而，Tomcat首先要配置ajp定向包協(xié)議的端口和轉(zhuǎn)發(fā)端口來接收請求并向ApacheterraCottaTerraCottaTerraCottasession。Tomcat其中Server.xml主要配置Tomcat作為jsp服務(wù)器時的各項配置信息,主要參數(shù)諸如解析方法文件 等等Context主要作為輔助內(nèi)容，配置Tomcat運(yùn)行的第環(huán)境，如插件等等首先要在Server.xml中配置Tomcat根據(jù)定向包協(xié)議接受來自Apache的請求。AJP定向包協(xié)議中的轉(zhuǎn)發(fā)對象是按照ip:port地址來確定的，因而每個tomcat除了其運(yùn)行機(jī)本身具有一個ip地址外，還需要配置特定的接受和返回端AJPServer.xml<service>下配置信息。這里的port屬性一定要與Apache配置中worker.router.tomcat節(jié)點(diǎn)的port屬性一致，而該節(jié)點(diǎn)的ip也一定要和Apache配置文件perties中的worker.router.romcat節(jié)點(diǎn)的host屬性一致，即采用相對固定的內(nèi)網(wǎng)ip地址。從而形成一個穩(wěn)定的ip：port其次，要在Context節(jié)點(diǎn)中配置TerraCotta的運(yùn)行環(huán)境，并指明其用于session管理的服務(wù)端口。代碼如下，其中提到的className是實(shí)現(xiàn)該功能所TerraCottaTable4-8 tcConfigUrl="localhost:9510"/>因此，還要為Tomcat提供用于與TerraCotta進(jìn)行通訊的插件包terracotta-session-terracotta-toolkit-1.1-runtime-這些插件包后，要放在Tomcat 的lib文件夾下，TomcatTerraCotta4.4系統(tǒng)的啟動方式與錯誤處由于Apache2.2.3中的分發(fā)器是Apache完成的，而Tomcat啟動時又需要加載TerraCotta的模塊并從TerraCotta節(jié)點(diǎn)處獲取配置信息因而三者啟動TerraCotta、Tomcat、Apache.上面的實(shí)例中，Apache、TerraCotta均安裝在本機(jī)，而Tomcat安裝在兩臺機(jī)器TerraCottaTerraCotta下表Table4-9是在TerraCotta 下cmd中的啟動命令 Bin/serviceinstallservice_name (將tomcat為服務(wù)，service_name為服務(wù)名)Netstart Tomcat在Tomcat根 下命令行啟動命令如下表Table4-10所示第三步：啟動Apache負(fù)載均衡服務(wù)器節(jié)點(diǎn)。在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時可以，并返回靜態(tài)頁面Itworks！JSP404503TomcatApacheTomcatApache夠按照其的節(jié)點(diǎn)列表到所有節(jié)點(diǎn)，并認(rèn)為該節(jié)點(diǎn)故障，從而放棄向該第六章集群式Web系統(tǒng)請求處理的優(yōu)對于存在大量重復(fù)數(shù)據(jù)的Web系統(tǒng)而言，一個重要的情況就是服務(wù)器與數(shù)據(jù)庫之間的信息存取可能成為新的瓶頸。第二章已經(jīng)論證了客戶請求往往同時滿足時間范圍、數(shù)據(jù)范圍上的Zipf-like分布，服務(wù)器的最的狀況應(yīng)該是再短時間對少量資源的大量。這一瓶頸在數(shù)據(jù)采用海量分布式時，這一瓶頸可能會表現(xiàn)得尤為明顯。web應(yīng)對重復(fù)數(shù)據(jù)的基本策將用戶請求精確的分解為記錄級別的數(shù)據(jù)庫信息并做“并集運(yùn)算”，將是每個a)中所說的單元，都必須具有一個的資源標(biāo)現(xiàn)行的#RESTweb會對的數(shù)據(jù)庫開發(fā)提出新的要求。經(jīng)請求分析整合的系統(tǒng)如圖5.1,經(jīng)過分析整合的系統(tǒng)如圖5.2,很明顯，經(jīng)過請求分析處理，省去了重復(fù)的數(shù)據(jù)庫資源請求，數(shù)據(jù)庫所承受的資源請求數(shù)量明顯減少。5.2對現(xiàn)有系統(tǒng)的改進(jìn)方在4.1中論證了對數(shù)據(jù)請求進(jìn)行分析的必要性，但這一分析工作必須由專門的分析組件部署于系統(tǒng)的某個位置完成。在本節(jié)中比較幾個分析組件將數(shù)據(jù)庫資源的結(jié)構(gòu)直接給用戶，造成了數(shù)據(jù)的不安全導(dǎo)致C\S方案二：webweba）加大web服務(wù)器集群的計算量，或者說，也許需要一個新的集群。c）WebDB方案三：DB據(jù)安全。因為這種方案不會將資源地址給用戶綜合而言，在方案二、三之間進(jìn)行折中可能產(chǎn)生一個更好的方案(圖5.3)即部分的請求分析放在web服務(wù)器層，這些請求將被分解為數(shù)據(jù)對象級別，而數(shù)據(jù)庫根據(jù)情況將這些請求繼續(xù)分解為記錄級別的請求，并返回完整的數(shù)據(jù)集合到web服務(wù)器。這種方案可能有助于在數(shù)據(jù)的分布呈現(xiàn)zipf-like分布的前提下改善的緩存性能。在下一個部分進(jìn)行。WEB服務(wù)器集群以及客戶端之間的網(wǎng)絡(luò)負(fù)載問網(wǎng)絡(luò)負(fù)載方面，主要的瓶頸應(yīng)該位于web服務(wù)器集群和客戶端之間。降低5.3派生數(shù)據(jù)指由基本數(shù)據(jù)計算組合生成的新數(shù)據(jù)。這意味著要將計算任務(wù)HttpWebHttpWeb服務(wù)提供商的模式問題，派生數(shù)據(jù)的概念對于現(xiàn)行的絕大部分HttpWeb服的。因為這將浪費(fèi)許多客戶端資源和計算能力。適當(dāng)?shù)貫槟骋活惪蛻舳碎_發(fā)相應(yīng)的客戶端程序?qū)⑹怯欣模膊⒉贿`背安全性原則。這是一個非常有效而成方案。因為GIS系統(tǒng)中數(shù)據(jù)的在數(shù)據(jù)范圍上zipf-like并良好的客戶端的緩存方案將有效地降低客戶端與web服務(wù)器端的網(wǎng)絡(luò)負(fù)載。當(dāng)然，這個方案的前提是用戶并不要求的動態(tài)數(shù)據(jù)。否則，頻繁的緩降低web服務(wù)器和數(shù)據(jù)庫的響應(yīng)時間的方值得注意的是不應(yīng)該因為過分強(qiáng)調(diào)響應(yīng)時間而犧牲必要的計算。因為webwebweb可能在絕大部分時候都是閑置的。而相比之下數(shù)據(jù)庫服務(wù)器則可能要承擔(dān)數(shù)據(jù)更新和的工作。所以，將計算工作放置在web服務(wù)器層面可能是一種比較好的選擇。同時，這將使得擁有、更靈活的方式為用戶反映所請求的數(shù)據(jù)。這個優(yōu)勢在業(yè)務(wù)邏輯不斷擴(kuò)展的情況下，將逐漸顯出優(yōu)勢。因為這個方web多級緩存技術(shù)的，是通過適當(dāng)?shù)夭渴稹⒄{(diào)度位于各級web服務(wù)器和客是降低了服務(wù)器的響應(yīng)時間和響應(yīng)成本。但這一方案的前提是，zipf-like峰值期間用戶海量的只是數(shù)量上的增加，但集中度較高。多級緩存的技術(shù)，主要有兩種模式，三級緩存、反向緩三級緩存是指在客戶端、web服務(wù)器和數(shù)據(jù)服務(wù)器各一個緩存。客戶端webweb存主要是根據(jù)zipf-like分布確定的頻度最高的數(shù)據(jù)。三級緩存最適用于對數(shù)據(jù)的范圍較為廣泛，即數(shù)據(jù)范圍上zipf-likeWeb而反向緩存是基于反向技術(shù)的多級分布式緩存。反向是指以服務(wù)器來接受網(wǎng)絡(luò)上的連接請求，然后將請求轉(zhuǎn)發(fā)給網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給網(wǎng)絡(luò)上請求連接的客戶端，此時服務(wù)器對外就表現(xiàn)為一個服務(wù)器。所謂反向緩存，就是將WEB服務(wù)器上的緩存或者通過某種算法同步調(diào)度到扮演服務(wù)器的服務(wù)器上。這樣，就實(shí)現(xiàn)了緩存的分布式和。反向緩存可以極大地提高Web系統(tǒng)的響應(yīng)時間，但卻難以進(jìn)行緩存之間的同步、調(diào)度以及。因而適用于zipf-likeWebzipf-likeWeb利用布隆過濾器減少無效在進(jìn)行了信息定位的前提下，可以對來自客戶端的數(shù)據(jù)請求進(jìn)行驗證，當(dāng)數(shù)據(jù)庫服務(wù)器在分布式數(shù)據(jù)庫中進(jìn)行輪詢的時候，不用每一個器，以 圖5.4以布隆過濾器無效請隆過濾器的特點(diǎn)，可以很容易地將布隆過濾器與硬件相結(jié)合，而DB服務(wù)器的時間復(fù)雜度的增加。具體實(shí)現(xiàn)方案如圖圖5-4。而“信息”和“應(yīng)用”給服務(wù)器以及服務(wù)器集群帶來的同時，決的根本問題之一。因而，無效信息的快速判定和刪除是現(xiàn)代Web系統(tǒng)必須考慮在負(fù)載和信息過量問題的同時，仍有大量信息仍必須持久化在設(shè)備中。由于海量信息通過云的形式給用戶，而用戶可能產(chǎn)生大量重復(fù)的，這些重復(fù)的如果直接由Web網(wǎng)絡(luò)抵達(dá)數(shù)據(jù)設(shè)備必將導(dǎo)致對設(shè)備的大量。而超大容量的系統(tǒng)受限于物理原因，不可避免的存在性能問題，并勢必成為網(wǎng)絡(luò)性能的瓶頸所在。因而，通過合理地優(yōu)化網(wǎng)絡(luò)服務(wù)以減少底 設(shè)備的次數(shù)，也是一個優(yōu)秀的Web系統(tǒng)所必備的。第七章總在Web2.0導(dǎo)致的“信息”和Web3.0導(dǎo)致的“應(yīng)用”面前，由大量客戶端、WebC/S進(jìn)發(fā)展。而由P2P和分布式計算發(fā)端的云和云計算將很好地解決服務(wù)器能現(xiàn)行最廣泛流行的Web服務(wù)體系結(jié)構(gòu)為基礎(chǔ)，依次了上述幾個問題，并對現(xiàn)有的Web服務(wù)體系提出相應(yīng)的改進(jìn)方案。這些改進(jìn)方案都從Web系統(tǒng)的達(dá)到逐步改進(jìn)現(xiàn)有Web系統(tǒng)的目的。這些方案沒有考慮商業(yè)應(yīng)用的成本問題，無論網(wǎng)絡(luò)結(jié)構(gòu)如何發(fā)展，Web服務(wù)器作為服務(wù)的和數(shù)據(jù)的根本來源，都必須負(fù)載均衡和恢復(fù)的問題。第三章中著重了在傳統(tǒng)Web服務(wù)模式下負(fù)載均衡的方案和恢復(fù)的措施。并在呈zipf-like分布的情況下可以確定的是，將大量的計算機(jī)和客戶端納入云范圍，通過高性能的網(wǎng)絡(luò)算法合理分配、利用其計算能力是是在必行的，同時也將帶來海量信息的充分共享，進(jìn)而互聯(lián)網(wǎng)的計算、潛力。而為了達(dá)到海量信息的有效共享，必須對現(xiàn)有的互聯(lián)網(wǎng)信息進(jìn)行有效、完善、可擴(kuò)展的元數(shù)據(jù)封裝；為了提高海量信息的效率，必須有一套行之有效的互聯(lián)網(wǎng)資源。而且，這一應(yīng)該與信息的元數(shù)據(jù)封裝相結(jié)合。第五章中，結(jié)合ss布隆濾器（BloomFilter）和REST對信息封裝和做了較為詳細(xì)的介紹。Web式，在不斷改進(jìn)中繼續(xù)發(fā)揮作用，并應(yīng)對海量的數(shù)據(jù)。為了應(yīng)對這一挑參考文VipinKumar,DouglasChubb,GregTurner,ShashiShekhar,SivakumarRavada,SivakumarRavada.DeclusteringandLoad-BalancingMethodsForParallelizingWebSystem[J/OL] HVJagadish. Linearclusteringofobjectswithmultipleattributes[J/OL]，，，.數(shù)字地球中影像數(shù)據(jù)的Zipf_like分布及應(yīng)用分析[N].大學(xué)報-信息科學(xué)版2010-3NO.3.DanyelFisher.HowWeWatchtheCity:PopularityandOnlineMaps[J/OL]Researchpdf2007-SingleHTMLVersionofProductation15-，謝長生.對象系統(tǒng)的合作緩存方案[J].華技大學(xué)學(xué)報(信息科學(xué)版).2008(11),NO.11.，朱欣焰，，.WebGIS空間數(shù)據(jù)的分布式緩存[N]大學(xué)學(xué)報-信息科學(xué)版2005-12Vol.30No.12. ApacheHttpServer 2008.ApacheTheApacheTomcatConnector-AJPProtocol2011-Apache.Tomcat6.0DocsAnd2006-曾武，，地理信息系統(tǒng)中的集群緩存華技大學(xué)學(xué)報(自然科學(xué)版),2009-9,Vol.37No.9.GibsonG,Gorbett PNFSProblemStatement[R]RFC3668R. UpgradingtoTLSWithinRFC-28172000-5.,,.Namenode單點(diǎn)故障解決方案研究[J].計算機(jī)工程,2012,38(21):40-44.趙鑫,,,等.共享式Web應(yīng)用服務(wù)器集群的資源整合方法研究[J].計算機(jī)科學(xué)與探索,2013,7(1):25-34.[J].大學(xué)學(xué)報(信息科學(xué)版,2013,38(9).時磊,,王紅梅,等.基于布隆過濾器的事務(wù)架構(gòu)中的高速緩[J].微電子學(xué)與計算機(jī),2011,28(3):141-笱,,單征,等.基于計數(shù)布隆過濾器的負(fù)載均衡算法[J].計算機(jī)工程,2010,36(17):111-113,116.,萱,張永平,等.一種基于內(nèi)容的數(shù)據(jù)分發(fā)網(wǎng)絡(luò)及算法[J].計算機(jī)科學(xué),2013,40(4):64-68.,時勘,,等.基于突發(fā)事件集群行為感知實(shí)驗雜志,2013,32(5):32-,張昱,汪晨,等.一種動態(tài)共享數(shù)據(jù)結(jié)構(gòu)的并發(fā)控制分析方[J].中國科學(xué)技術(shù)大學(xué)學(xué)報,2011,41(2):164-LAAdamic,