原因:
經過前幾天的壓力測試, 發現網絡層處理消息有些問題, 定長的BUFF導致響應客戶端請求的數量要遠高於數據庫返回的響應(因爲客戶端發送的協議數據長度很小, 而數據庫返回的卻很大, 在同樣長度的BUFF內可以容納更多的客戶端請求, 打個比方, 平均響應100條客戶端請求, 才能響應一條數據庫請求, 這勢必會造成服務器內部堆積了大量的不均衡請求對, 最終有可能導致服務器掛掉), 所以打算近期進行改造.
思路:
如果能讓每條連接響應的協議數量可控, 則可以大大減少這種情況的發生. 那麼總體需要完成以下目標:
1) 增加接受回調函數的返回值(返回是否還需要繼續通知)
2) 增加未完成隊列(該隊列應爲一個hash_tbl, 用於存放哪個連接還有數據未讀取完, 且需要通知)
爲了能在響應這些通知的時候, 有能繼續處理系統通知事件, 這需要一個額外的線程輔助, 不過這樣又會涉及到鎖, 不安全的回調參數等問題, 我還並不是很希望進入這樣的不安全因素, 所以還需要進一步的思考完善.
未完待續...