Feature/dynamic bind: 增加DynamicBind工作池模式,类似于Bind工作池模式,每个连接绑定一个worker, 但不像Bind模式那样会闲置很多worker#339
Conversation
|
首先肯定
|
|
建议增加 max_idle_worker 机制,避免 worker 频繁创建和销毁的开销。 |
Dynamic Bind模式下,配置参数“WorkerPoolSize” 就是预启动的worker数量,也是worker最小数量,配置参数“MaxConn”是最大worker数量 |
确实可以复用 |
There was a problem hiding this comment.
handle := &MsgHandle{
Apis: make(map[uint32]ziface.IRouter),
RouterSlices: NewRouterSlices(),
WorkerPoolSize: zconf.GlobalObject.WorkerPoolSize,
// One worker corresponds to one queue (一个worker对应一个queue)
TaskQueue: make([]chan ziface.IRequest, TaskQueueLen),
freeWorkers: freeWorkers,
builder: newChainBuilder(),
// 可额外临时分配的workerID集合
extraFreeWorkers: extraFreeWorkers,
}中,TaskQueue: make([]chan ziface.IRequest, TaskQueueLen), 能否做 zconf.GlobalObject.WorkerMode == zconf.WorkerModeDynamicBind 的区分,这样不会影响到之前的WorkerBind模式。
There was a problem hiding this comment.
TaskQueue 的长度 TaskQueueLen 已经有针对DynamicBind 模式的区分
There was a problem hiding this comment.

在 StartOneWorker() 中,对于!ok的处理,要不也加上模式的区分,否则会不会全部的管道读取错误都会归类到当前模式worker的关闭,这个还不确定。 @jursonmo
There was a problem hiding this comment.
一旦关闭queue,不管什么模式下,worker都应该退出的,不然一直能从queue读到一个空的request。
具体实现: DynamicBind 模式 也是一个连接对应一个worker, 给新连接分配worker时, 优先从已初始化好的工作池里取,如果工作池里的worker已经用完了,没有空闲的worker,就动态创建一个worker绑定到每个连接。这个临时创建的worker, 会在连接断开后销毁。