訊息佇列和任務池
原來乙個鏈結對應乙個reader和乙個writer，乙個訊息對應handler
原來客戶端發乙個message，伺服器會開闢乙個handler goroutine去處理業務。很多message會有很多handler goroutine
為了提高效能，要降低gorouine數量
手段：讓處理業務的 handler goroutine和訊息無關
制定乙個worker處理業務
啟動一定數量的worker處理業務的go程，每個worker繫結乙個任務的佇列
能夠降低go的數量
記憶體節省
go排程器切換go的成本降低，更好利用cpu
比如1萬個reader和1萬個writer都是阻塞，並不會占用太多的cpu資源
訊息列隊及worker工作池的實現
建立訊息佇列
屬性訊息佇列
工作池的數量
type msghandler struct//初始化方法
func newmsghandler() ziface.imsghandler
}
啟動工作池：啟動固定數量的goroutine
//啟動worker工作池 (在整個server服務中 只啟動一次)
func (mh *msghandler) startworkerpool()
}
func (mh *msghandler) startoneworker(workerid int, taskqueue chan ziface.irequest)
}}
func (mh *msghandler) sendmsgtotaskqueue(request ziface.irequest)建立多工的worker工作池，並且啟動
啟動工作池：繫結worker和channel
將之前傳送的訊息，由reader呼叫handler過程變成 讓worker工作池來處理
//全域性計數器，記錄訊息的個數
修改全域性配置
工作池最大數量
訊息佇列的長度
修改connection
給訊息佇列傳送請求
if config.globalobject.workerpoolsize > 0 elseZinx V0 8訊息佇列及多工機制
之前的zinx框架 是1個鏈結對應1個reader和1個writer,1個訊息對應乙個handler，如果說1個客戶端傳送10個訊息 1w客戶端 就10w訊息，10w handler的go程來處理業務，cpu就會在10w handler之間進行切換，影響效能，這時就需要制定乙個worker處理業務的...
django celery 任務訊息佇列
描述 為提高 效能，很多耗時，但不影響頁面正常的操作，可丟給訊息佇列非同步執行 比如sns 的 新鮮事兒 系統，我發帖之後，會給所有關注我的人推送一條通知。乍一看沒什麼難的，發帖之後找出關注我的人，然後生成相應的訊息記錄就行了。但問題是，100個人關注我，就要執行100條insert查詢，更要命的是...
訊息和訊息佇列
在傳統的c 程式當中，我們呼叫 fopen 函式開啟檔案，這個庫函式最終呼叫作業系統 提供的函式 來開啟檔案。而在 windows 中，不僅使用者程式可以呼叫系統的 api函式，反回來，系統也會呼叫使用者程式，這個呼叫是通過訊息來進行的。windows程式設計是一種完全不同於傳統的 dos方式的程式...