高性能架構

 

1、不一樣視角下的網站性能。

1. 　　用戶視角：就是用戶在瀏覽器上直觀感覺的網站響應速度快仍是慢。
2. 　　開發視角：應用程序自己及其子系統的性能，包括響應延遲、系統吞吐量、併發處理能力、系統穩定性等技術指標。
3. 　　運維視角：基礎設施性能和資源利用率。

2、相對應的優化手段。

1. 　　前端架構優化手段（使瀏覽器儘快的顯示用戶感興趣的內容、儘量近的獲取頁面內容）：
1. 　　優化HTML頁面樣式。　　
2.  　　利用瀏覽器端的併發和異步特性。
3. 　　調整瀏覽器緩存策略。
4. 　　使用CDN服務。
5. 　　反向代理等。 
2. 　　後端架構優化手段：
   1. 　　使用緩存加速數據讀取。
   2. 　　使用集羣提升吞吐能力。
   3. 　　使用異步消息加快請求響應及實現削峯。
   4. 　　使用代碼優化手段改善程序性能。
3. 　　服務器優化手段：
   1. 　　建設優化骨幹網。
   2. 　　使用高性價比定製服務器。
   3. 　　利用虛擬化技術優化資源。

三，經常使用的系統操做響應時間。（僅供參考）

操做	響應時間
L1緩存	1ns
分支錯誤	3ns
二級緩存	4ns
互斥鎖/解鎖	17ns
壓縮1KB的Zippy	2,000ns≈2μs
經過商品網絡發送2,000字節	88ns
SSD隨機讀取	16,000ns≈16μs
從存儲器中順序讀取1,000,000字節	5,000ns≈5μs
往返於同一數據中心	500,000ns≈500μs
從SSD中順序讀取1,000,000字節	78,000ns≈78μs
磁盤查找	3,000,000ns≈3ms
從磁盤順序讀取1,000,000字節	1,000,000ns≈1ms
將數據包往返於荷蘭	150,000,000ns≈150ms
從遠程分佈式緩存Redis讀取一個數據	0.5ms
機械磁盤一次尋址定位	4ms
在數據庫中查詢一條記錄（有索引）	十幾ms
打開一個網站	幾秒

https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html

 

4、吞吐量

　　指單位時間內系統處理的請求數量，體現系統的總體處理能力。

　　TPS：（每秒事務數）是吞吐量的一個經常使用量化指標。

　　HPS：（每秒HTTP請求數）。

　　QPS：（每秒查詢數）。

 

5、性能測試方法

　　性能測試、負載測試、壓力測試、穩定性測試。

　　測試目標：一、系統的最大負載點。二、系統的崩潰點。

 

6、性能分析

　　排查一個網站或者程序瓶頸的手法基本相同：檢查請求處理的各個環節的日誌，分析哪一個環節響應時間不合理、超過預期；而後檢查監控數據，分析影響性能的主要因素是內存、磁盤、網絡仍是CPU，

　　　　是代碼問題仍是架構設計不合理，或者系統資源確實不足。

 

7、優化方案：

　　一、Web前端性能優化

　　一：瀏覽器訪問優化　

• 減小http請求　　 　　HTTP協議是無狀態的應用層協議，意味着每次HTTP請求都須要創建通訊鏈路、進行數據傳輸，而在服務器端，每一個HTTP都須要啓動獨立的線程去處理。這些通訊和服務的開銷都很昂貴，減小HTTP請求的數目可有效的提升訪問性能。 　 eg:：合併CSS、合併JavaScript、合併圖片等。
• 使用瀏覽器緩存 　　對一個網站而言，css、js、logo等靜態資源文件更新頻率比較低，而這些文件又是每次HTTP請求都須要的，若是緩存在瀏覽器上，能夠極好的改善性能。 　　eg：經過設置HTTP頭中的Cache-Control和Expires屬性，可設置瀏覽器緩存，時間能夠是幾天or幾個月。 　　使用瀏覽器緩存策略的網站在更新靜態資源時，應採用逐量更新 的方法，避免忽然大量緩存失效。
• 啓用壓縮 　　在服務器端對文件進行壓縮，在瀏覽器端對文件解壓縮，可有效減小通訊傳輸的數據量。 　　CSS放在頁面最上面，javascript放在頁面最下面。 　　瀏覽器會在下載徹底部CSS以後纔對整個頁面進行渲染。 　　javacsript則相反，瀏覽器在加載js後當即執行，有可能會阻塞整個頁面
• 減小cookie傳輸 　　Cookie包含在每次請求和響應中，太大的Cookie會嚴重影響數據傳輸。

　　二：CDN加速

CDN（Content Distribute Network，內容分發網絡）的本質仍然是一個緩存，並且將數據緩存在離用戶最近的地方，使用戶以最快速度獲取數據，即所謂網絡訪問第一跳。

　　三：反向代理

能夠配置緩存加速web請求

 

---

 　　

　　二、應用服務器性能優化　　

網站性能優化第必定律：優先考慮使用緩存優化性能

　　　　一：分佈式緩存

1、緩存的基本原理
     緩存指將數據存儲在相對較高訪問速度的存儲介質中，以供系統處理。
      
     網站數據訪問一般遵循二八定律，即80%的訪問落在20%的數據上，所以利用Hash表和內存的高速訪問特性，將這20%的數據緩存起來，可很好的改善系統性能。


二、合理使用緩存

　　　頻繁修改的數據：不宜使用緩存。
　　　　（數據的讀寫比在2:1以上，即寫入一次緩存，在數據更新前至少讀取兩次，緩存纔有意義）

　　　沒有熱點的訪問：不宜使用緩存。
　　　　（若是應用系統訪問數據沒有熱點，不遵循二八定律，即大部分數據訪問並無集中在小部分數據上，那麼緩存也就沒有意義）　

　　　數據不一致與髒讀：若是不能容忍必定時間的數據不一致，也不建議使用緩存。
　　　　
　　　緩存可用性：緩存是爲了提升數據讀取性能，緩存數據丟失或者緩存不可用不會影響到應用程序的處理，由於能夠從數據庫直接獲取數據。
　　　　　　但當緩存服務崩潰時，數據庫的壓力會驟然增長，嚴重會致使宕機。
　　　　　　（因此須要避免 緩存雪崩）
　　　
　　　緩存預熱：緩存中存放的是熱點數據，熱點數據又是緩存系統利用LRU對不斷訪問的數據篩選淘汰數來的，這個過程須要花費較長的時間。若是是新啓動的緩存系統，若是沒有任何數據，在重建緩存數據的過程當中
　　　　　　系統的性能和負載都不太好，那麼最好在緩存系統啓動時就把熱點數據加載好。

　　  緩存穿透：若是由於不恰當的業務或者惡意攻擊持續高併發地請求某個不存在的數據，因爲緩存沒有保存該數據，全部的請求都會落在數據庫上，會對數據庫形成很大的壓力，甚至崩潰。
　　　　　　（一個簡單的對策是將不存在的數據也緩存起來）


三、分佈式緩存架構
　　　　指緩存部署多個服務器組成的集羣中，以集羣方式提供緩存服務。

四、Memcached
　　　　（簡單的通訊協議、豐富的客戶端程序、高性能的網絡通訊、高效的內存管理、互不通訊的服務器集羣架構）

　二： 異步操做

任何能夠晚點作的事情都應該晚點再作。

使用消息隊列將調用異步話，經過異步處理，將短期高併發產生的事務消息存儲在消息隊列中，從而削平高峯期的併發事務。 -----   消息隊列具備很好的削峯做用

　三：使用集羣

在高併發訪問的場景下，使用負載均衡技術爲一個應用構建一個由多臺服務器組成的服務器集羣，將併發訪問請求分發到多臺服務器上處理，避免單一服務器因負載壓力過大而響應緩慢。

  四：代碼優化

1、多線程
    使用多線程的緣由主要有兩個：IO阻塞與多CPU。
    （理想的系統Load是既沒有進程（線程）等待也沒有CPU空閒）。

    啓動線程數=[任務執行時間/(任務執行時間-IO等待時間)] * CPU內核數

    解決線程安全的主要手段：
       ①： 將對象設計爲無狀態對象（指對象自己不存儲狀態信息），這樣多線程併發訪問的時候就不會出現狀態不一致，java web 開發中經常使用的servlet對象就設計爲無狀態對象。
        ②：使用局部對象
        ③：併發訪問資源時使用鎖

2、資源複用
     從編程角度，資源複用主要兩張模式：單例（Singleton） 和對象池 （Object Pool）
     好比：數據庫鏈接、網絡通訊鏈接、線程、複雜對象等。

3、數據結構
    
4、垃圾回收
    合理設置堆大小，減小Full GC次數

 

---

 

　三、存儲性能優化

　　①、機械硬盤  &  固態硬盤

　　②、B+樹 & LSM樹

　　③、RAID  &  HDFS