Go夜读 第 73 期趣头条在长链接方面的实践 - qrpc

mai_yang for Go 夜读 · 2020年02月13日 · 76 次阅读

文章来自于:https://reading.developerlearning.cn/reading/73-2019-12-28-qrpc/

分享者:徐志强 @ 趣头条

观看视频

【Go 夜读】#73 趣头条在长链接方面的实践-qrpc

qrpc 是一个小而强大的长链接框架,它包含了谷歌 grpc 的核心特性,但是更加轻量、高效、可扩展,从最早的推送中台长链接,到后来整个的 IM 中台,以及目前进行中的 qfe 长链接网关,正在朝着成为趣头条的长链接底座的方向发展。

大纲

1.为何qrpc 2.qrpc的特性和生态 3.qrpc的应用 4.qrpc核心的优化 5.qrpc的展望 6.pprof tips

分享者自我介绍

徐志强,开源爱好者,Cocos2dx、TiDB、GO contributor。 目前在趣头条的母公司比格基地担任架构师。 负责推送和 IM 中台,目前已经接入了多个日活 500-800w 的业务方。 研究兴趣点:网络 + 存储 + 高并发。

分享时间

2019-12-28 21:00 UTC+8

分享地址

https://zoom.us/j/6923842137

Slides

在线版 qrpc.pptx 需翻墙 离线版 qrpc-夜读.pptx


备注

Q:不用 epoll 怎么保持 80W 连接?

A:其实 go 内部所有连接都已经用 epoll(或者各平台对应物)接管了,自己再做集成的好处,是可以把闲置的协程释放掉

Q:IM 优雅重启时老进程不退出的原因?

A:老进程关闭所有端口后做 Shutdown,前面有个 bug,导致无法退出(较低概率出现),相关的 commit 是这个:https://github.com/zhiqiangxu/qrpc/commit/951759ff4f03b4c34d76092f634817444bbc2d35

Q:3 个协程如何优化成 2 个?

A:通过抢占锁的方式,抢到的一方再把其他的写请求接管过来,最后通过 writev 批量写,最终结果是内存和性能都有收获

Q:没有任何监听端口时的调试工具?

A:delve,谷歌官方推荐

Q:qrpc 是基于 http2 还是 tcp?

A:tcp,没有 http2 的历史包袱

Q:用 qrpc 写聊天工具是不是只要写 ui 就好了?

A:对,长链接部分会非常简单,不过由于 IM 涉及的接口繁多,还是需要开发很多的 restful 接口做存储

Q:串行、并行的区别

A:串行的话,前面的包处理完,后面的才会处理;并行的话,不会等前面的处理完就会开始执行

Q:TLS 可以集成吗?

A:规划中,也可以使用 TLS proxy 分担出去。

Q:并行模式下,包的顺序如何保证?

A:并行模式下,包的顺序没保证,可能后面的请求先返回了,请求/响应是通过 8 字节的 RequestID 进行关联

Q:socket 断了如何保证消息不丢?

A:IM 的消息都会做存储,客户端是推拉结合,重连后会跟 server 端进行同步

Q:如何维持心跳,是否需要重发机制?

A:qrpc 内部做了 tcp 层的心跳,业务层也可以做,通过周期地请求某个 CMD 即可实现。tcp 本身已经保证了可靠性,所以基于 tcp 做上层应用不需要考虑重发,除非连接断开了,那么下次重连会同步。

Q:push 的时候如何去重?

A:这个是客户端根据消息 ID 做的幂等处理

Q:路由怎么做?

A:一致性哈希或者路由表存起来,前者成本比较低,目前用一致性哈希

Q:目前遇到的主要挑战是?

A:正准备上聊天室,一天一亿条消息,并且聊天室里成员众多,实际写放大会很大,对长链会是个考验

Q:优雅重启时新老进程如何通信?

A:推荐 https://github.com/cloudflare/tableflip


暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册