yanglimingcn commented on PR #2177:
URL: https://github.com/apache/brpc/pull/2177#issuecomment-2888680043

   > > 
备用Socket这里还有个问题,采用什么连接策略?比如原来是单连接,那么备用Socket也是单连接,还是说退化成一个临时的短连接?如果备用Socket也是单连接,管理起来比较复杂,如果退化成短连接,可能会导致性能下降或给后端带来太大压力?
   > 
   > 备用Socket还是通过SelectOut::ptr返回给调用方。调用方将其当做main 
socket用。连接策略是由调用方使用方式决定即可。在调用方看来,备用Socket应该跟naming 
service下发的Socket并无区别。应该可以加多一个备用Socket的SocketMap,相同Channel不用LB复用Socket,连接数不会增加很多,不会给后端带来太大压力。
   > 
   > 相比之下,SingleSocketPool的方案更好,将Socket管理逻辑收敛到main 
socket中,LB只需要实现恐慌策略,简化LB的实现逻辑,这样对于用户定义的LB更友好。
   > 
   > > 怎么判断实例是完全不可用呢?比如某一次连接ECONNREFUSED,后面再连有可能就成功了
   > 
   > Failed Socket在健康检查成功之前可以看作是不可用吧。如果是能连成功的话,健康检查成功,就Socket就会恢复了。
   > 
   > SingleSocketPool的方案将屏蔽状态和连接状态区分开来,更清晰了。
   > 
   > > 我在想能不能把SocketPool的逻辑稍微改一下,变成SingleSocketPool:
   > > GetSocket的逻辑: 如果pool里能找到不是Failed状态的Socket,就返回该Socket,且不从pool中删除 
如果找到Failed状态的Socket,就从pool中删除 如果找不到可用的Socket,就新建一个Socket,并加入到Pool中,然后返回该Socket。
   > > RPC连接的时候,对于单连接的情况,不再使用main socket进行交互,而是从main 
socket的SingleSocketPool中获取Socket。
   > > 这样就是main socket的Failed状态表示屏蔽状态,和LB的现有逻辑兼容,然后socket pool中的socket的状态表示连接状态。
   > 
   > 
这个方案看起来可行,可以将SocketPool(或许得改了名字,不应该叫SocketPool了)抽象成基类,各个连接模式(single、pooled、short和待支持的multi
 #536)实现对应的SocketPool。或许single跟目前的short一样,单独实现一个函数即可。
   > 
   > 以下是当前的方案:
   > 
   > 1. 
抽象SocketPool为基类,各个连接模式(single、pooled、short和待支持的multi)实现对应的SocketPool。main 
socket的状态是屏蔽状态,SocketPool的sub socket是连接状态。sub socket的一些Failed连接状态会使得main 
socket屏蔽状态变成Failed。
   > 2. 正常模式下,LB屏蔽Failed main socket。当全部main socket都是Failed,返回第一次选到实例的main 
socket。
   > 3. RPC AddressFailedAsWell(main socket)后,根据连接模式,获取sub socket进行通信。
   > 
   > @wwbmmm 还有什么补充的吗?
   
   这个方案的pr啥时候提出了?


-- 
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

Reply via email to