基於mongoDB的capped collection的性能優化

MonitorLogging改造(消息接入)

改造前架構：

能夠看出原來的流程中，大量業務分析，業務接入耦合在web服務層。大量操做，致使線程線性的掛起線程。

改造後：

將業務通信抽象成爲MonitorQueueManager，並將業務主題抽象放到各自的collection中。

形如：

抽象爲一個結構topic,content針對業務分爲若干個主題。方便之後切換到mq或者其餘的隊列中。

MonitorSchedule改造（消息集中處理）

原有處理流程

當時業務比較少，只有一個主處理流程，因此強耦合到main方法中，擴展基本等於0。加之以前開發比較倉促，編碼註釋基本沒有。
如今要將monitorLoging裏面的全部業務處理，放到MonitorSchedule中。業務增長，若是架構再不進行改變那即將是個災難（維護或者業務流程新增）。

改造以後的流程：

看起來也清晰很多吧，原來的業務分紅了按照業務事件進行分類。

使用監聽器來處理事件自己，就有一個問題。多線程的狀況下如何管理業務的處理速度。原有的瓶頸放到mongodb中了，可是，若是線程讀取太快了，那麼，性能的瓶頸有被移到了任務操做中了。

capped collection

這裏咱們先說下mongodb的capped collection：

• 固定長度
• LRU隊列
• 環裝結構，老數據自動覆蓋
• 錄入隊列的數據能夠與直接讀寫磁盤媲美
• 基於日誌形式（不可修改，不創建索引狀況下速度與寫磁盤相同）

因此你們能夠看到，若是寫到了mongoDB的collection隊列以後，序列化能力使得，數據多了一個緩存方式。

代碼邏輯

event

事件的結構很簡單：

主要三個內容：

• queueName 隊列的名稱
• topic 消息的主題
• source 真正消息的內容

listener

主要使用了spring的applicationMulticast事件廣播,使用了模板方法的設計，下降耦合的同時，也大大的下降了業務實現的難度。

業務實現的邏輯，這裏使用內部類來對業務進行分類，防止太多的command出現

命令的接口類

reader

這裏將接口定義爲兩類：

• 持久化層
• 緩存層

利用修飾模式設計，共同被模板類依賴 

抽象類實現

這樣讓代碼編寫量大大減小
咱們來看下具體實現類：這樣的設計相比以前的要好了很多

測試中遇到的問題

• collection的大小限制

固定記錄數假如是100條，那麼對於collection來講就會存在被覆蓋的狀況。設置合理的長度很重要，目前設置爲2個G單collection。保證緩存當天的數據，即便線程卡住或者有其餘狀況，也能夠合理緩存。

• 線程等停頓位置

以前在設置線程停頓時，會在讀取過程當中，進行sleep。這樣就會對系統資源浪費，可是若是頻繁的輪訓又會出現一個問題，mongodb的連接資源浪費（頻繁請求）。綜上，採起的辦法是讀取有數據的時候就不休眠，在沒有數據的時候才進行200毫秒的等待。

你們能夠算一個帳，若是一次執行等待200毫秒，處理時間爲100豪秒/500條。那麼就會出現作500條等待200毫秒，一秒鐘只能處理1000 /（200+100）* 500=1500條數據，白白浪費了 400毫秒。因此須要改爲沒有數據再進行等待操做，若是有則不進行等待。