刘丹冰

哈哈，好全，自己搞不定啊，有想法一起来建设呗。

> @aceld 刚好公司用的是tcp。新转行游戏后台一枚。吃透框架ing~ 到时候希望可以帮上忙建设。 @sun-wenming 非常欢迎！

README里有一个ws版本的，你可以参考一下。

ok,可以提PR哦~

可以尝试提交Pull request 。 在此感谢对zinx的关注~！

是一个好的建议，这样业务消息的可读性更好一些。

嗯是的，ztimer目前模块是独立的，没有集成到zinx框架接口中。 之后会加入到zinx接口中。提供一些延迟发包的功能

加消息队列也是为了限定处理业务worker的个数，并不能无限制的开辟goroutine，考虑到对于大并发的情况。

并不是，举个栗子。 比如现在有10W个客户端请求，那么我们之前如果不加消息队列和worker池机制，以目前的框架来讲是 会开30w个go(10w个reader，10w个writer，10w个处理消息业务的Handle)，其中Reader,Writer是读写客户端数据的，而且大部分时间是阻塞状态，并不会抢占调度器资源。但是10w个handle确实处理业务的，需要cpu计算，那么调度器需要在这10w的go之间进行切换，那么切换成本就浪费了cpu的利用率。 那么如果用worker机制，比如我们限定worker的数量就是8个(建议cpu核心也是8个)，那么还是这个例子，有10w的客户端请求过来，zinx会开辟(10w个reader[阻塞]，10W个writer[阻塞]，和8个worker用来调用Handle)，那么最终处理业务的go只有8个，调度器只需要在这8个之间切换就可以了，所以不管客户端请求数量多达，最后也是8个go在做真正的计算，大大节省了调度器的切换成本。

@rfyiamcool 多谢，我去pingcap项目去看看，学习一下