>文章来自于：https://reading.developerlearning.cn/reading/73-2019-12-28-qrpc/
分享者：徐志强@趣头条
## 观看视频
https://youtu.be/Ug4i4IHhGh4
## 【Go 夜读】#73 趣头条在长链接方面的实践-qrpc
qrpc是一个小而强大的长链接框架，它包含了谷歌grpc的核心特性，但是更加轻量、高效、可扩展，从最早的推送中台长链接，到后来整个的IM中台，以及目前进行中的qfe长链接网关，正在朝着成为趣头条的长链接底座的方向发展。
## 大纲
1.为何[qrpc](https://github.com/zhiqiangxu/qrpc)
2.[qrpc](https://github.com/zhiqiangxu/qrpc)的特性和生态
3.[qrpc](https://github.com/zhiqiangxu/qrpc)的应用
4.[qrpc](https://github.com/zhiqiangxu/qrpc)核心的优化
5.[qrpc](https://github.com/zhiqiangxu/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](https://docs.google.com/presentation/d/18Gk2x2Fi3WdIGs2sfMtkA-NatbcD5wela80qaDwY-WE/edit?usp=sharing) 需翻墙
[离线版 qrpc-夜读.pptx](https://github.com/developer-learning/night-reading-go/files/3971489/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
---
有疑问加站长微信联系（非本文作者）
