1 網站架構及性能調優攻略

時間 2019-12-12

標籤網站架構性能攻略欄目網站開發简体版

原文原文鏈接

從單機至億級流量大型網站系統架構的演進過程

web服務集羣須要解決的問題：html

負載均衡的問題，通常有5種解決方案：nginx

一、http重定向。HTTP重定向就是應用層的請求轉發。用戶的請求其實已經到了HTTP重定向負載均衡服務器，服務器根據算法要求用戶重定向，用戶收到重定向請求後，再次請求真正的集羣web

優勢：簡單。算法
缺點：性能較差。shell

二、DNS域名解析負載均衡。DNS域名解析負載均衡就是在用戶請求DNS服務器，獲取域名對應的IP地址時，DNS服務器直接給出負載均衡後的服務器IP。數據庫

優勢：交給DNS，不用咱們去維護負載均衡服務器。apache
缺點：當一個應用服務器掛了，不能及時通知DNS，並且DNS負載均衡的控制權在域名服務商那裏，網站沒法作更多的改善和更強大的管理。瀏覽器

三、反向代理服務器。在用戶的請求到達反向代理服務器時（已經到達網站機房），由反向代理服務器根據算法轉發到具體的服務器。經常使用的apache，nginx均可以充當反向代理服務器。安全

優勢：部署簡單。服務器
缺點：代理服務器可能成爲性能的瓶頸，特別是一次上傳大文件。

四、IP層負載均衡。在請求到達負載均衡器後，負載均衡器經過修改請求的目的IP地址，從而實現請求的轉發，作到負載均衡。

優勢：性能更好。
缺點：負載均衡器的寬帶成爲瓶頸。

五、數據鏈路層負載均衡。在請求到達負載均衡器後，負載均衡器經過修改請求的mac地址，從而作到負載均衡，與IP負載均衡不同的是，當請求訪問完服務器以後，直接返回客戶。而無需再通過負載均衡器。

集羣調度算法問題，常見的調度算法有10種：

一、rr 輪詢調度算法。顧名思義，輪詢分發請求。

優勢：實現簡單
缺點：不考慮每臺服務器的處理能力

二、wrr 加權調度算法。咱們給每一個服務器設置權值weight，負載均衡調度器根據權值調度服務器，服務器被調用的次數跟權值成正比。

優勢：考慮了服務器處理能力的不一樣

三、sh 原地址散列：提取用戶IP，根據散列函數得出一個key，再根據靜態映射表，查處對應的value，即目標服務器IP。過目標機器超負荷，則返回空。

四、dh 目標地址散列：同上，只是如今提取的是目標地址的IP來作哈希。

優勢：以上兩種算法的都能實現同一個用戶訪問同一個服務器。

五、lc 最少鏈接。優先把請求轉發給鏈接數少的服務器。

優勢：使得集羣中各個服務器的負載更加均勻。

六、wlc 加權最少鏈接。在lc的基礎上，爲每臺服務器加上權值。算法爲：（活動鏈接數*256+非活動鏈接數）÷權重，計算出來的值小的服務器優先被選擇。

優勢：能夠根據服務器的能力分配請求。

七、sed 最短時間望延遲。其實sed跟wlc相似，區別是不考慮非活動鏈接數。算法爲：（活動鏈接數+1)*256÷權重，一樣計算出來的值小的服務器優先被選擇。

八、nq 永不排隊。改進的sed算法。咱們想一下什麼狀況下才能「永不排隊」，那就是服務器的鏈接數爲0的時候，那麼假若有服務器鏈接數爲0，均衡器直接把請求轉發給它，無需通過sed的計算。

九、LBLC 基於局部性的最少鏈接。均衡器根據請求的目的IP地址，找出該IP地址最近被使用的服務器，把請求轉發之，若該服務器超載，最採用最少鏈接數算法。

十、LBLCR 帶複製的基於局部性的最少鏈接。均衡器根據請求的目的IP地址，找出該IP地址最近使用的「服務器組」，注意，並非具體某個服務器，而後採用最少鏈接數從該組中挑出具體的某臺服務器出來，把請求轉發之。若該服務器超載，那麼根據最少鏈接數算法，在集羣的非本服務器組的服務器中，找出一臺服務器出來，加入本服務器組，而後把請求轉發之。

第三個問題是集羣模式問題，通常3種解決方案：

一、NAT：負載均衡器接收用戶的請求，轉發給具體服務器，服務器處理完請求返回給均衡器，均衡器再從新返回給用戶。

二、DR：負載均衡器接收用戶的請求，轉發給具體服務器，服務器處理完請求後直接返回給用戶。須要系統支持IP Tunneling協議，難以跨平臺。

三、TUN：同上，但無需IP Tunneling協議，跨平臺性好，大部分系統均可以支持。

第四個問題是session問題，通常有4種解決方案：

一、Session Sticky。session sticky就是把同一個用戶在某一個會話中的請求，都分配到固定的某一臺服務器中，這樣咱們就不須要解決跨服務器的session問題了，常見的算法有ip_hash法，即上面提到的兩種散列算法。