What’s new in Apache/dubbo-getty 1.5.0
经过半年改进,dubbo-getty 发布了 v1.5.0 版本,致力于提升稳定性,并修复已知问题,为用户提供更可靠的网络通信服务。
如昔,依然坚持 "Getty 只考虑使用 Go 语言原生的网络接口,如果遇到网络性能瓶颈也只会在自身层面寻找优化突破点" Go 语言网络库 getty 的那些事 。
1. 限制 TCP 客户端重连行为
Getty 支持 TCP lazy reconnect,所谓 lazy reconnect,Go 语言网络库 getty 的那些事 有详细描述。
lazy reconnect 整体流程图如上。
近期社区 No-SilverBullet 筒子觉得:服务端的连接数是动态的,所以我觉得 getty 还是应该有一个兜底的逻辑,而不是 "无脑的" 一直去重连,可以 "添加一个最多重来次数或者重连时间限制":
-
- 客户端在 read EOF 时,停止重连维护连接池的行为
-
- reconnect 增加最大次数,当重连次数超过设定的连接数时,退出
具体改进是:
-
- session 增加了新的 attribute(ignoreReconnectKey),用于标识是否重连
-
- 最大重连次数设定为用户设定的连接数
相关 PR 是 https://github.com/apache/dubbo-getty/pull/117。
2. 修复 WebSocket 并行安全问题
Getty WebSocket 通信依赖于 gorilla/websocket 这个包,进行 WebSocket 网络通信时只能 "支持一个并发 reader 和一个并发 writer"。
Connections support one concurrent reader and one concurrent writer. Applications are responsible for ensuring that no more than one goroutine calls the write methods (NextWriter, SetWriteDeadline, WriteMessage, WriteJSON, EnableWriteCompression, SetCompressionLevel) concurrently and that no more than one goroutine calls the read methods (NextReader, SetReadDeadline, ReadMessage, ReadJSON, SetPongHandler, SetPingHandler) concurrently. The Close and WriteControl methods can be called concurrently with all other methods. -- from https://pkg.go.dev/github.com/gorilla/websocket#hdr-Concurrency
Getty WebSocket 以往没有注意到这个规则,近期有人在 [issue 120] 中报出了这个 bug,社区筒子立即响应,添加了 gettyWSConn:threadSafeWriteMessage
和 gettyWSConn:threadSafeReadMessage 这两个接口以解决并行通信的 data race 问题,相关代码详见 PR 121 和 PR 123。
相关 PR 是:
https://github.com/apache/dubbo-getty/pull/121
https://github.com/apache/dubbo-getty/pull/123
在 PR 121 中我们顺便解决了 [issue 103] 描述的 session 异常关闭问题。
3 致谢
感谢所有为 Dubbo-Getty 1.5.0 做出贡献的社区成员,包括 issue/PR 提交者、代码 reviewer 以及文章作者【排名不分先后,依据字母序列】:
- chenbaoding2818
- FoghostCn
- Lvnszn
- No-SilverBullet
- seven-ali
alexstocks/getty 作为 dubbo-getty 的上游仓库,已在 alexstocks/gettyv1.5.0 中吸收了本次更新。
另外,我们搜到一些第三方作者对 getty 的解析文章,代表社区向这些传播 getty 的文章作者致敬:

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
开源日报 | 智谱开源GLM9B系列模型;FFmpeg社区委员会新成员是中国开发者;对“斯坦福抄袭中国大模型”事件的三重思考;昆仑万维开源天工MoE
欢迎阅读 OSCHINA 编辑部出品的开源日报,每天更新一期。 # 2024.6.5 今日要闻 悟空刘歧 (Steven Liu) 成为 FFmpeg 社区委员会成员 FFmpeg 项目今日在邮件列表正式官宣新的Community Committee 成员:Steven Liu。据悉这是首位成为 FFmpeg 社区委员会成员的亚洲人。 FFmpeg 社区委员会 (Community Committee) 目前共 5 名成员,主要职责是规范开发者在邮件列表与 IRC 频道上的行为,维持工作环境,仲裁调解开发者之间的纠纷,是社区建设相关最终决策者。 viahttps://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-June/328921.html Steven Liu 是中国开发者刘歧 —— 社区人称大师兄悟空。他是 FFmpeg 社区最活跃的贡献者之一,也是 FFmpeg 官方顾问,曾出版技术书籍《FFmpeg 从入门到精通》《深入理解 FFmpeg》。 智谱开源GLM9B系列模型 智谱开源了 GLM-4-9B 系列模型,包含基座模型、不同上...
- 下一篇
Pika 主从数据同步状态指标 “repl_connect_status” 简介
1 背景 PR #2638 合并后,Slave 超时后重新与 Master 建连,可能会有更长的时间处于 "connecting" 状态。此时主从已经建连成功,但若用户欲获取主从数据同步状态,只能查看日志,很不方便。 2 新增指标 "repl_connect_status" 为了方便用户或其他旁路系统实时获取 Pika 的数据同步状态,我们在 PR #2656 中新增了主从数据同步 info 命令指标 ”repl_connect_status“。 3 指标获取方式 向 Slave 端发送 info/info replication 命令进行获取,该值也会出现在 Slave 实例上,对 Master 发送 info 命令是取不到该指标的 4 指标格式 每个 db 均有自己的 repl_connect_status 值,以 \n 分隔,示例如下: repl_connect_status: db0:syncing_full db1:syncing_full db2:try_to_incr_sync db3:try_to_incr_sync db4:try_to_incr_sync db5:t...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题