隨著cnbc.com（美國華爾街最大財(cái)經(jīng)網(wǎng)絡(luò)）日訪問量不斷大幅增長，我們發(fā)覺自己陷入了一個(gè)很多網(wǎng)站都再熟悉不過的艱難境地，網(wǎng)站運(yùn)行的各方面都被動(dòng)地發(fā)生了重大的變化，現(xiàn)狀堪憂。在硬件，存儲(chǔ)空間以及能源上的需求使我們不得不增設(shè)額外的服務(wù)器，延長本來毫無必要的響應(yīng)時(shí)間。我們甚至要依靠經(jīng)常性的微型緩存或類似手段才可勉強(qiáng)提高代碼性能……這些讓人不安和頭疼的問題一股腦地堆到了眼前，讓人想忽視都難。
    由于需要不斷革新產(chǎn)品才能保持網(wǎng)站競爭力，而開發(fā)資源又十分有限，因此即使code base(碼基)能被顯著改善，網(wǎng)站重構(gòu)的能力依然受到了限制。那么，要怎樣才可以提高網(wǎng)站性能并解決其它方面的需求問題，而又不至于要請出整個(gè)公司的專業(yè)團(tuán)隊(duì)夜以繼日地操勞呢？我們想到了一種卓越的網(wǎng)絡(luò)緩存應(yīng)用加速產(chǎn)品——aiCache！
    緩存作為一種技術(shù)，原理并不復(fù)雜。一般而言，一個(gè)站點(diǎn)為了對用戶請求生成響應(yīng)，必須使數(shù)據(jù)經(jīng)過“Apache-JK-Java-數(shù)據(jù)庫”一系列后端 處理環(huán)節(jié)(我們CNBC網(wǎng)站差不多可以說是一個(gè)Java“商場”了)。緩存設(shè)備就是在這個(gè)處理系統(tǒng)前端對網(wǎng)絡(luò)中的用戶請求進(jìn)行處理。當(dāng)然，“Apache-PHP-數(shù)據(jù)庫”等也可以看做是后端處理系統(tǒng)，它通過字節(jié)代碼與/或DB結(jié)果集緩存。以我們CNBC為例，以前，我們有很多其它的次級緩存系統(tǒng)，目的在于加快讀股票信息和與公司相關(guān)的信息。然而，要發(fā)展這么多的微型緩存并在系統(tǒng)上保持全部的微型緩存并非易事，也解決不了多大問題。幸好，aiCache讓我們又回到了正軌。
   aiCache基本意旨在于在服務(wù)器前端通過緩存處理網(wǎng)絡(luò)中的用戶流量，并將你的整個(gè)網(wǎng)絡(luò)環(huán)境提升到一個(gè)新的層次。我們不認(rèn)為aiCache本質(zhì)性能就是革新的，寧可相信是由于其功能之全面解決了每個(gè)您能想到的問題。
    我們還發(fā)現(xiàn)，aiCache實(shí)際上的性能潛力是可以無限挖掘的！它提供難以置信的配置靈活性，還支持實(shí)時(shí)報(bào)告和警報(bào)機(jī)制。
    就存儲(chǔ)空間的問題，我們在下面不分先后地羅列了一些使用該產(chǎn)品的經(jīng)驗(yàn):
    aiCache可在任何Linux發(fā)行版本上運(yùn)行，我們的情況正好是安裝了RedHat 5的64位惠普機(jī)DL360G5。
    響應(yīng)被緩存在 RAM 中，而非磁盤上。不存在磁盤IO (訪問日志和錯(cuò)誤日志的情況除外，但它們是可配置的)。而且，緩存響應(yīng)不存在延遲——壓力測試表明TTFB為零毫秒。另外，資源使用率極低——裝有 aiCache的服務(wù)器可每秒處理超過2000次的請求卻依然還有99%是閑置。抱著懷疑的態(tài)度，我將壓力測試定為每臺(tái)服務(wù)器每秒處理25,000次請求 ——可此時(shí)的負(fù)載量才占2%。這進(jìn)一步證實(shí)了aiCache生產(chǎn)廠商所作出的承諾絕非虛假。
    我們對 GET 和 POST請求都進(jìn)行了緩存，使用了查詢參數(shù)丟棄 (即有選擇性地刪除那些增加緩存復(fù)雜性的半隨意參數(shù))。
    當(dāng)用戶提交新的評論后，我們使用響應(yīng)驅(qū)動(dòng)終止機(jī)制來更新討論區(qū)內(nèi)容。
我們有機(jī)會(huì)使用到了網(wǎng)站“管理后備模式” (在這種機(jī)制下aiCache以先前緩存好的響應(yīng)對用戶做出回答，服務(wù)器不受任何請求干擾)，以加速服務(wù)器從癱瘓狀態(tài)恢復(fù)正常服務(wù)。
我們還多次通過標(biāo)記原始服務(wù)器的功能避免代碼出錯(cuò)的情況。
    從我們十個(gè)不同的分站來看，aiCache的平均緩存率達(dá)80%，其中一些站點(diǎn)的緩存命中率甚至高達(dá)97%。在大幅減少了服務(wù)器集群的數(shù)量以及原始服務(wù)器所需面對的網(wǎng)絡(luò)流量之后，我們甚至還發(fā)現(xiàn)整個(gè)web，數(shù)據(jù)庫和其它后端系統(tǒng)的資源使用率都得到了降低。
    Keynote報(bào)告指出響應(yīng)時(shí)間將近大幅度降低了30%。
    每個(gè)人都愛上了實(shí)時(shí)流量報(bào)告。這是在公司許多計(jì)算機(jī)上的一個(gè)標(biāo)準(zhǔn)化窗口，你可以從這個(gè)窗口了解到每個(gè)加速站點(diǎn)的每秒請求次數(shù)，響應(yīng)時(shí)間，正常工作與出現(xiàn)問題的服務(wù)器數(shù)量，客戶端與服務(wù)器連接數(shù)量， BW 輸入輸出值等等。
    我們將Nagios與服務(wù)器連接，以通過SNMP 對aiCache的一些綜合資料進(jìn)行讀取和制表，它可以把你能想到的任何事情作為一個(gè)對象標(biāo)示符。
    我也非常喜歡它們的CLI 界面：你可以看到響應(yīng)數(shù)的總量，做出任何回應(yīng)，終止響應(yīng)，以請求內(nèi)容，大小，完成時(shí)間，更新次數(shù)等不同方式實(shí)時(shí)查看響應(yīng)。無需再進(jìn)行日志分析。由于有一些命令是成群發(fā)出的，所以你只需在一個(gè)節(jié)點(diǎn)操作它們，它們會(huì)照葫蘆畫瓢，全部聽令。
    同樣，以上的窗體中只羅列了我們這家公司所使用的功能，只占了aiCache全部功能中的一小部分。要知道，aiCache的用戶手冊可多達(dá)四十頁呢！里面恰好全是我所喜歡的核心技術(shù)內(nèi)容。
    下面，再談?wù)勎覀兙W(wǎng)絡(luò)裝置的細(xì)節(jié)。我們使用了F5負(fù)載均衡器，并將虛擬IP配置為可供多臺(tái)aiCache服務(wù)器和原始服務(wù)器同時(shí)使用。即在最前邊用 F5負(fù)載平衡設(shè)備，下邊的有多個(gè)aiCache服務(wù)器和原始服務(wù)器。通過使用F5的VIP機(jī)制，只要有一臺(tái)aiCache服務(wù)器可以正常運(yùn)行，我們就將所有的網(wǎng)絡(luò)流量都交給它們處理，而讓原始服務(wù)器自動(dòng)或按需的失效備緩所有網(wǎng)絡(luò)流量。
    我們也使用著名的CDN技術(shù)來服務(wù)各種輔助內(nèi)容，如Javascript，CSS和鏡像。
    我通過網(wǎng)站上一個(gè)維基百科的鏈接嘗試進(jìn)行下載。由于aiCache中已經(jīng)對這個(gè)內(nèi)容進(jìn)行了緩存，使得這個(gè)請求執(zhí)行得非常迅速，讓這我大吃一驚�；叵氪蠹s在2000年時(shí)，我們使用 Novell公司的 ICS。但是要搞清楚什么樣的URL可以被緩存，可以緩存多長時(shí)間真是一種煎熬。這樣的經(jīng)驗(yàn)更使得我們對aiCache的出現(xiàn)眼前一亮。
最后提一句，當(dāng)你打算對aiCache進(jìn)行壓力測試時(shí)，請使用您自己的服務(wù)器測試。否則，你極有可能毀了一臺(tái)或更多的網(wǎng)絡(luò)設(shè)備組件！
   
作者：Rashid Karimov，電子工程師，自1992年就在網(wǎng)絡(luò)設(shè)備領(lǐng)域工作，以前是俄國internet服務(wù)提供者，現(xiàn)在為像CNBC和NBC （cnbc.com, NBC奧運(yùn)網(wǎng)站及其它）這樣的大型繁忙網(wǎng)站設(shè)計(jì)和運(yùn)行網(wǎng)絡(luò)設(shè)備。文章譯自http://highscalability.com/serving-250m-quotes-day-cnbc-com-aicache

標(biāo)簽： linux 標(biāo)準(zhǔn) 代碼 服務(wù)器 美國 數(shù)據(jù)庫 網(wǎng)絡(luò) 網(wǎng)站 問題 選擇 用戶

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。