之前的zinx框架 是1個鏈結對應1個reader和1個writer, 1個訊息對應乙個handler，如果說1個客戶端傳送10個訊息 1w客戶端 就10w訊息，—> 10w handler的go程來處理業務，cpu就會在10w handler之間進行切換，影響效能，這時就需要制定乙個worker處理業務的工作池的機制。
1.在msghandler中新增workpoolsize（工作池）和taskqueue（訊息佇列）
type msghandler struct
func
newmsghandler
() ziface.imsghandler
}
//乙個worker真正處理業務的 goroutine函式
func
(mh *msghandler)
startoneworker
(workerid int
, taskqueue chan ziface.irequest)
}}
type imsghandler inte***ce
//啟動worker工作池 (在整個server服務中 只啟動一次)
func
(mh *msghandler)
startworkerpool()
}//將訊息新增到worker工作池中 （將訊息傳送給對應的訊息佇列）
//應該是reader來呼叫的
func
(mh *msghandler)
sendmsgtotaskqueue
(request ziface.irequest)
這裡是用每個connection的id對工作池數量取餘得到乙個workerid，將request寫入taskqueue下標為workerid的channel中，這樣就相對來說實現了將request輪詢分配給每個工作池。4.在connection剛開始也就是還沒有監聽之前開啟工作池
func
(s *server)
start()
......
}
func
(c *connection)
startreader()
else
}}
Zinx v0 8訊息佇列和任務池
訊息佇列和任務池 原來乙個鏈結對應乙個reader和乙個writer，乙個訊息對應handler 原來客戶端發乙個message，伺服器會開闢乙個handler goroutine去處理業務。很多message會有很多handler goroutine 為了提高效能，要降低gorouine數量 手段...
訊息佇列屬性及常見訊息佇列介紹
訊息佇列是在訊息的傳輸過程中儲存訊息的容器，用於接收訊息並以檔案的方式儲存，乙個佇列的訊息可以同時被多個訊息消費者消費。分布式訊息服務dms則是分布式的佇列系統，訊息佇列中的訊息分布儲存，且每條訊息儲存多個副本，以實現高可用性，如下圖所示。一般來說，訊息佇列具有如下屬性 訊息順序 普通佇列支援 分割...
訊息佇列 分析及運用
訊息佇列特性為先進先出，底層實現是鍊錶，在核心中建立，有乙個訊息佇列的識別符號來表示，這個佇列當中的每乙個元素都有自己的型別，每乙個型別都有乙個優先順序概念 訊息佇列在作業系統屬性 msgmax 每乙個節點最大訊息的傳送位元組數為8 k msgmnb 佇列中所有訊息的長度之和 為 16 k msgm...