分佈式系統中的線程與進程

進程　　

　　雖然進程構成了分佈式系統中的基本組成單元，可是操做系統提供的用於構建分佈式系統的進程在粒度上仍是太大了，而就粒度而言，將每一個進程細分爲若干控制線程的形式則更加合適。

　　爲了程序執行的須要，操做系統建立多個虛擬處理器，每一個虛擬處理器運行一個程序。爲了保持對這些虛擬處理器的跟蹤，操做系統中有一張進程表。其包含的條目中存儲着CPU寄存器值、內存映像、打開的文件、統計信息、特權信息等。

　　操做系統特別注意確保獨立的進程不會有意或無心地破壞其餘獨立進程運行的正確性。也就是說，多個進程併發地共享同一個CPU以及其餘硬件資源這樣一個事實是透明的。通常來講，操做系統須要硬件支持來實現這種隔離。要獲得這種併發透明性須要付出相對較高的代價。例如：每次建立一個進程的時候，操做系統必須分配一個完整的獨立地址空間。空間分配意味着要對內存段進行初始化，比爾先對數據段清零，而後將相關的程序複製到文本段中，隨後爲臨時數據創建堆棧等。

　　在兩個進程之間切換CPU的開銷一樣會比較大，除了要保存CPU環境（包括寄存器值、程序計數器、堆棧指針等）之外，操做系統還必須修改內存管理單元的寄存器，而且將位於轉換後備緩衝器中的地址轉換緩存內容標記爲無效，另外，若是操做系統支持同時運行的進程數目超出主存容納能力，則必須在切換進程以前如今主存和磁盤之間進行交換。

 

非分佈式系統中的線程用法

　　多線程最顯著的好處來自如下事實：那就是在只擁有單線程的進程中，一旦執行了形成阻塞的系統調用，整個進程就被阻塞了。

　　多線程技術在大型應用程序上下文中也是頗有用的。這種應用程序通常是做爲一組寫做的程序開發出來的，其中每個程序都經過獨立的進程進行。例如UNIX系統，程序間寫做是經過進程間通訊(IPC）機制實現的。這套機制中一般包括已命名管道、消息隊列以及共享內存段。左右IPC機制都有一個主要的缺陷，就是其中的通訊須要開銷龐大的上下文切換：

　　

　　因爲IPC須要內核干預才能進行，所以，要進行IPC的進程通常首先要從用戶模式切換到內核模式，須要改變MMU中的內存映像，同時還要刷新TLB。在內核中進行進程上下文的切換，隨後就能夠從內核模式切換回用戶模式以使得通訊的另外一方可以激活。後一次切換也一樣須要改變MMU映像而且刷新TLB。

　　通常採用用戶級線程和內核級線程的混合模式（LWP），LWP運行在單個重量級進程的上下文中，每一個進程能夠包含多個LWP，除了LWP外，系統還提供用戶級線程包，嚮應用程序提供了建立和銷燬線程等普通操做。另外，包中還提供了用於線程同步的工具，好比互斥變量和條件變量。重要的是，線程包徹底在用戶空間中實現的。也就是說，執行這些線程操做不須要內核的干預。

　　

 

分佈式系統中的線程

一、多線程客戶

　　在廣域網上構建的分佈式系統須要隱藏較長的進程間消息傳播的時間。在廣域網中，傳輸的延遲很容易達到上百毫秒，甚至幾秒。

　　在不少狀況下，Web文檔是由HTML文件組成的，HTML文件中包含有純文本文件以及圖像組、圖標等。爲了得到Web文檔中每個組成部分，瀏覽器必須創建TCP/IP鏈接，讀取輸入數據並將數據傳遞給顯示組件。首先將文本顯示出來以便用戶查看，而且提供頁面滾動之類的功能，同時繼續獲取組成頁面的其餘文件，好比圖像等。在收到這些文件以後再顯示它們。用戶沒必要等待瀏覽器取得整個頁面的全部組件就可以查看頁面。

　　以多線程客戶的模式來開發瀏覽器能夠顯著地使問題簡化。每一個線程都與服務器簡歷一個獨立鏈接以獲取數據。在使用多線程客戶的時候，能夠與不一樣服務器副本創建鏈接，這樣就能夠並行地進行數據傳輸了，而且確保整個Web文檔徹底顯示出來所需的時間與使用無複製的服務器的狀況相比要短得多。

二、多線程服務器

　　考慮一下文件服務器的組織結構，該文件服務器可能會偶爾因爲等待磁盤操做而阻塞。文件服務器通常等待輸入的文件操做請求，隨後執行該請求，最後送回應答。下圖中，有一個稱爲分發器(dispatcher)的線程，由它來讀取文件操做請求。客戶發送請求到服務器的某個已知端點。在對請求進行檢查之後，服務器選擇一個空閒的（也就是阻塞的）工做着線程，由它來處理該請求。

　　工做者線程在本地文件系統上執行阻塞的read調用，執行該調用將會致使該線程被掛起直到數據從磁盤上讀出爲止。若是該線程被掛起了，就選擇另外一個線程接着執行。

 

 

簡單總結下服務器集羣。

　　簡單說，服務器集羣只是一組經網絡鏈接的機器，每臺機器運行一個或多個服務器，這裏所講的服務器集羣是特指經局域網鏈接的機器，能提供高帶寬和低延遲。

　　大多數狀況下，服務器集羣邏輯上由三層組成，第一層是一個邏輯上的交換機，由它分配客戶請求給服務器。在功能上好比：傳輸層交換機接收TCP鏈接請求，再轉發給集羣中的某個服務器。

　　

　　就像全部的多層客戶-服務器體系結構同樣，不少服務器集羣也包含了專用於應用處理的服務器。在集羣計算中，這一般是運行在高性能硬件上專用於提供計算能力的服務器。然而，在企業服務器集羣中，應用程序可能只需運行在相對低端的機器上，由於在這裏的平靜不是計算能力而是數據存取。 固然如今的諸如Hadoop分佈式計算框架已經不是三層結構，每臺機器都有本身的本地存儲，把應用和數據處理集成在單個服務器中。

　　第一層：一個重要的服務器集羣設計目標是隱藏有多個服務器的事實。也就是說，運行在遠程機器上的客戶應用程序不該該須要知道集羣的內部組織結構。這種存取透明性經過單個訪問點來實現（就比如你調用spark的thriftserver服務，傳入一個sql,並返回結果給你，你並不知道是由幾個節點運算的）。

　　一個標準的存取服務器集羣的方式是簡歷一個TCP鏈接，在這之上應用級別的請求可做爲一個會話的一部分來發送。經過撤除鏈接可結束會話。在傳輸層交換機的狀況下，交換機接受到來的TCP鏈接請求，轉發一些請求給一臺服務器。