新聞動態

高性能服務器架構思路【不僅是思路】

2019-10-21 15:39:37 21

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

1. 緩存策略的概念和實例

2.緩存策略的難點:不同特點的緩存數據的清理機制

3.分布策略的概念和實例

4.分布策略的難點:共享數據安全性與代碼復雜度的平衡

緩存

緩存策略的概念

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

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


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

當我們訪問一個WEB的網站的時候,輸入的URL地址會被服務器變成對磁盤上某個文件的讀取。如果有大量的用戶訪問這個網站,每次的請求都會造成對磁盤的讀操作,可能會讓磁盤不堪重負,導致無法即時讀取到文件內容。但是如果我們寫的程序,會把讀取過一次的文件內容,長時間的保存在內存中,當有另外一個對同樣文件的讀取時,就直接從內存中把數據返回給客戶端,就無需去讓磁盤讀取了。由于用戶訪問的文件往往很集中,所以大量的請求可能都能從內存中找到保存的副本,這樣就能大大提高服務器能承載的訪問量了。這種做法,就是用內存的空間,換取了磁盤的讀寫時間,屬于用空間換時間的策略。


[方便面預先緩存了大量的烹飪操作]

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


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

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

另外,我們的Web服務器,在發送HTML文件內容的時候,往往也會先用ZIP壓縮,然后發送給瀏覽器,瀏覽器收到后要先解壓,然后才能顯示,這個也是用服務器和客戶端的CPU時間,來換取網絡帶寬的空間。


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


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

緩存的本質,除了讓“已經處理過的數據,不需要重復處理”以外,還有“以快速的數據存儲讀寫,代替較慢速的存儲讀寫”的策略。我們在選擇緩存策略進行時空轉換的時候,必須明確我們要轉換的時間和空間是否合理,是否能達到效果。比如早期有一些人會把WEB文件緩存在分布式磁盤上(例如NFS),但是由于通過網絡訪問磁盤本身就是一個比較慢的操作,而且還會占用可能就不充裕的網絡帶寬空間,導致性能可能變得更慢。

在設計緩存機制的時候,我們還容易碰到另外一個風險,就是對緩存數據的編程處理問題。如果我們要緩存的數據,并不是完全無需處理直接讀寫的,而是需要讀入內存后,以某種語言的結構體或者對象來處理的,這就需要涉及到“序列化”和“反序列化”的問題。如果我們采用直接拷貝內存的方式來緩存數據,當我們的這些數據需要跨進程、甚至跨語言訪問的時候,會出現那些指針、ID、句柄數據的失效。因為在另外一個進程空間里,這些“標記型”的數據都是不存在的。因此我們需要更深入的對數據緩存的方法,我們可能會使用所謂深拷貝的方案,也就是跟著那些指針去找出目標內存的數據,一并拷貝。一些更現代的做法,則是使用所謂序列化方案來解決這個問題,也就是用一些明確定義了的“拷貝方法”來定義一個結構體,然后用戶就能明確的知道這個數據會被拷貝,直接取消了指針之類的內存地址數據的存在。比如著名的ProtocolBuffer就能很方便的進行內存、磁盤、網絡位置的緩存;現在我們常見的JSON,也被一些系統用來作為緩存的數據格式。

但是我們需要注意的是,緩存的數據和我們程序真正要操作的數據,往往是需要進行一些拷貝和運算的,這就是序列化和反序列化的過程,這個過程很快,也有可能很慢。所以我們在選擇數據緩存結構的時候,必須要注意其轉換時間,否則你緩存的效果可能被這些數據拷貝、轉換消耗去很多,嚴重的甚至比不緩存更差。一般來說,緩存的數據越解決使用時的內存結構,其轉換速度就越快,在這點上,Protocol Buffer采用TLV編碼,就比不上直接memcpy的一個C結構體,但是比編碼成純文本的XML或者JSON要來的更快。因為編解碼的過程往往要進行復雜的查表映射,列表結構等操作。

緩存策略的難點

雖然使用緩存思想似乎是一個很簡單的事情,但是緩存機制卻有一個核心的難點,就是——緩存清理。我們所說的緩存,都是保存一些數據,但是這些數據往往是會變化的,我們要針對這些變化,清理掉保存的“臟”數據,卻可能不是那么容易。

首先我們來看看最簡單的緩存數據——靜態數據。這種數據往往在程序的運行時是不會變化的,比如Web服務器內存中緩存的HTML文件數據,就是這種。事實上,所有的不是由外部用戶上傳的數據,都屬于這種“運行時靜態數據”。一般來說,我們對這種數據,可以采用兩種建立緩存的方法:一是程序一啟動,就一股腦把所有的靜態數據從文件或者數據庫讀入內存;二就是程序啟動的時候并不加載靜態數據,而是等有用戶訪問相關數據的時候,才去加載,這也就是所謂lazyload的做法。第一種方法編程比較簡單,程序的內存啟動后就穩定了,不太容易出現內存漏洞(如果加載的緩存太多,程序在啟動后立刻會因內存不足而退出,比較容易發現問題);第二種方法程序啟動很快,但要對緩存占用的空間有所限制或者規劃,否則如果要緩存的數據太多,可能會耗盡內存,導致在線服務中斷。

一般來說,靜態數據是不會“臟”的,因為沒有用戶會去寫緩存中的數據。但是在實際工作中,我們的在線服務往往會需要“立刻”變更一些緩存數據。比如在門戶網站上發布了一條新聞,我們會希望立刻讓所有訪問的用戶都看到。按最簡單的做法,我們一般只要重啟一下服務器進程,內存中的緩存就會消失了。對于靜態緩存的變化頻率非常低的業務,這樣是可以的,但是如果是新聞網站,就不能每隔幾分鐘就重啟一下WEB服務器進程,這樣會影響大量在線用戶的訪問。常見的解決這類問題有兩種處理策略:

第一種是使用控制命令。簡單來說,就是在服務器進程上,開通一個實時的命令端口,我們可以通過網絡數據包(如UDP包),或者Linux系統信號(如kill SIGUSR2進程號)之類的手段,發送一個命令消息給服務器進程,讓進程開始清理緩存。這種清理可能執行的是最簡單的“全部清理”,也有的可以細致一點的,讓命令消息中帶有“想清理的數據ID”這樣的信息,比如我們發送給WEB服務器的清理消息網絡包中會帶一個字符串URL,表示要清理哪一個HTML文件的緩存。這種做法的好處是清理的操作很精準,可以明確的控制清理的時間和數據。但是缺點就是比較繁瑣,手工去編寫發送這種命令很煩人,所以一般我們會把清理緩存命令的工作,編寫到上傳靜態數據的工具當中,比如結合到網站的內容發布系統中,一旦編輯提交了一篇新的新聞,發布系統的程序就自動的發送一個清理消息給WEB服務器。

第二種是使用字段判斷邏輯。也就是服務器進程,會在每次讀取緩存前,根據一些特征數據,快速的判斷內存中的緩存和源數據內容,是否有不一致(是否臟)的地方,如果有不一致的地方,就自動清理這條數據的緩存。這種做法會消耗一部分CPU,但是就不需要人工去處理清理緩存的事情,自動化程度很高。現在我們的瀏覽器和WEB服務器之間,就有用這種機制:檢查文件MD5;或者檢查文件最后更新時間。具體的做法,就是每次瀏覽器發起對WEB服務器的請求時,除了發送URL給服務器外,還會發送一個緩存了此URL對應的文件內容的MD5校驗串、或者是此文件在服務器上的“最后更新時間”(這個校驗串和“最后更新時間”是第一次獲的文件時一并從服務器獲得的);服務器收到之后,就會把MD5校驗串或者最后更新時間,和磁盤上的目標文件進行對比,如果是一致的,說明這個文件沒有被修改過(緩存不是“臟”的),可以直接使用緩存。否則就會讀取目標文件返回新的內容給瀏覽器。這種做法對于服務器性能是有一定消耗的,所以如果往往我們還會搭配其他的緩存清理機制來用,比如我們會在設置一個“超時檢查”的機制:就是對于所有的緩存清理檢查,我們都簡單的看看緩存存在的時間是否“超時”了,如果超過了,才進行下一步的檢查,這樣就不用每次請求都去算MD5或者看最后更新時間了。但是這樣就存在“超時”時間內緩存變臟的可能性。


[WEB服務器靜態緩存例子]

上面說了運行時靜態的緩存清理,現在說說運行時變化的緩存數據。在服務器程序運行期間,如果用戶和服務器之間的交互,導致了緩存的數據產生了變化,就是所謂“運行時變化緩存”。比如我們玩網絡游戲,登錄之后的角色數據就會從數據庫里讀出來,進入服務器的緩存(可能是堆內存或者memcached、共享內存),在我們不斷進行游戲操作的時候,對應的角色數據就會產生修改的操作,這種緩存數據就是“運行時變化的緩存”。這種運行時變化的數據,有讀和寫兩個方面的清理問題:由于緩存的數據會變化,如果另外一個進程從數據庫讀你的角色數據,就會發現和當前游戲里的數據不一致;如果服務器進程突然結束了,你在游戲里升級,或者撿道具的數據可能會從內存緩存中消失,導致你白忙活了半天,這就是沒有回寫(緩存寫操作的清理)導致的問題。這種情況在電子商務領域也很常見,最典型的就是火車票網上購買的系統,火車票數據緩存在內存必須有合適的清理機制,否則讓兩個買了同一張票就麻煩了,但如果不緩存,大量用戶同時搶票,服務器也應對不過來。因此在運行時變化的數據緩存,應該有一些特別的緩存清理策略。

在實際運行業務中,運行變化的數據往往是根據使用用戶的增多而增多的,因此首先要考慮的問題,就是緩存空間不夠的可能性。我們不太可能把全部數據都放到緩存的空間里,也不可能清理緩存的時候就全部數據一起清理,所以我們一般要對數據進行分割,這種分割的策略常見的有兩種:一種是按重要級來分割,一種是按使用部分分割。

先舉例說說“按重要級分割”,在網絡游戲中,同樣是角色的數據,有些數據的變化可能會每次修改都立刻回寫到數據庫(清理寫緩存),其他一些數據的變化會延遲一段時間,甚至有些數據直到角色退出游戲才回寫,如玩家的等級變化(升級了),武器裝備的獲得和消耗,這些玩家非常看重的數據,基本上會立刻回寫,這些就是所謂最重要的緩存數據。而玩家的經驗值變化、當前HP、MP的變化,就會延遲一段時間才寫,因為就算丟失了緩存,玩家也不會太過關注。最后有些比如玩家在房間(地區)里的X/Y坐標,對話聊天的記錄,可能會退出時回寫,甚至不回寫。這個例子說的是“寫緩存”的清理,下面說說“讀緩存”的按重要級分割清理。


假如我們寫一個網店系統,里面容納了很多產品,這些產品有一些會被用戶頻繁檢索到,比較熱銷,而另外一些商品則沒那么熱銷。熱銷的商品的余額、銷量、評價都會比較頻繁的變化,而滯銷的商品則變化很少。所以我們在設計的時候,就應該按照不同商品的訪問頻繁程度,來決定緩存哪些商品的數據。我們在設計緩存的結構時,就應該構建一個可以統計緩存讀寫次數的指標,如果有些數據的讀寫頻率過低,或者空閑(沒有人讀、寫緩存)時間超長,緩存應該主動清理掉這些數據,以便其他新的數據能進入緩存。這種策略也叫做“冷熱交換”策略。實現“冷熱交換”的策略時,關鍵是要定義一個合理的冷熱統計算法。一些固定的指標和算法,往往并不能很好的應對不同硬件、不同網絡情況下的變化,所以現在人們普遍會用一些動態的算法,如Redis就采用了5種,他們是:

1.根據過期時間,清理最長時間沒用過的

2.根據過期時間,清理即將過期的

3.根據過期時間,任意清理一個

4.無論是否過期,隨機清理

5.無論是否過期,根據LRU原則清理:所謂LRU,就是Least Recently Used,最近最久未使用過。這個原則的思想是:如果一個數據在最近一段時間沒有被訪問到,那么在將來他被訪問的可能性也很小。LRU是在操作系統中很常見的一種原則,比如內存的頁面置換算法(也包括FIFO,LFU等),對于LRU的實現,還是非常有技巧的,但是本文就不詳細去說明如何實現,留待大家上網搜索“LRU”關鍵字學習。

數據緩存的清理策略其實遠不止上面所說的這些,要用好緩存這個武器,就要仔細研究需要緩存的數據特征,他們的讀寫分布,數據之中的差別。然后最大化的利用業務領域的知識,來設計最合理的緩存清理策略。這個世界上不存在萬能的優化緩存清理策略,只存在針對業務領域最優化的策略,這需要我們程序員深入理解業務領域,去發現數據背后的規律。


分布

分布策略的概念

任何的服務器的性能都是有極限的,面對海量的互聯網訪問需求,是不可能單靠一臺服務器或者一個CPU來承擔的。所以我們一般都會在運行時架構設計之初,就考慮如何能利用多個CPU、多臺服務器來分擔負載,這就是所謂分布的策略。分布式的服務器概念很簡單,但是實現起來卻比較復雜。因為我們寫的程序,往往都是以一個CPU,一塊內存為基礎來設計的,所以要讓多個程序同時運行,并且協調運作,這需要更多的底層工作。

首先出現能支持分布式概念的技術是多進程。在DOS時代,計算機在一個時間內只能運行一個程序,如果你想一邊寫程序,同時一邊聽mp3,都是不可能的。但是,在WIN95操作系統下,你就可以同時開多個窗口,背后就是同時在運行多個程序。在Unix和后來的Linux操作系統里面,都普遍支持了多進程的技術。所謂的多進程,就是操作系統可以同時運行我們編寫的多個程序,每個程序運行的時候,都好像自己獨占著CPU和內存一樣。在計算機只有一個CPU的時候,實際上計算機會分時復用的運行多個進程,CPU在多個進程之間切換。但是如果這個計算機有多個CPU或者多個CPU核,則會真正的有幾個進程同時運行。所以進程就好像一個操作系統提供的運行時“程序盒子”,可以用來在運行時,容納任何我們想運行的程序。當我們掌握了操作系統的多進程技術后,我們就可以把服務器上的運行任務,分為多個部分,然后分別寫到不同的程序里,利用上多CPU或者多核,甚至是多個服務器的CPU一起來承擔負載。


[多進程利用多CPU]

這種劃分多個進程的架構,一般會有兩種策略:一種是按功能來劃分,比如負責網絡處理的一個進程,負責數據庫處理的一個進程,負責計算某個業務邏輯的一個進程。另外一種策略是每個進程都是同樣的功能,只是分擔不同的運算任務而已。使用第一種策略的系統,運行的時候,直接根據操作系統提供的診斷工具,就能直觀的監測到每個功能模塊的性能消耗,因為操作系統提供進程盒子的同時,也能提供對進程的全方位的監測,比如CPU占用、內存消耗、磁盤和網絡I/O等等。但是這種策略的運維部署會稍微復雜一點,因為任何一個進程沒有啟動,或者和其他進程的通信地址沒配置好,都可能導致整個系統無法運作;而第二種分布策略,由于每個進程都是一樣的,這樣的安裝部署就非常簡單,性能不夠就多找幾個機器,多啟動幾個進程就完成了,這就是所謂的平行擴展。

現在比較復雜的分布式系統,會結合這兩種策略,也就是說系統既按一些功能劃分出不同的具體功能進程,而這些進程又是可以平行擴展的。當然這樣的系統在開發和運維上的復雜度,都是比單獨使用“按功能劃分”和“平行劃分”要更高的。由于要管理大量的進程,傳統的依靠配置文件來配置整個集群的做法,會顯得越來越不實用:這些運行中的進程,可能和其他很多進程產生通信關系,當其中一個進程變更通信地址時,勢必影響所有其他進程的配置。所以我們需要集中的管理所有進程的通信地址,當有變化的時候,只需要修改一個地方。在大量進程構建的集群中,我們還會碰到容災和擴容的問題:當集群中某個服務器出現故障,可能會有一些進程消失;而當我們需要增加集群的承載能力時,我們又需要增加新的服務器以及進程。這些工作在長期運行的服務器系統中,會是比較常見的任務,如果整個分布系統有一個運行中的中心進程,能自動化的監測所有的進程狀態,一旦有進程加入或者退出集群,都能即時的修改所有其他進程的配置,這就形成了一套動態的多進程管理系統。開源的ZooKeeper給我們提供了一個可以充當這種動態集群中心的實現方案。由于ZooKeeper本身是可以平行擴展的,所以它自己也是具備一定容災能力的。現在越來越多的分布式系統都開始使用以ZooKeeper為集群中心的動態進程管理策略了。

[動態進程集群]

在調用多進程服務的策略上,我們也會有一定的策略選擇,其中最著名的策略有三個:一個是動態負載均衡策略;一個是讀寫分離策略;一個是一致性哈希策略。動態負載均衡策略,一般會搜集多個進程的服務狀態,然后挑選一個負載最輕的進程來分發服務,這種策略對于比較同質化的進程是比較合適的。讀寫分離策略則是關注對持久化數據的性能,比如對數據庫的操作,我們會提供一批進程專門用于提供讀數據的服務,而另外一個(或多個)進程用于寫數據的服務,這些寫數據的進程都會每次寫多份拷貝到“讀服務進程”的數據區(可能就是單獨的數據庫),這樣在對外提供服務的時候,就可以提供更多的硬件資源。一致性哈希策略是針對任何一個任務,看看這個任務所涉及讀寫的數據,是屬于哪一片的,是否有某種可以緩存的特征,然后按這個數據的ID或者特征值,進行“一致性哈希”的計算,分擔給對應的處理進程。這種進程調用策略,能非常的利用上進程內的緩存(如果存在),比如我們的一個在線游戲,由100個進程承擔服務,那么我們就可以把游戲玩家的ID,作為一致性哈希的數據ID,作為進程調用的KEY,如果目標服務進程有緩存游戲玩家的數據,那么所有這個玩家的操作請求,都會被轉到這個目標服務進程上,緩存的命中率大大提高。而使用“一致性哈希”,而不是其他哈希算法,或者取模算法,主要是考慮到,如果服務進程有一部分因故障消失,剩下的服務進程的緩存依然可以有效,而不會整個集群所有進程的緩存都失效。具體有興趣的讀者可以搜索“一致性哈希”一探究竟。

以多進程利用大量的服務器,以及服務器上的多個CPU核心,是一個非常有效的手段。但是使用多進程帶來的額外的編程復雜度的問題。一般來說我們認為最好是每個CPU核心一個進程,這樣能最好的利用硬件。如果同時運行的進程過多,操作系統會消耗很多CPU時間在不同進程的切換過程上。但是,我們早期所獲得的很多API都是阻塞的,比如文件I/O,網絡讀寫,數據庫操作等。如果我們只用有限的進程來執行帶這些阻塞操作的程序,那么CPU會大量被浪費,因為阻塞的API會讓有限的這些進程停著等待結果。那么,如果我們希望能處理更多的任務,就必須要啟動更多的進程,以便充分利用那些阻塞的時間,但是由于進程是操作系統提供的“盒子”,這個盒子比較大,切換耗費的時間也比較多,所以大量并行的進程反而會無謂的消耗服務器資源。加上進程之間的內存一般是隔離的,進程間如果要交換一些數據,往往需要使用一些操作系統提供的工具,比如網絡socket,這些都會額外消耗服務器性能。因此,我們需要一種切換代價更少,通信方式更便捷,編程方法更簡單的并行技術,這個時候,多線程技術出現了。


[在進程盒子里面的線程盒子]

多線程的特點是切換代價少,可以同時訪問內存。我們可以在編程的時候,任意讓某個函數放入新的線程去執行,這個函數的參數可以是任何的變量或指針。如果我們希望和這些運行時的線程通信,只要讀、寫這些指針指向的變量即可。在需要大量阻塞操作的時候,我們可以啟動大量的線程,這樣就能較好的利用CPU的空閑時間;線程的切換代價比進程低得多,所以我們能利用的CPU也會多很多。線程是一個比進程更小的“程序盒子”,他可以放入某一個函數調用,而不是一個完整的程序。一般來說,如果多個線程只是在一個進程里面運行,那其實是沒有利用到多核CPU的并行好處的,僅僅是利用了單個空閑的CPU核心。但是,在JAVA和C#這類帶虛擬機的語言中,多線程的實現底層,會根據具體的操作系統的任務調度單位(比如進程),盡量讓線程也成為操作系統可以調度的單位,從而利用上多個CPU核心。比如Linux2.6之后,提供了NPTL的內核線程模型,JVM就提供了JAVA線程到NPTL內核線程的映射,從而利用上多核CPU。而Windows系統中,據說本身線程就是系統的最小調度單位,所以多線程也是利用上多核CPU的。所以我們在使用JAVA\C#編程的時候,多線程往往已經同時具備了多進程利用多核CPU、以及切換開銷低的兩個好處。

早期的一些網絡聊天室服務,結合了多線程和多進程使用的例子。一開始程序會啟動多個廣播聊天的進程,每個進程都代表一個房間;每個用戶連接到聊天室,就為他啟動一個線程,這個線程會阻塞的讀取用戶的輸入流。這種模型在使用阻塞API的環境下,非常簡單,但也非常有效。

當我們在廣泛使用多線程的時候,我們發現,盡管多線程有很多優點,但是依然會有明顯的兩個缺點:一個內存占用比較大且不太可控;第二個是多個線程對于用一個數據使用時,需要考慮復雜的“鎖”問題。由于多線程是基于對一個函數調用的并行運行,這個函數里面可能會調用很多個子函數,每調用一層子函數,就會要在棧上占用新的內存,大量線程同時在運行的時候,就會同時存在大量的棧,這些棧加在一起,可能會形成很大的內存占用。并且,我們編寫服務器端程序,往往希望資源占用盡量可控,而不是動態變化太大,因為你不知道什么時候會因為內存用完而當機,在多線程的程序中,由于程序運行的內容導致棧的伸縮幅度可能很大,有可能超出我們預期的內存占用,導致服務的故障。而對于內存的“鎖”問題,一直是多線程中復雜的課題,很多多線程工具庫,都推出了大量的“無鎖”容器,或者“線程安全”的容器,并且還大量設計了很多協調線程運作的類庫。但是這些復雜的工具,無疑都是證明了多線程對于內存使用上的問題。


[同時排多條隊就是并行]

由于多線程還是有一定的缺點,所以很多程序員想到了一個釜底抽薪的方法:使用多線程往往是因為阻塞式API的存在,比如一個read()操作會一直停止當前線程,那么我們能不能讓這些操作變成不阻塞呢?——selector/epoll就是Linux退出的非阻塞式API。如果我們使用了非阻塞的操作函數,那么我們也無需用多線程來并發的等待阻塞結果。我們只需要用一個線程,循環的檢查操作的狀態,如果有結果就處理,無結果就繼續循環。這種程序的結果往往會有一個大的死循環,稱為主循環。在主循環體內,程序員可以安排每個操作事件、每個邏輯狀態的處理邏輯。這樣CPU既無需在多線程間切換,也無需處理復雜的并行數據鎖的問題——因為只有一個線程在運行。這種就是被稱為“并發”的方案。


[服務員兼了點菜、上菜就是并發]

實際上計算機底層早就有使用并發的策略,我們知道計算機對于外部設備(比如磁盤、網卡、顯卡、聲卡、鍵盤、鼠標),都使用了一種叫“中斷”的技術,早期的電腦使用者可能還被要求配置IRQ號。這個中斷技術的特點,就是CPU不會阻塞的一直停在等待外部設備數據的狀態,而是外部數據準備好后,給CPU發一個“中斷信號”,讓CPU轉去處理這些數據。非阻塞的編程實際上也是類似這種行為,CPU不會一直阻塞的等待某些I/O的API調用,而是先處理其他邏輯,然后每次主循環去主動檢查一下這些I/O操作的狀態。

多線程和異步的例子,最著名就是Web服務器領域的Apache和Nginx的模型。Apache是多進程/多線程模型的,它會在啟動的時候啟動一批進程,作為進程池,當用戶請求到來的時候,從進程池中分配處理進程給具體的用戶請求,這樣可以節省多進程/線程的創建和銷毀開銷,但是如果同時有大量的請求過來,還是需要消耗比較高的進程/線程切換。而Nginx則是采用epoll技術,這種非阻塞的做法,可以讓一個進程同時處理大量的并發請求,而無需反復切換。對于大量的用戶訪問場景下,apache會存在大量的進程,而nginx則可以僅用有限的進程(比如按CPU核心數來啟動),這樣就會比apache節省了不少“進程切換”的消耗,所以其并發性能會更好。


[Nginx的固定多進程,一個進程異步處理多個客戶端]


[Apache的多態多進程,一個進程處理一個客戶]

在現代服務器端軟件中,nginx這種模型的運維管理會更簡單,性能消耗也會稍微更小一點,所以成為最流行的進程架構。但是這種好處,會付出一些另外的代價:非阻塞代碼在編程的復雜度變大。

分布式編程復雜度

以前我們的代碼,從上往下執行,每一行都會占用一定的CPU時間,這些代碼的直接順序,也是和編寫的順序基本一致,任何一行代碼,都是唯一時刻的執行任務。當我們在編寫分布式程序的時候,我們的代碼將不再好像那些單進程、單線程的程序一樣簡單。我們要把同時運行的不同代碼,在同一段代碼中編寫。就好像我們要把整個交響樂團的每個樂器的樂譜,全部寫到一張紙上。為了解決這種編程的復雜度,業界發展出了多種編碼形式。

在多進程的編碼模型上,fork()函數可以說一個非常典型的代表。在一段代碼中,fork()調用之后的部分,可能會被新的進程中執行。要區分當前代碼的所在進程,要靠fork()的返回值變量。這種做法,等于把多個進程的代碼都合并到一塊,然后通過某些變量作為標志來劃分。這樣的寫法,對于不同進程代碼大部份相同的“同質進程”來說,還是比較方便的,最怕就是有大量的不同邏輯要用不同的進程來處理,這種情況下,我們就只能自己通過規范fork()附近的代碼,來控制混亂的局面。比較典型的是把fork()附近的代碼弄成一個類似分發器(dispatcher)的形式,把不同功能的代碼放到不同的函數中,以fork之前的標記變量來決定如何調用。


[動態多進程的代碼模式]

在我們使用多線程的API時,情況就會好很多,我們可以用一個函數指針,或者一個帶回調方法的對象,作為線程執行的主體,并且以句柄或者對象的形式來控制這些線程。作為開發人員,我們只要掌握了對線程的啟動、停止等有限的幾個API,就能很好的對并行的多線程進行控制。這對比多進程的fork()來說,從代碼上看會更直觀,只是我們必須要分清楚調用一個函數,和新建一個線程去調用一個函數,之間的差別:新建線程去調用函數,這個操作會很快的結束,并不會依序去執行那個函數,而是代表著,那個函數中的代碼,可能和線程調用之后的代碼,交替的執行。

由于多線程把“并行的任務”作為一個明確的編程概念定義了出來,以句柄、對象的形式封裝好,那么我們自然會希望對多線程能更多復雜而細致的控制。因此出現了很多多線程相關的工具。比較典型的編程工具有線程池、線程安全容器、鎖這三類。線程池提供給我們以“池”的形態,自動管理線程的能力:我們不需要自己去考慮怎么建立線程、回收線程,而是給線程池一個策略,然后輸入需要執行的任務函數,線程池就會自動操作,比如它會維持一個同時運行線程數量,或者保持一定的空閑線程以節省創建、銷毀線程的消耗。在多線程操作中,不像多進程在內存上完全是區分開的,所以可以訪問同一份內存,也就是對堆里面的同一個變量進行讀寫,這就可能產生程序員所預計不到的情況(因為我們寫程序只考慮代碼是順序執行的)。還有一些對象容器,比如哈希表和隊列,如果被多個線程同時操作,可能還會因為內部數據對不上,造成嚴重的錯誤,所以很多人開發了一些可以被多個線程同時操作的容器,以及所謂“原子”操作的工具,以解決這樣的問題。有些語言如Java,在語法層面,就提供了關鍵字來對某個變量進行“上鎖”,以保障只有一個線程能操作它。多線程的編程中,很多并行任務,是有一定的阻塞順序的,所以有各種各樣的鎖被發明出來,比如倒數鎖、排隊鎖等等。java.concurrent庫就是多線程工具的一個大集合,非常值得學習。然而,多線程的這些五花八門的武器,其實也是證明了多線程本身,是一種不太容易使用的順手的技術,但是我們一下子還沒有更好的替代方案罷了。


[多線程的對象模型]

在多線程的代碼下,除了啟動線程的地方,是和正常的執行順序不同以外,其他的基本都還是比較近似單線程代碼的。但是如果在異步并發的代碼下,你會發現,代碼一定要裝入一個個“回調函數”里。這些回調函數,從代碼的組織形態上,幾乎完全無法看出來其預期的執行順序,一般只能在運行的時候通過斷點或者日志來分析。這就對代碼閱讀帶來了極大的障礙。因此現在有越來越多的程序員關注“協程”這種技術:可以用類似同步的方法來寫異步程序,而無需把代碼塞到不同的回調函數里面。協程技術最大的特點,就是加入了一個叫yield的概念,這個關鍵字所在的代碼行,是一個類似return的作用,但是又代表著后續某個時刻,程序會從yield的地方繼續往下執行。這樣就把那些需要回調的代碼,從函數中得以解放出來,放到yield的后面了。在很多客戶端游戲引擎中,我們寫的代碼都是由一個框架,以每秒30幀的速度在反復執行,為了讓一些任務,可以分別放在各幀中運行,而不是一直阻塞導致“卡幀”,使用協程就是最自然和方便的了——Unity3D就自帶了協程的支持。

在多線程同步程序中,我們的函數調用棧就代表了一系列同屬一個線程的處理。但是在單線程的異步回調的編程模式下,我們的一個回調函數是無法簡單的知道,是在處理哪一個請求的序列中。所以我們往往需要自己寫代碼去維持這樣的狀態,最常見的做法是,每個并發任務啟動的時候,就產生一個序列號(seqid),然后在所有的對這個并發任務處理的回調函數中,都傳入這個seqid參數,這樣每個回調函數,都可以通過這個參數,知道自己在處理哪個任務。如果有些不同的回調函數,希望交換數據,比如A函數的處理結果希望B函數能得到,還可以用seqid作為key把結果存放到一個公共的哈希表容器中,這樣B函數根據傳入的seqid就能去哈希表中獲得A函數存入的結果了,這樣的一份數據我們往往叫做“會話”。如果我們使用協程,那么這些會話可能都不需要自己來維持了,因為協程中的棧代表了會話容器,當執行序列切換到某個協程中的時候,棧上的局部變量正是之前的處理過程的內容結果。


[協程的代碼特征]

為了解決異步編程的回調這種復雜的操作,業界還發明了很多其他的手段,比如lamda表達式、閉包、promise模型等等,這些都是希望我們,能從代碼的表面組織上,把在多個不同時間段上運行的代碼,以業務邏輯的形式組織到一起。

最后我想說說函數式編程,在多線程的模型下,并行代碼帶來最大的復雜性,就是對堆內存的同時操作。所以我們才弄出來鎖的機制,以及一大批對付死鎖的策略。而函數式編程,由于根本不使用堆內存,所以就無需處理什么鎖,反而讓整個事情變得非常簡單。唯一需要改變的,就是我們習慣于把狀態放到堆里面的編程思路。函數式編程的語言,比如LISP或者Erlang,其核心數據結果是鏈表——一種可以表示任何數據結構的結構。我們可以把所有的狀態,都放到鏈表這個數據列車中,然后讓一個個函數去處理這串數據,這樣同樣也可以傳遞程序的狀態。這是一種用棧來代替堆的編程思路,在多線程并發的環境下,非常的有價值。

分布式程序的編寫,一直都伴隨著大量的復雜性,影響我們對代碼的閱讀和維護,所以我們才有各種各樣的技術和概念,試圖簡化這種復雜性。也許我們無法找到任何一個通用的解決方案,但是我們可以通過理解各種方案的目標,來選擇最適合我們的場景:

l動態多進程fork——同質的并行任務

l多線程——能明確劃的邏輯復雜的并行任務

l異步并發回調——對性能要求高,但中間會被阻塞的處理較少的并行任務

l協程——以同步的寫法編寫并發的任務,但是不合適發起復雜的動態并行操作。

l函數式編程——以數據流為模型的并行處理任務

分布式數據通信

分布式的編程中,對于CPU時間片的切分本身不是難點,最困難的地方在于并行的多個代碼片段,如何進行通信。因為任何一個代碼段,都不可能完全單獨的運作,都需要和其他代碼產生一定的依賴。在動態多進程中,我們往往只能通過父進程的內存提供共享的初始數據,運行中則只能通過操作系統間的通訊方式了:Socket、信號、共享內存、管道等等。無論那種做法,這些都帶來了一堆復雜的編碼。這些方式大部分都類似于文件操作:一個進程寫入、另外一個進程讀出。所以很多人設計了一種叫“消息隊列”的模型,提供“放入”消息和“取出”消息的接口,底層則是可以用Socket、共享內存、甚至是文件來實現。這種做法幾乎能夠處理任何狀況下的數據通訊,而且有些還能保存消息。但是缺點是每個通信消息,都必須經過編碼、解碼、收包、發包這些過程,對處理延遲有一定的消耗。

如果我們在多線程中進行通信,那么我們可以直接對某個堆里面的變量直接進行讀寫,這樣的性能是最高的,使用也非常方便。但是缺點是可能出現幾個線程同時使用變量,產生了不可預期的結果,為了對付這個問題,我們設計了對變量的“鎖”機制,而如何使用鎖又成為另外一個問題,因為可能出現所謂的“死鎖”問題。所以我們一般會用一些“線程安全”的容器,用來作為多線程間通訊的方案。為了協調多個線程之間的執行順序,還可以使用很多種類型的“工具鎖”。

在單線程異步并發的情況下,多個會話間的通信,也是可以通過直接對變量進行讀寫操作,而且不會出現“鎖”的問題,因為本質上每個時刻都只有一個段代碼會操作這個變量。然而,我們還是需要對這些變量進行一定規劃和整理,否則各種指針或全局變量在代碼中散布,也是很出現BUG的。所以我們一般會把“會話”的概念變成一個數據容器,每段代碼都可以把這個會話容器作為一個“收件箱”,其他的并發任務如果需要在這個任務中通訊,就把數據放入這個“收件箱”即可。在WEB開發領域,和cookie對應的服務器端Session機制,就是這種概念的典型實現。

分布式緩存策略

在分布式程序架構中,如果我們需要整個體系有更高的穩定性,能夠對進程容災或者動態擴容提供支持,那么最難解決的問題,就是每個進程中的內存狀態。因為進程一旦毀滅,內存中的狀態會消失,這就很難不影響提供的服務。所以我們需要一種方法,讓進程的內存狀態,不太影響整體服務,甚至最好能變成“無狀態”的服務。當然“狀態”如果不寫入磁盤,始終還是需要某些進程來承載的。在現在流行的WEB開發模式中,很多人會使用PHP+Memcached+MySQL這種模型,在這里,PHP就是無狀態的,因為狀態都是放在Memcached里面。這種做法對于PHP來說,是可以隨時動態的毀滅或者新建,但是Memcached進程就要保證穩定才行;而且Memcached作為一個額外的進程,和它通信本身也會消耗更多的延遲時間。因此我們需要一種更靈活和通用的進程狀態保存方案,我們把這種任務叫做“分布式緩存”的策略。我們希望進程在讀取數據的時候,能有最高的性能,最好能和在堆內存中讀寫類似,又希望這些緩存數據,能被放在多個進程內,以分布式的形態提供高吞吐的服務,其中最關鍵的問題,就是緩存數據的同步。


[PHP常用Memached做緩存]

為了解決這個問題,我們需要先一步步來分解這個問題:

首先,我們的緩存應該是某種特定形式的對象,而不應該是任意類型的變量。因為我們需要對這些緩存進行標準化的管理,盡管C++語言提供了運算重載,我們可以對“=”號的寫變量操作進行重新定義,但是現在基本已經沒有人推薦去做這樣的事。而我們手頭就有最常見的一種模型,適合緩存這種概念的使用,它就是——哈希表。所有的哈希表(或者是Map接口),都是把數據的存放,分為key和value兩個部分,我們可以把想要緩存的數據,作為value存放到“表”當中,同時我們也可以用key把對應的數據取出來,而“表”對象就代表了緩存。

其次我們需要讓這個“表”能在多個進程中都存在。如果每個進程中的數據都毫無關聯,那問題其實就非常簡單,但是如果我們可能從A進程把數據寫入緩存,然后在B進程把數據讀取出來,那么就比較復雜了。我們的“表”要有能把數據在A、B兩個進程間同步的能力。因此我們一般會用三種策略:租約清理、租約轉發、修改廣播

l租約清理,一般是指,我們把存放某個key的緩存的進程,稱為持有這個key的數據的“租約”,這個租約要登記到一個所有進程都能訪問到的地方,比如是ZooKeeper集群進程。那么在讀、寫發生的時候,如果本進程沒有對應的緩存,就先去查詢一下對應的租約,如果被其他進程持有,則通知對方“清理”,所謂“清理”,往往是指刪除用來讀的數據,回寫用來寫的數據到數據庫等持久化設備,等清理完成后,在進行正常的讀寫操作,這些操作可能會重新在新的進程上建立緩存。這種策略在緩存命中率比較高的情況下,性能是最好的,因為一般無需查詢租約情況,就可以直接操作;但如果緩存命中率低,那么就會出現緩存反復在不同進程間“移動”,會嚴重降低系統的處理性能。


l租約轉發。同樣,我們把存放某個KEY的緩存的進程,稱為持有這個KEY數據的“租約”,同時也要登記到集群的共享數據進程中。和上面租約清理不同的地方在于,如果發現持有租約的進程不是本次操作的進程,就會把整個數據的讀、寫請求,都通過網絡“轉發”個持有租約的進程,然后等待他的操作結果返回。這種做法由于每次操作都需要查詢租約,所以性能會稍微低一些;但如果緩存命中率不高,這種做法能把緩存的操作分擔到多個進程上,而且也無需清理緩存,這比租約清理的策略適應性更好。


l修改廣播。上面兩種策略,都需要維護一份緩存數據的租約,但是本身對于租約的操作,就是一種比較耗費性能的事情。所以有時候可以采用一些更簡單,但可能承受一些不一致性的策略:對于讀操作,每個節點的讀都建立緩存,每次讀都判斷是否超過預設的讀冷卻時間x,超過則清理緩存從持久化重建;對于寫操作,么個節點上都判斷是否超過預設的寫冷卻時間y,超過則展開清理操作。清理操作也分兩種,如果數據量小就廣播修改數據;如果數據量大就廣播清理通知回寫到持久化中。這樣雖然可能會有一定的不一致風險,但是如果數據不是那種要求太高的,而且緩存命中率又能比較有保障的話(比如根據KEY來進行一致性哈希訪問緩存進程),那么真正因為寫操作廣播不及時,導致數據不一致的情況還是會比較少的。這種策略實現起來非常簡單,無需一個中心節點進程維護數據租約,也無需復雜的判斷邏輯進行同步,只要有廣播的能力,加上對于寫操作的一些配置,就能實現高效的緩存服務。所以“修改廣播”策略是在大多數需要實時同步,但數據一致性要求不高的領域最常見的手段。著名的DNS系統的緩存就是接近這種策略:我們要修改某個域名對應的IP,并不是立刻在全球所有的DNS服務器上生效,而是需要一定時間廣播修改給其他服務區。而我們每個DSN服務器,都具備了大量的其他域名的緩存數據。


總結

在高性能的服務器架構中,常用的緩存和分布兩種策略,往往是結合到一起使用的。雖然這兩種策略,都有無數種不同的表現形式,成為各種各樣的技術流派,但是只有清楚的理解這些技術的原理,并且和實際的業務場景結合起來,才能真正的做出滿足應用要求的高性能架構。


群英会开奖出好图表