Ma Zheng
Ma Zheng
问下啊 这个问题解决了么，用max request NUM主要是为了内存泄漏 > tars的确会对swoole进程进行监控，使用max_request参数的原因是？
  我现在是这么做的参考了grpc，service代表一个服务（游戏场景下可以是一个业务模块）,rpc是服务里得一个方法（对应业务模块里得一个接口）,收发的都是NetPacket包，真正的rpc里得req包在Data字段里。uri是service+rpc的形式，用于路由到对应的handler了。  这样使用起来就方便多了。
包前两位是msgid和lenth把。你只把body部分发过去了。
感觉source和target整反了 source target我理解是生成的sql是srouce-->target，现在结果相反。
这属于逻辑层了。
> 首先，感谢您的issues~ context其实是存在一些争议的，go核心开发者ianlancetaylor专门开了个issue(28342)，记录了当前context的问题； [golang/go#28342](https://github.com/golang/go/issues/28342) > > 尽管有很多的争议，但是在很多场景下，使用context会很方便，所以现在它在go生态圈中比较活跃，包括很多的web应用框架，几乎是标配； 如果我们遇到了以下的场景，是可以考虑使用context的： 1.上下文信息传递，比如处理http请求，在请求处理链路上传递信息； 2.控制子goroutine的运行； 3.超时控制的方法调用； 4.可以取消的方法调用； 通常开发中我们用context来控制子协程的运行会多一点； > > 关于zinx： 1.目前zinx涉猎的是tcp的框架，一条请求一般会把所有的消息绑在request上， 如果从上下文信息传递的方面考虑出发，这里你也可以理解request其实就是zinx里的context； 2.zinx的业务框架处理模式是worker工作池的模式，后续如果会有控制子协程的调度需求，是可以考虑添加context呢~ 了解，那其实和我们公司框架有点类似，区别是我们公司反过来，是req绑定在ctx里。context作为一个天然的balckboard
> 请问这个callback是加载 server 对 client的socket 执行Close()之后么 ， client是否还需要添加对close()之后的callBack？ 对，server执行conn.close时，可以在ICONECTION里提供给业务层一个STOP方法来执行所有callback和conn的close。业务层不要直接操作 conn的close。
同意，可以把空值存进去，类似布隆过滤器的效果
可行
https://www.yuque.com/aceld/tsgooa/sbvzgczh3hqz8q3l 就类似这种使用文档，按核心模块划分的