高效能伺服器架構(一) 緩衝策略

2021-09-22 16:58:56 字數 3433 閱讀 3993

在伺服器端程式開發領域,效能問題一直是備受關注的重點。業界有大量的框架、元件、類庫都是以效能為賣點而廣為人知。然而,伺服器端程式在效能問題上應該有何種基本思路,這個卻很少被這些專案的文件提及。本文正式希望介紹伺服器端解決效能問題的基本策略和經典實踐 —— 由韓大分享。

在伺服器端程式開發領域,效能問題一直是備受關注的重點。業界有大量的框架、元件、類庫都是以效能為賣點而廣為人知。然而,伺服器端程式在效能問題上應該有何種基本思路,這個卻很少被這些專案的文件提及。本文正式希望介紹伺服器端解決效能問題的基本策略和經典實踐,並分為幾個部分來說明:

快取策略的概念和例項

快取策略的難點:不同特點的快取資料的清理機制

分布策略的概念和例項

分布策略的難點:共享資料安全性與**複雜度的平衡

我們提到伺服器端效能問題的時候,往往會混淆不清。因為當我們訪問乙個伺服器時,出現服務卡住不能得到資料,就會認為是「效能問題」。但是實際上這個效能問題可能是有不同的原因,表現出來都是針對客戶請求的延遲很長甚至中斷。我們來看看這些原因有哪些:第乙個是所謂併發數不足,也就是同時請求的客戶過多,導致超過容納能力的客戶被拒絕服務,這種情況往往會因為伺服器記憶體耗盡而導致的;第二個是處理延遲過長,也就是有一些客戶的請求處理時間已經超過使用者可以忍受的長度,這種情況常常表現為cpu占用滿額100%。

我們在伺服器開發的時候,最常用到的有下面這幾種硬體:cpu、記憶體、磁碟、網絡卡。其中cpu是代表計算機處理時間的,硬碟的空間一般很大,主要是讀寫磁碟會帶來比較大的處理延遲,而記憶體、網絡卡則是受儲存、頻寬的容量限制的。所以當我們的伺服器出現效能問題的時候,就是這幾個硬體某乙個甚至幾個都出現負荷佔滿的情況。這四個硬體的資源一般可以抽象成兩類:一類是時間資源,比如cpu和磁碟讀寫;一類是空間資源,比如記憶體和網絡卡頻寬。所以當我們的伺服器出現效能問題,有乙個最基本的思路,就是——時間空間轉換。我們可以舉幾個例子來說明這個問題。

[水壩就是用水庫空間來換流量時間的例子]

當我們訪問乙個web的**的時候,輸入的url位址會被伺服器變成對磁碟上某個檔案的讀取。如果有大量的使用者訪問這個**,每次的請求都會造成對磁碟的讀操作,可能會讓磁碟不堪重負,導致無法即時讀取到檔案內容。但是如果我們寫的程式,會把讀取過一次的檔案內容,長時間的儲存在記憶體中,當有另外乙個對同樣檔案的讀取時,就直接從記憶體中把資料返回給客戶端,就無需去讓磁碟讀取了。由於使用者訪問的檔案往往很集中,所以大量的請求可能都能從記憶體中找到儲存的副本,這樣就能大大提高伺服器能承載的訪問量了。這種做法,就是用記憶體的空間,換取了磁碟的讀寫時間,屬於用空間換時間的策略。

[速食麵預先快取了大量的烹飪操作]

舉另外乙個例子:我們寫乙個網路遊戲的伺服器端程式,通過讀寫資料庫來提供玩家資料存檔。如果有大量玩家進入這個伺服器,必定有很多玩家的資料資料變化,比如公升級、獲得**等等,這些通過讀寫資料庫來實現的操作,可能會讓資料庫程序負荷過重,導致玩家無法即時完成遊戲操作。我們會發現遊戲中的讀操作,大部分都是針是對一些靜態資料的,比如遊戲中的關卡資料、**道具的具體資訊;而很多寫操作,實際上是會覆蓋的,比如我的經驗值,可能每打乙個怪都會增加幾十點,但是最後記錄的只是最終的乙個經驗值,而不會記錄下打怪的每個過程。所以我們也可以使用時空轉換的策略來提供效能:我們可以用記憶體,把那些遊戲中的靜態資料,都一次性讀取並儲存起來,這樣每次讀這些資料,都和資料庫無關了;而玩家的資料資料,則不是每次變化都去寫資料庫,而是先在記憶體中保持乙個玩家資料的副本,所有的寫操作都先去寫記憶體中的結構,然後定期再由伺服器主動寫回到資料庫中,這樣可以把多次的寫資料庫操作變成一次寫操作,也能節省很多寫資料庫的消耗。這種做法也是用空間換時間的策略。

[拼裝家具很省運輸空間,但是安裝很費時]

最後說說用時間換空間的例子:假設我們要開發乙個企業通訊錄的資料儲存系統,客戶要求我們能儲存下通訊錄的每次新增、修改、刪除操作,也就是這個資料的所有變更歷史,以便可以讓資料回退到任何乙個過去的時間點。那麼我們最簡單的做法,就是這個資料在任何變化的時候,都拷貝乙份副本。但是這樣會非常的浪費磁碟空間,因為這個資料本身變化的部分可能只有很小一部分,但是要拷貝的副本可能很大。這種情況下,我們就可以在每次資料變化的時候,都記下一條記錄,內容就是資料變化的情況:插入了一條內容是某某的聯絡方法、刪除了一條某某的聯絡方法……,這樣我們記錄的資料,僅僅就是變化的部分,而不需要拷貝很多份副本。當我們需要恢復到任何乙個時間點的時候,只需要按這些記錄依次對資料修改一遍,直到指定的時間點的記錄即可。這個恢復的時間可能會有點長,但是卻可以大大節省儲存空間。這就是用cpu的時間來換磁碟的儲存空間的策略。我們現在常見的mysqlinnodb日誌型資料表,以及svn源**儲存,都是使用這種策略的。

另外,我們的web伺服器,在傳送html檔案內容的時候,往往也會先用zip壓縮,然後傳送給瀏覽器,瀏覽器收到後要先解壓,然後才能顯示,這個也是用伺服器和客戶端的cpu時間,來換取網路頻寬的空間。

在我們的計算機體系中,快取的思路幾乎無處不在,比如我們的cpu裡面就有1級快取、2級快取,他們就是為了用這些快速的儲存空間,換取對記憶體這種相對比較慢的儲存空間的等待時間。我們的顯示卡裡面也帶有大容量的快取,他們是用來儲存顯示圖形的運算結果的。

[通往大空間的郊區路上容易交通堵塞]

快取的本質,除了讓「已經處理過的資料,不需要重複處理」以外,還有「以快速的資料儲存讀寫,代替較慢速的儲存讀寫」的策略。我們在選擇快取策略進行時空轉換的時候,必須明確我們要轉換的時間和空間是否合理,是否能達到效果。比如早期有一些人會把web檔案快取在分布式磁碟上(例如nfs),但是由於通過網路訪問磁碟本身就是乙個比較慢的操作,而且還會占用可能就不充裕的網路頻寬空間,導致效能可能變得更慢。

在設計快取機制的時候,我們還容易碰到另外乙個風險,就是對快取資料的程式設計處理問題。如果我們要快取的資料,並不是完全無需處理直接讀寫的,而是需要讀入記憶體後,以某種語言的結構體或者物件來處理的,這就需要涉及到「序列化」和「反序列化」的問題。如果我們採用直接拷貝記憶體的方式來快取資料,當我們的這些資料需要跨程序、甚至跨語言訪問的時候,會出現那些指標、id、控制代碼資料的失效。因為在另外乙個程序空間裡,這些「標記型」的資料都是不存在的。因此我們需要更深入的對資料快取的方法,我們可能會使用所謂深拷貝的方案,也就是跟著那些指標去找出目標記憶體的資料,一併拷貝。一些更現代的做法,則是使用所謂序列化方案來解決這個問題,也就是用一些明確定義了的「拷貝方法」來定義乙個結構體,然後使用者就能明確的知道這個資料會被拷貝,直接取消了指標之類的記憶體位址資料的存在。比如著名的protocol buffer就能很方便的進行記憶體、磁碟、網路位置的快取;現在我們常見的json,也被一些系統用來作為快取的資料格式。

但是我們需要注意的是,快取的資料和我們程式真正要操作的資料,往往是需要進行一些拷貝和運算的,這就是序列化和反序列化的過程,這個過程很快,也有可能很慢。所以我們在選擇資料快取結構的時候,必須要注意其轉換時間,否則你快取的效果可能被這些資料拷貝、轉換消耗去很多,嚴重的甚至比不快取更差。一般來說,快取的資料越解決使用時的記憶體結構,其轉換速度就越快,在這點上,protocol buffer採用tlv編碼,就比不上直接memcpy的乙個c結構體,但是比編碼成純文字的xml或者json要來的更快。因為編譯碼的過程往往要進行複雜的查表對映,列表結構等操作。

高效能伺服器架構思路 一 緩衝策略

在伺服器端程式開發領域,效能問題一直是備受關注的重點。業界有大量的框架 元件 類庫都是以效能為賣點而廣為人知。然而,伺服器端程式在效能問題上應該有何種基本思路,這個卻很少被這些專案的文件提及。本文正式希望介紹伺服器端解決效能問題的基本策略和經典實踐,並分為幾個部分來說明 快取策略的概念和例項 快取策...

高效能伺服器架構思路 一 緩衝策略

在伺服器端程式開發領域,效能問題一直是備受關注的重點。業界有大量的框架 元件 類庫都是以效能為賣點而廣為人知。然而,伺服器端程式在效能問題上應該有何種基本思路,這個卻很少被這些專案的文件提及。本文正式希望介紹伺服器端解決效能問題的基本策略和經典實踐,並分為幾個部分來說明 快取策略的概念和例項 快取策...

高效能伺服器架構思路 一 緩衝策略

在伺服器端程式開發領域,效能問題一直是備受關注的重點。業界有大量的框架 元件 類庫都是以效能為賣點而廣為人知。然而,伺服器端程式在效能問題上應該有何種基本思路,這個卻很少被這些專案的文件提及。本文正式希望介紹伺服器端解決效能問題的基本策略和經典實踐,並分為幾個部分來說明 快取策略的概念和例項 快取策...