push類型消息中間件-消息服務端(三)

1.鏈接管理

網絡架構原來是使用是本身開發的網絡框架Gecko,Gecko默認爲每一個網絡鏈接分配64KB的內存，支持1000個網絡鏈接，就須要大概64MB的內存。後來採用Netty重構了網絡服務層。

在Netty4是採用 Reactor Pattern線程模型

• 所謂Reactor Pattern模型是IO multiplexing event loop,Reactor負責處理全部IO事件，同時dispatching各IO事件的handler。
• 在新的模型中,有一個Boss線程池和Woker線程池,boss線程池主要處理socket accept事件，worker線程主要處理socket讀寫事件
• Boss線程在處理完socket accept請求(實際也只有一個NioEventLoop在處理accept事件)後，向Worker線程池取出一個NioEventLoopIO線程(默認輪詢策略)註冊剛創建鏈接的Channel(socket鏈接),此Channel生命週期內的全部讀寫事件都由其註冊的NioEventLoopIO線程負責。

2.存儲管理

數據庫存儲

支持異步和同步的數據庫消息記錄建立和更新，時序圖以下

文件存儲

存儲分爲物理分區和邏輯分區，物理分區存儲數據，邏輯分區存儲各個消費者須要的消息的索引，文件以DirectByteBuffer方式打開，消息順序存儲和順序消費，性能很是高。

接收和發送數據都採用 FileChannel Transfer的方式進行數據拷貝，減小內核態和用戶態的轉換，減小gc。
分佈式文件的基本結構

3.分組管理

消息存儲

到消息時先經過訂閱關係知道這條消息有哪些訂閱者須要訂閱，而後把這條消息的索引對應的訂閱分組的邏輯分區裏面去，分區的選擇採用隨機策略。消息存入邏輯分區時須要把消息序列化爲通信層傳輸的格式，便於使用零拷貝特性。

消息拉取推送

• 系統啓動時根據訂閱關係獲取全部訂閱分組的信息和分組對應的分區的信息，而後順序啓動每一個訂閱分組對應分區的拉取消息的任務，好比訂閱組A有5個分區，則會啓動5個任務分別的去5個分區裏面並行獲取消息並投遞，每次獲取消息的數量支持批量。
• 每一個任務獲取消息時都須要獲取任務鎖，投遞完消息後須要釋聽任務鎖，保證獲取消息
• 任務對每一個分區是單線程訪問的，避免消息重複投遞。
• 任務啓動時還須要向任務監控註冊，保證因爲線程池異常或者其餘異常致使任務異常終止時可以自動恢復超時的任務，繼續獲取消息並投遞。
• 訂閱關係新增時自動監聽並啓動新的任務投遞新訂閱分組的消息，當訂閱關係刪除時自動中止對應的訂閱分組的全部任務。
• 當某個訂閱者的分區數增多時自動增長一個該分區的任務獲取並投遞消息，當分區數減小時須要把減小的分區的消息投遞完後才中止該分區的任務並釋放相應資源。