你有同感吗？
当大家在开发服务端代码的时候，会不会经常有如下疑问？
- 纳闷 MySQL 连接池到底有多少连接？
- 每个连接的生命周期持续多久？
- 连接异常断开的时候到底是服务端主动断的，还是客户端主动断的？
- 当长时间没有请求的时候，底层库是否有 KeepAlive 请求？
复杂网络情况的处理从来都是后端开发的重点和难点之一，你是不是也为各种网络情况的调试而头顶发凉呢？
所以我写了 tproxy
当我在做后端开发和写 go-zero 的时候，经常会需要监控网络连接，分析请求内容。比如：
- 分析 gRPC 连接何时连接、何时重连，并据此调整各种参数，比如：MaxConnectionIdle
- 分析 MySQL 连接池，当前多少连接，连接的生命周期是什么策略
- 也可以用来观察和分析任何 TCP 连接，看服务端主动断，还是客户端主动断等等
tproxy 的安装
$ GOPROXY=https://goproxy.cn/,direct go install github.com/kevwan/tproxy@latest
或者使用 docker 镜像：
$ docker run --rm -it -p <listen-port>:<listen-port> -p <remote-port>:<remote-port> kevinwan/tproxy:v1 tproxy -l 0.0.0.0 -p <listen-port> -r host.docker.internal:<remote-port>
arm64 系统:
$ docker run --rm -it -p <listen-port>:<listen-port> -p <remote-port>:<remote-port> kevinwan/tproxy:v1-arm64 tproxy -l 0.0.0.0 -p <listen-port> -r host.docker.internal:<remote-port>
tproxy 的用法
$ tproxy --help
Usage of tproxy:
-d duration
the delay to relay packets
-l string
Local address to listen on (default "localhost")
-p int
Local port to listen on
-q Quiet mode, only prints connection open/close and stats, default false
-r string
Remote address (host:port) to connect
-t string
The type of protocol, currently support grpc
分析 gRPC 连接
tproxy -p 8088 -r localhost:8081 -t grpc -d 100ms
- 侦听在 localhost 和 8088 端口
- 重定向请求到
localhost:8081
- 识别数据包格式为 gRPC
- 数据包延迟100毫秒
![img]()
其中我们可以看到 gRPC 的一个请求的初始化和来回，可以看到第一个请求其中的 stream id 为 1。
再比如 gRPC 有个 MaxConnectionIdle 参数，用来设置 idle 多久该连接会被关闭，我们可以直接观察到时间到了之后服务端会发送一个 http2 的 GoAway 包。
![img]()
比如我把 MaxConnectioinIdle 设为 5 分钟，连接成功之后 5 分钟没有请求，连接就被自动关闭了，然后重新建了一个连接上来。
分析 MySQL 连接
我们来分析一下 MySQL 连接池设置对连接池的影响，比如我把参数设为：
maxIdleConns = 3
maxOpenConns = 8
maxLifetime = time.Minute
...
conn.SetMaxIdleConns(maxIdleConns)
conn.SetMaxOpenConns(maxOpenConns)
conn.SetConnMaxLifetime(maxLifetime)
我们把 MaxIdleConns 和 MaxOpenConns 设为不同值，然后我们用 hey 来做个压测：
hey -c 10 -z 10s "http://localhost:8888/lookup?url=go-zero.dev"
我们做了并发为10QPS且持续10秒钟的压测，连接结果如下图：
![img]()
我们可以看到：
- 10秒钟内建立了2000+的连接
- 过程中在不停的关闭已有连接，重开新的连接
- 每次连接使用完放回去，可能超过 MaxIdleConns 了，然后这个连接就会被关闭
- 接着来新请求去拿连接时，发现连接数小于 MaxOpenConns，但是没有可用请求了，所以就又新建了连接
这也就是我们经常会看到 MySQL 很多 TIME_WAIT 的原因。
然后我们把 MaxIdleConns 和 MaxOpenConns 设为相同值，然后再来做一次相同的压测：
![img]()
我们可以看到：
- 一直维持着8个连接不变
- 压测完过了一分钟（ConnMaxLifetime），所有连接被关闭了
这里的 ConnMaxLifetime 一定要设置的小于 wait_timeout，可以通过如下方式查看 wait_timeout 值：
![img]()
我建议设置小于5分钟的值，因为有些交换机会5分钟清理一下空闲连接，比如我们在做社交的时候，一般心跳包不会超过5分钟。具体原因可以看
https://github.com/zeromicro/go-zero/blob/master/core/stores/sqlx/sqlmanager.go#L65
其中 go-sql-driver 的 issue 257 里有一段也在说 ConnMaxLifetime，如下：
> 14400 sec is too long. One minutes is enough for most use cases. > > Even if you configure entire your DC (OS, switch, router, etc...), TCP connection may be lost from various reasons. (bug in router firmware, unstable power voltage, electric nose, etc...)
所以如果你不知道 MySQL 连接池参数怎么设置，可以参考 go-zero 的设置。
另外，ConnMaxIdleTime 对上述压测结果没有影响，其实你也不需要设置它。
如果你对上述设置有疑问，或者觉得哪里有误，欢迎在 go-zero 群里一起讨论。
项目地址
tproxy: https://github.com/kevwan/tproxy
go-zero:
https://github.com/zeromicro/go-zero
https://gitee.com/kevwan/go-zero
欢迎使用并 star 支持我们！
微信交流群
关注『微服务实践』公众号并点击 交流群 获取社区群二维码。</remote-port></listen-port></remote-port></remote-port></listen-port></listen-port></remote-port></listen-port></remote-port></remote-port></listen-port></listen-port>
