wwbmmm commented on PR #2177: URL: https://github.com/apache/brpc/pull/2177#issuecomment-2764377680
> > 解决该问题的根本办法是将单连接的main socket和rpc通信的socket进行拆分（有点类似于只有一个连接的连接池），当rpc通信socket SetFailed之后，可以从main socket新建新的socket进行连接，但这个方案对brpc的改动较大。 > > 我思考过这个方案，改动很大且复杂。 > > 或许可以从LB的角度来实现，ServerId增加EndPoint字段，在E112期间构造出备用Socket（管理策略得再详细设计一下）来进行通信了，这样实现会简单很多。 > > LB选实例的时候，记录下第一次选到的实例EndPoint，用于E112的时候通信。另外，在E112期间，也能保持一定的负载均衡。更近一步，或许可以参考[Envoy的恐慌策略](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/panic_threshold)，当不可用实例比例超过阈值，使能恐慌策略。但是Envoy的连接的实现跟bRPC Socket的实现不一样，所以恐慌策略不一定合适，得做一些权衡。 > > @wwbmmm 有空看看这个方案可行性？ 嗯，其实引入恐慌策略是比较合理的，只是因为brpc把Socket和LB耦合在一起了，导致实现起来比较麻烦。 > 或许可以从LB的角度来实现，ServerId增加EndPoint字段，在E112期间构造出备用Socket（管理策略得再详细设计一下）来进行通信了，这样实现会简单很多。 好像从已有的Failed的Socket上也能够获取到EndPoint字段？ 我觉得关键问题在于，需要区分Socket的连接状态和屏蔽状态，LB看的是屏蔽状态，实际连接的时候，再看连接状态，如果连接状态是Failed时再启动备用连接之类的。 -- 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
