yanglimingcn commented on PR #2358:
URL: https://github.com/apache/brpc/pull/2358#issuecomment-1737255624
> 上面提了一些小问题。 另外想探讨一下整体的设计：
>
> 1.
目前看来Server端分tag需要依赖于Client端设置connection_group，在Socket中把tag相关信息传过来。但是这样的话存在问题：
>
> * 修改了通信协议，强依赖于支持该特性的Client，无法兼容以前的Client
这块其实现在是能兼容原有协议的，只是新Client能交互tag信息，server端拿到信息可以用来区分不同tag的woker组。如果旧的Client发送消息，因为没有PTAG这个包，请求就会在默认的那个worker池子里面执行，就像现在只有一个woker组一样。
> * 让Client来决定Server的worker tag是否合理？按理说worker
tag应该由server端的业务逻辑决定。如果server想要调整worker tag，还需要修改所有的Client，这也不方便吧
这块其实不是让Client决定Server的tag数量，Server根据自身服务的接口来决定tag的数量，Client端要是想把请求按照预期划分开到Server不同的worker组处理，就需要按照Server的规则去设置connection_group去访问Server。
> 针对这个问题，我的建议是这样：
> * 对于请求处理逻辑中的隔离，可以在用户callback里，自己指定tag调用bthread_start_xxx来将任务发送到指定的worker
> * 对于IO的隔离，可以考虑按照端口来隔离，不同端口的Server指定不同的tag。
其实一开始也想要这么去做的，但是感觉性能上会有些损失，bthread_start_xxx将任务发送到指定的worker上会有线程间的交互，不如现在这种任务解析出来到放到thread
local的worker上去了。最终其实还是希望能做到Run To Complete。
> * 可以把bthread支持多tag和brpc支持多tag的PR分成两个，我理解前者更没有争议一些
这个可以的
> 2.
关于bthread支持多tag，是否考虑支持不同的tag指定不同的worker数量呢？毕竟不同tag执行的业务逻辑性质会有较大的差异，对worker数量的需求应该是不一样的
这个不太好做，目前就是依赖把bthread_min_concurrency配置成非0，让服务自动调整worker线程的数量。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For additional commands, e-mail: dev-h...@brpc.apache.org
