Leader Follower 程序池設計思路

2021-08-22 13:55:25 字數 1500 閱讀 7791

看了 [url= 的分析文章[/url]之後,覺得裡面的圖非常好地描述了 apache 的結構。也嘗試用 visio 畫一下 [url= 的結構。

對圖中各個部分的說明:

1. masterserver 通過 fork 建立 processmanager ,processpool 作為 processmanager 在 masterserver 中的存根

2. 在 processpool 和 processmanager 存在乙個 managerpipe 管道

3. 當 masterserver 需要更多的子程序的時候,masterserver 通過 processpool 物件向 processmanager 發起建立 childserver 的請求4. processmanager 是建立 childserver 的唯一乙個地方

5. 在 masterserver 和 childserver 之間存在乙個 childpipe 管道

6. masterserver 只負責監控子程序的狀態(包括:忙、閒、異常退出),監控子程序的狀態完全是通過 childpipe 來進行的;masterserver 使用 select 可以同時監控所有的 childpipe 的可讀狀態;當乙個 childpipe 可讀的時候,masterserver 讀入內容,如果讀入的最後乙個位元組為 busychar,設定 child 的狀態為 busy;如果為 idlechar ,設定 child 的狀態為 idle;如果讀入 0 位元組,那麼表示 child 已經關閉 childpipe ,也就表明 child 已經異常退出了。

7. childserver 被建立出來之後,就在 listenfd 上 accept ,如果 accept 成功就通過 childpipe 傳送乙個 busychar,然後開始處理;處理結束之後,再通過 childpipe 傳送乙個 idlechar;接著檢查 pipeofdeath 是否有內容,如果讀到有內容,那麼子程序自行退出;

關於幾個主要檔案控制代碼的傳遞說明:

1. managerpipe :masterserver 建立,傳遞給 processmanager(通過 fork)

2. listenfd :masterserver 建立,傳遞給 processmanager(通過 fork),由 processmanager 傳遞給 childserver(通過fork)

3. pipeofdeath :masterserver 建立,傳遞給 processmanager(通過 fork),由 processmanager 傳遞給 childserver(通過 fork),masterserver 持可寫的一端,各個 childserver 持可讀的一端;pipeofdeath 在 masterserver 只有乙個控制代碼;

4. childpipe :masterserver 建立,傳遞給 processmanager(通過 send_fd),由 processmanager 傳遞給 childserver(通過 fork),childpipe 在 masterserver 有多個,每個 childserver 有乙個 childpipe;

[img]

Leader Follower執行緒模型

io執行緒模型一直在演化,由最開始的單執行緒模型,到bio方式的單執行緒接受請求執行緒池執行緒具體處理單個請求的讀寫事件,再到nio的單執行緒接受請求執行緒池裡面的單個執行緒可以處理不同請求的讀寫事件,乙個字沒有最快,只有更快。最近發現還有個leader follower執行緒模型,其的出現是為了解...

leader follower 模型讀書筆記

douglas c.schmidt,carlos o ryan,michael kircher,i n pyarali,and frank buschmann 1.傳統的乙個執行緒select io 多個執行緒 worker 處理模型的缺點 a.io執行緒收到訊息後,需要動態分配記憶體,將請求放在該...

對LoginRequiredMixin進行重寫

首先我們要知道繼承自loginrequiredmixin的檢視類會怎樣走,未登入,會執行 handle no permission函式,登陸了,就直接繼續執行函式下邊的 如 class usercenterinfoview loginrequiredmixin,view def get self,r...