Muduo 網絡程式設計示例之六：限制伺服器的最大并發連接配接數為什麼要限制并發連接配接數？Muduo 中限制并發連接配接數

Muduo 網絡程式設計示例之六：限制伺服器的最大并發連接配接數

陳碩 (giantchen_AT_gmail)

本文已以大家都熟悉的 EchoServer 介紹如何限制伺服器的并發連接配接數。

這篇文章中的“并發連接配接數”是指一個 server program 能同時支援的用戶端連接配接數，連接配接系由用戶端主動發起，服務端被動接受(accept)連接配接。（如果要限制應用程式主動發起的連接配接，則問題要簡單得多，畢竟主動權和決定權都在程式本身。）

一方面，我們不希望服務程式超載，另一方面，更因為 file descriptor 是稀缺資源，如果出現 file descriptor 耗盡，很棘手（跟 “malloc 失敗/new() 抛出 std::bad_alloc”差不多同樣棘手）。

Muduo 的 acceptor 正是這麼實作的，但是，這個做法在多線程下不能保證正确，會有 race condition。（思考題：是什麼 race condition？）

其實有另外一種比較簡單的辦法：file descriptor 是 hard limit，我們可以自己設一個稍低一點的 soft limit，如果超過 soft limit 就主動關閉新連接配接，這樣就避免觸及“file descriptor 耗盡”這種邊界條件。比方說目前程序的 max file descriptor 是 1024，那麼我們可以在連接配接數達到 1000 的時候進入“拒絕新連接配接”狀态，這樣留給我們足夠的騰挪空間。

然後，在 EchoServer::onConnection() 中判斷目前活動連接配接數，如果超過最大允許數，則踢掉連接配接。

這種做法可以積極地防止耗盡 file descriptor。

另外，如果是有業務邏輯的服務，可以在 shutdown() 之前發送一個簡單的響應，表明本服務程式的負載能力已經飽和，提示用戶端嘗試下一個可用的 server（當然，下一個可用的 server 位址不一定要在這個響應裡給出，用戶端可以自己去 name service 查詢），這樣友善用戶端快速 failover。

後文将介紹如何處理空閑連接配接的逾時：如果一個連接配接長時間（若幹秒）沒有輸入資料，則踢掉此連接配接。辦法有很多種，我用 Time Wheel 解決。

    本文轉自 陳碩  部落格園部落格，原文連結：http://www.cnblogs.com/Solstice/archive/2011/04/27/2029904.html，如需轉載請自行聯系原作者