No-SilverBullet commented on issue #116: URL: https://github.com/apache/dubbo-getty/issues/116#issuecomment-2044282547
> Getty 中 session 代表一个网络连接，client 其实是一个网络连接池，维护一定数量的连接 session，这个数量当然是用户设定的。Getty client 初始版本【2018 年以前的版本】中，每个 client 单独启动一个 goroutine 轮询检测其连接池中 session 数量，如果没有达到用户设定的连接数量就向 server 发起新连接。 > > 当 client 与 server 连接断开时，server 可能是被下线了，可能是意外退出，也有可能是假死。如果上层用户判定对端 server 确实不存在【如收到注册中心发来的 server 下线通知】后，调用 client.Close() 接口把连接池关闭掉。如果上层用户没有调用这个接口把连接池关闭掉，client 就认为对端地址还有效，就会不断尝试发起重连，维护连接池。 > > 综上，从一个旧 session 关闭到创建一个新 session，getty client 初始版本的重连处理流程是： > > 1 旧 session 关闭网络接收 goroutine； > > 2 旧 session 网络发送 goroutine 探测到 网络接收 goroutine 退出后终止网络发送，进行资源回收后设定当前 session 无效； > > 3 client 的轮询 goroutine 检测到无效 session 后把它从 session 连接池删除； > > 4 client 的轮询 goroutine 检测到有效 session 数目少于 getty 上层使用者设定的数目 且 getty 上层使用者没有通过 client.Close() 接口关闭连接池时，就调用连接接口发起新连接。 > > 上面这种通过定时轮询方式不断查验 client 中 session pool 中每个 session 有效性的方式，可称之为主动连接。主动连接的缺点显然是每个 client 都需要单独启用一个 goroutine。当然，其进一步优化手段之一是可以启动一个全局的 goroutine，定时轮询检测所有 client 的 session pool，不必每个 client 单独启动一个 goroutine。但是个人从 2016 年开始一直在思考一个问题：能否换一种 session pool 维护方式，去掉定时轮询机制，完全不使用任何的 goroutine 维护每个 client 的 session pool？ > > 2018 年 5 月个人在一次午饭后遛弯时，把 getty client 的重连逻辑又重新梳理了一遍，突然想到了另一种方法，在步骤 2 中完全可以对 网络发送 goroutine 进行 “废物利用”，在这个 goroutine 标记当前 session 无效的逻辑步骤之后再加上一个逻辑： > > 1 如果当前 session 的维护者是一个 client【因为 session 的使用者也可能是 server】； > > 2 且如果其当前 session pool 的 session 数量少于上层使用者设定的 session number； > > 3 且如果上层使用者还没有通过 client.Close() 设定当前 session pool 无效【即当前 session pool 有效，或者说是对端 server 有效】 > > 4 满足上面三个条件，网络发送 goroutine 执行连接重连即可； > > 5 新网络连接 session 建立成功且被加入 client 的 session pool 后，网络发送 goroutine 使命完成直接退出。 > > 我把这种重连方式称之为 lazy reconnect，网络发送 goroutine 在其生命周期的最后阶段应该被称之为 网络重连 goroutine。通过 lazy reconnect这种方式，上述重连步骤 3 和 步骤 4 的逻辑被合入了步骤 2，client 当然也就没必要再启动一个额外的 goroutine 通过定时轮询的方式维护其 session pool 了。 > >  > > lazy reconnect 整体流程图如上。如果对相关代码流程感兴趣，请移步 "参考 13" 给出的链接，很容易自行分析出来。 > > 以上内容来自 [Go 语言网络库 getty 的那些事](https://mp.weixin.qq.com/s/z22k-E2ybjAMNtxzj5Aikw) 第三章。 > > 你先理解下，如果觉得机制不合理，我们可以在这个 issue 里面继续聊。 你好，感谢回复。在一个session失效之前去触发重连的逻辑，这种设计没有任何问题，可以节约goroutine。但是，如果连接存在问题，会持续的去重连，我的理解是这种行为是不合理的，会给客户端以及服务端都造成压力。这里对于无效session的区分是不是可以更细一点呢，当连接出现问题的时候就不再去重连。 -- 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: notifications-unsubscr...@dubbo.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org For additional commands, e-mail: notifications-h...@dubbo.apache.org
