《大型網站技術架構》讀書筆記四:瞬時響應之網站的高性能架構


此篇已收錄至《大型網站技術架構》讀書筆記系列目錄貼,點擊訪問該目錄可獲取更多內容。

一、網站性能測試

(1)性能測試指標:①響應時間;②並發數;③吞吐量;④性能計數器;

(2)性能測試方法:①性能測試;②負載測試;③壓力測試;④穩定性測試;

(3)性能優化策略:

  ①性能分析:檢查請求處理各個環節的日志,分析哪個環節響應時間不合理,檢查監控數據分析影響性能的因素;

  ②性能優化:Web前端優化,應用服務器優化,存儲服務器優化;

二、Web前端性能優化

(1)瀏覽器訪問優化:

  ①減少http請求:因為http是無狀態的,每次請求的開銷都比較昂貴(需要建立通信鏈路、進行數據傳輸,而服務器端對於每個http請求都需要啟動獨立的線程去處理);減少http的主要手段是合並CSS、合並JS、合並圖片(CSS精靈,利用偏移定位image);

  ②使用瀏覽器緩存:設置http頭中Cache-Control和Expires屬性;

  ③啟用壓縮:可以對html、css、js文件啟用Gzip壓縮,可以達到較高的壓縮效率,但是壓縮會對服務器及瀏覽器產生一定的壓力;

  ④CSS放頁面最上面,JS放頁面最下面:瀏覽器會在下載完全部CSS之后才開始對整個頁面進行渲染,因此最好將CSS放在頁面最上面;而瀏覽器在加載JS后會立即執行,有可能會阻塞整個頁面,造成頁面顯示緩慢,因此最好將JS放在頁面最下面;

  ⑤減少Cookie傳輸:一方面,太大的Cookie會嚴重影響數據傳輸;另一方面,對於某些靜態資源的訪問(如CSS、JS等)發送Cookie沒有意義;

(2)CDN加速:

  CDN(內容分發網絡)仍然是一個緩存,它將數據緩存在離用戶最近的地方,便於用戶以最快速度獲取數據。即所謂的“網絡訪問第一跳”,如下圖所示:

CDN

  CDN只將訪問頻度很高的熱點內容(例如:圖片、視頻、CSS、JS腳本等訪問頻度很高的內容)進行緩存,可以極大地加快用戶訪問速度,減少數據中心負載。

(3)反向代理:

  反向代理服務器位於網站機房,代理網站Web服務器接收Http請求,對請求進行轉發,如下圖所示:

  反向代理服務器具有以下功能:

  ①保護網站安全:任何來自Internet的請求都必須先經過代理服務器;

  ②通過配置緩存功能加速Web請求:減輕真實Web服務器的負載壓力;

  ③實現負載均衡:均衡地分發請求,平衡集群中各個服務器的負載壓力;

三、應用服務器性能優化

(1)分布式緩存:

PS:網站性能優化第一定律:優先考慮使用緩存優化性能。緩存是指將數據存儲在相對較高訪問速度的存儲介質中(如內存),以供系統進行快速處理響應用戶請求。

  ①緩存本質是一個內存Hash表,數據以(Key,Value)形式存儲在內存中。

  ②緩存主要用來存放那些讀寫比很高、很少變化的數據,如商品的類目信息、熱門商品信息等。這樣,應用程序讀取數據時,先到緩存中取,如緩存中沒有或失效,再到數據庫中取出,重新寫入緩存以供下一次訪問。因此,可以很好地改善系統性能,提高數據讀取速度,降低存儲訪問壓力

  ③分布式緩存架構:一方面是以以JBoss Cache為代表的互相通信派;另一方面是以Memcached為代表的互不通信派;

  JBoss Cache需要將緩存信息同步到集群中的所有機器,代價比較大;而Memcached采用一種集中式的緩存集群管理,緩存與應用分離部署,應用程序通過一致性Hash算法選擇緩存服務器遠程訪問緩存數據,緩存服務器之間互不通信,因而集群規模可以輕易地擴容,具有良好的伸縮性。

  Memcached由兩個核心組件組成:服務端(ms)和客戶端(mc),在一個memcached的查詢中,mc先通過計算key的hash值來確定kv對所處在的ms位置。當ms確定后,客戶端就會發送一個查詢請求給對應的ms,讓它來查找確切的數據。因為這之間沒有交互以及多播協議,所以 memcached交互帶給網絡的影響是最小化的。

(2)異步操作:

  ①使用消息隊列將調用異步化,可改善網站的擴展性,還可改善網站性能;

  ②消息隊列具有削峰的作用->將短時間高並發產生的事務消息存儲在消息隊列中,從而削平高峰期的並發事務;

PS:任何可以晚點做的事情都應該晚點再做。前提是:這個事兒確實可以晚點再做。

(3)使用集群:

  ①在高並發場景下,使用負載均衡技術為一個應用構建多台服務器組成的服務器集群;

  ②可以避免單一服務器因負載壓力過大而響應緩慢,使用戶請求具有更好的響應延遲特性

  ③負載均衡可以采用硬件設備,也可以采用軟件負載。商用硬件負載設備(例如出名的F5)成本通常較高(一台幾十萬上百萬很正常),所以在條件允許的情況下我們會采用軟負載,軟負載解決的兩個核心問題是:選誰、轉發,其中最著名的是LVS(Linux Virtual Server)。

PS:LVS是四層負載均衡,也就是說建立在OSI模型的第四層——傳輸層之上,傳輸層上有我們熟悉的TCP/UDP,LVS支持TCP/UDP的負載均衡。

LVS的轉發主要通過修改IP地址(NAT模式,分為源地址修改SNAT和目標地址修改DNAT)、修改目標MAC(DR模式)來實現。有關LVS的詳情請參考:http://www.importnew.com/11229.html

(4)代碼優化:

  ①多線程:使用多線程的原因:一是IO阻塞,二是多CPU,都是為了最大限度地利用CPU資源,提高系統吞吐能力,改善系統性能;

  ②資源復用:目的是減少開銷很大的系統資源的創建和銷毀,主要采用兩種模式實現:單例(Singleton)和對象池(Object Pool)。例如,在.NET開發中,經常使用到的線程池,數據庫連接池等,本質上都是對象池。

  ③數據結構:在不同場合合理使用恰當的數據結構,可以極大優化程序的性能。

  ④垃圾回收:理解垃圾回收機制有助於程序優化和參數調優,以及編寫內存安安全的代碼。這里主要針對Java(JVM)和C#(CLR)一類的具有GC(垃圾回收機制)的語言。

四、存儲性能優化

(1)機械硬盤 還是 固態硬盤?

  ①機械硬盤:通過馬達驅動磁頭臂,帶動磁頭到指定的磁盤位置訪問數據。它能夠實現快速順序讀寫,慢速隨機讀寫

  ②固態硬盤(又稱SSD):無機械裝置,數據存儲在可持久記憶的硅晶體上,因此可以像內存一樣快速隨機訪問

  在目前的網站應用中,大部分應用訪問數據都是隨機的,這種情況下SSD具有更好的性能表現,但是性價比有待提升(蠻貴的,么么嗒)。

(2)B+樹 vs LSM樹

  ①傳統關系型數據庫廣泛采用B+樹,B+樹是對數據排好序后再存儲,加快數據檢索速度。

PS:目前大多數DB多采用兩級索引的B+樹,樹的層次最多三層。因此可能需要5次磁盤訪問才能更新一條記錄(三次磁盤訪問獲得數據索引及行ID,一次數據文件讀操作,一次數據文件寫操作,終於知道數據庫操作有多麻煩多耗時了)

  ②NoSQL(例如:HBase)產品廣泛采用LSM樹:

  具體思想是:將對數據的修改增量保持在內存中,達到指定的大小限制后將這些修改操作批量寫入磁盤不過讀取的時候稍微麻煩,需要合並磁盤中歷史數據和內存中最近的修改操作,所以寫入性能大大提升,讀取時可能需要先看是否命中內存,否則需要訪問較多的磁盤文件。

  LSM樹的原理是:把一棵大樹拆分成N棵小樹,它首先寫入內存中,隨着小樹越來越大,內存中的小樹會被清除並寫入到磁盤中,磁盤中的樹定期可以做合並操作,合並成一棵大樹,以優化讀性能。

  LSM樹的優勢在於:在LSM樹上進行一次數據更新不需要磁盤訪問,在內存即可完成,速度遠快於B+樹。

五、學習總結

  對於網站的高性能架構這一章的閱讀,通過大牛的書籍我們學到了從三個主要方面的性能優化策略,雖然都是理論,而且還只是淺顯地說明,但是對於我們這些廣大的開發菜鳥來說,擴展知識面,了解一點優化策略不是一件壞事,我們可以從中注意到日常的代碼規范,如何寫出高效的代碼也是一件值得研究的事兒。在書中,看到了作者寫了這樣一句話,貼出來與各位正在學習途中的菜鳥們共享:“歸根結底,技術是為業務服務的,技術選型和架構決策依賴業務規划乃至企業戰略規划,離開業務發展的支撐和驅動,技術走不遠,甚至還會迷路”。出來實習了一年多,對這句話感慨頗多,也吃了很多的虧,在和客戶的溝通交流上也有了自己的一點感悟,所以貼出來與各位園友共勉。最后,希望作為菜鳥的我們,在技術這條路上能夠走得遠一些,迷路不重要,重要的是能夠迷途知返,么么嗒!再過一個多月,就要開始找工作了,希望在此期間能夠認真閱讀完自己的計划書單,加油!

參考文獻

(1)李智慧,《大型網站技術架構-核心原理與案例分析》,http://item.jd.com/11322972.html

(2)周言之,《Memcached詳解》,http://blog.csdn.net/zlb824/article/details/7466943

(3)百度百科,CDN,http://baike.baidu.com/view/8689800.htm

(4)王晨純,《Web基礎架構:負載均衡和LVS》,http://www.importnew.com/11229.html

(5)輝之光,《B樹、B-樹、B+樹》,http://www.cnblogs.com/oldhorse/archive/2009/11/16/1604009.html

(6)yanghuahui's blog,《LSM樹由來、設計思想以及應用到HBase的索引》,http://www.cnblogs.com/yanghuahui/p/3483754.html

本章思維導圖

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM