第 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

分享地址

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