本文来自知乎官方技术团队的“知乎技术专栏”，感谢原作者faceair的无私分享。
1、引言
实时的响应总是让人兴奋的，就如你在微信里看到对方正在输入，如你在王者峡谷里一呼百应，如你们在直播弹幕里不约而同的 666，它们的背后都离不开长连接技术的加持。
每个互联网公司里几乎都有一套长连接系统，它们被应用在消息提醒、即时通讯、推送、直播弹幕、游戏、共享定位、股票行情等等场景。而当公司发展到一定规模，业务场景变得更复杂后，更有可能是多个业务都需要同时使用长连接系统。
业务间分开设计长连接会导致研发和维护成本陡增、浪费基础设施、增加客户端耗电、无法复用已有经验等等问题。共享长连接系统又需要协调好不同系统间的认证、鉴权、数据隔离、协议拓展、消息送达保证等等需求，迭代过程中协议需要向前兼容，同时因为不同业务的长连接汇聚到一个系统导致容量管理的难度也会增大。
经过了一年多的开发和演进，经过我们服务面向内和外的数个 App、接入十几个需求和形态各异的长连接业务、数百万设备同时在线、突发大规模消息发送等等场景的锤炼，我们提炼出一个长连接系统网关的通用解决方案，解决了多业务共用长连接时遇到的种种问题。
知乎长连接网关致力于业务数据解耦、消息高效分发、解决容量问题，同时提供一定程度的消息可靠性保证。
（本文同步发布于：http://www.52im.net/thread-2737-1-1.html）
2、相关文章
3、我们怎么设计通讯协议？
3.1 业务解耦
支撑多业务的长连接网关实际上是同时对接多客户端和多业务后端的，是多对多的关系，他们之间只使用一条长连接通讯。
这种多对多的系统在设计时要避免强耦合。业务方逻辑也是会动态调整的，如果将业务的协议和逻辑与网关实现耦合会导致所有的业务都会互相牵连，协议升级和维护都会异常困难。
所以我们尝试使用经典的发布订阅模型来解耦长连接网关跟客户端与业务后端，它们之间只需要约定 Topic 即可自由互相发布订阅消息。传输的消息是纯二进制数据，网关也无需关心业务方的具体协议规范和序列化方式。
3.2 权限控制
我们使用发布订阅解耦了网关与业务方的实现，我们仍然需要控制客户端对 Topic 的发布订阅的权限，避免有意或无意的数据污染或越权访问。
假如讲师正在知乎 Live 的 165218 频道开讲，当客户端进入房间尝试订阅 165218 频道的 Topic 时就需要知乎 Live 的后端判断当前用户是否已经付费。这种情况下的权限实际上是很灵活的，当用户付费以后就能订阅，否则就不能订阅。权限的状态只有知乎 Live 业务后端知晓，网关无法独立作出判断。
所以我们在 ACL 规则中设计了基于回调的鉴权机制，可以配置 Live 相关 Topic 的订阅和发布动作都通过 HTTP 回调给 Live 的后端服务判断。
同时根据我们对内部业务的观察，大部分场景下业务需要的只是一个当前用户的私有 Topic 用来接收服务端下发的通知或消息，这种情况下如果让业务都设计回调接口来判断权限会很繁琐。
所以我们在 ACL 规则中设计了 Topic 模板变量来降低业务方的接入成本，我们给业务方配置允许订阅的 Topic 中包含连接的用户名变量标识，表示只允许用户订阅或发送消息到自己的 Topic。
此时网关可以在不跟业务方通信的情况下，独立快速判断客户端是否有权限订阅或往 Topic 发送消息。
3.3 消息可靠性保证
网关作为消息传输的枢纽，同时对接业务后端和客户端，在转发消息时需要保证消息在传输过程的可靠性。
TCP 只能保证了传输过程中的顺序和可靠性，但遇到 TCP 状态异常、客户端接收逻辑异常或发生了 Crash 等等情况时，传输中的消息就会发生丢失。
为了保证下发或上行的消息被对端正常处理，我们实现了回执和重传的功能。重要业务的消息在客户端收到并正确处理后需要发送回执，而网关内暂时保存客户端未收取的消息，网关会判断客户端的接收情况并尝试再次发送，直到正确收到了客户端的消息回执。
而面对服务端业务的大流量场景，服务端发给网关的每条消息都发送回执的方式效率较低，我们也提供了基于消息队列的接收和发送方式，后面介绍发布订阅实现时再详细阐述。
在设计通讯协议时我们参考了 MQTT 规范（详见《扫盲贴：认识MQTT通信协议》），拓展了认证和鉴权设计，完成了业务消息的隔离与解耦，保证了一定程度的传输可靠性。同时保持了与 MQTT 协议一定程度上兼容，这样便于我们直接使用 MQTT 的各端客户端实现，降低业务方接入成本。
4、我们怎么设计系统架构？
在设计项目整体架构时，我们优先考虑的是：
- 1）可靠性；
- 2）水平扩展能力；
- 3）依赖组件成熟度；
- 4）简单才值得信赖。
为了保证可靠性，我们没有考虑像传统长连接系统那样将内部数据存储、计算、消息路由等等组件全部集中到一个大的分布式系统中维护，这样增大系统实现和维护的复杂度。我们尝试将这几部分的组件独立出来，将存储、消息路由交给专业的系统完成，让每个组件的功能尽量单一且清晰。
同时我们也需要快速地水平扩展能力。互联网场景下各种营销活动都可能导致连接数陡增，同时发布订阅模型系统中下发消息数会随着 Topic 的订阅者的个数线性增长，此时网关暂存的客户端未接收消息的存储压力也倍增。将各个组件拆开后减少了进程内部状态，我们就可以将服务部署到容器中，利用容器来完成快速而且几乎无限制的水平扩展。
最终设计的系统架构如下图：
系统主要由四个主要组件组成：
- 1）接入层使用 OpenResty 实现，负责连接负载均衡和会话保持；
- 2）长连接 Broker，部署在容器中，负责协议解析、认证与鉴权、会话、发布订阅等逻辑；
- 3）Redis 存储，持久化会话数据；
- 4）Kafka 消息队列，分发消息给 Broker 或业务方。
其中 Kafka 和 Redis 都是业界广泛使用的基础组件，它们在知乎都已平台化和容器化 (详见：《Redis at Zhihu》、《知乎基于 Kubernetes 的 Kafka 平台的设计和实现》)，它们也都能完成分钟级快速扩容。
5、我们如何构建长连接网关？
5.1 接入层
OpenResty 是业界使用非常广泛的支持 Lua 的 Nginx 拓展方案，灵活性、稳定性和性能都非常优异，我们在接入层的方案选型上也考虑使用 OpenResty。
接入层是最靠近用户的一侧，在这一层需要完成两件事：
- 1）负载均衡，保证各长连接 Broker 实例上连接数相对均衡；
- 2）会话保持，单个客户端每次连接到同一个 Broker，用来提供消息传输可靠性保证。
负载均衡其实有很多算法都能完成，不管是随机还是各种 Hash 算法都能比较好地实现，麻烦一些的是会话保持。
常见的四层负载均衡策略是根据连接来源 IP 进行一致性 Hash，在节点数不变的情况下这样能保证每次都 Hash 到同一个 Broker 中，甚至在节点数稍微改变时也能大概率找到之前连接的节点。
之前我们也使用过来源 IP Hash 的策略，主要有两个缺点：
- 1）分布不够均匀，部分来源 IP 是大型局域网 NAT 出口，上面的连接数多，导致 Broker 上连接数不均衡；
- 2）不能准确标识客户端，当移动客户端掉线切换网络就可能无法连接回刚才的 Broker 了。
所以我们考虑七层的负载均衡，根据客户端的唯一标识来进行一致性 Hash，这样随机性更好，同时也能保证在网络切换后也能正确路由。常规的方法是需要完整解析通讯协议，然后按协议的包进行转发，这样实现的成本很高，而且增加了协议解析出错的风险。
最后我们选择利用 Nginx 的 preread 机制实现七层负载均衡，对后面长连接 Broker 的实现的侵入性小，而且接入层的资源开销也小。
Nginx 在接受连接时可以指定预读取连接的数据到 preread buffer 中，我们通过解析 preread buffer 中的客户端发送的第一个报文提取客户端标识，再使用这个客户端标识进行一致性 Hash 就拿到了固定的 Broker。
5.2 发布与订阅
我们引入了业界广泛使用的消息队列 Kafka 来作为内部消息传输的枢纽。
前面提到了一些这么使用的原因：
- 1）减少长连接 Broker 内部状态，让 Broker 可以无压力扩容；
- 2）知乎内部已平台化，支持水平扩展。
还有一些原因是：
- 1）使用消息队列削峰，避免突发性的上行或下行消息压垮系统；
- 2）业务系统中大量使用 Kafka 传输数据，降低与业务方对接成本。
其中利用消息队列削峰好理解，下面我们看一下怎么利用 Kafka 与业务方更好地完成对接。
5.3 发布
连接 Broker 会根据路由配置将消息发布到 Kafka Topic，同时也会根据订阅配置去消费 Kafka 将消息下发给订阅客户端。
路由规则和订阅规则是分别配置的，那么可能会出现四种情况。
情况一：消息路由到 Kafka Topic，但不消费，适合数据上报的场景，如下图所示。
情况二：消息路由到 Kafka Topic，也被消费，普通的即时通讯场景，如下图所示。
情况三：直接从 Kafka Topic 消费并下发，用于纯下发消息的场景，如下图所示。
情况四：消息路由到一个 Topic，然后从另一个 Topic 消费，用于消息需要过滤或者预处理的场景，如下图所示。
这套路由策略的设计灵活性非常高，可以解决几乎所有的场景的消息路由需求。同时因为发布订阅基于 Kafka，可以保证在处理大规模数据时的消息可靠性。
5.4 订阅
当长连接 Broker 从 Kafka Topic 中消费出消息后会查找本地的订阅关系，然后将消息分发到客户端会话。
我们最开始直接使用 HashMap 存储客户端的订阅关系。当客户端订阅一个 Topic 时我们就将客户端的会话对象放入以 Topic 为 Key 的订阅 Map 中，当反查消息的订阅关系时直接用 Topic 从 Map 上取值就行。
因为这个订阅关系是共享对象，当订阅和取消订阅发生时就会有连接尝试操作这个共享对象。为了避免并发写我们给 HashMap 加了锁，但这个全局锁的冲突非常严重，严重影响性能。
最终我们通过分片细化了锁的粒度，分散了锁的冲突。
本地同时创建数百个 HashMap，当需要在某个 Key 上存取数据前通过 Hash 和取模找到其中一个 HashMap 然后进行操作，这样将全局锁分散到了数百个 HashMap 中，大大降低了操作冲突，也提升了整体的性能。
5.5 会话持久化
当消息被分发给会话 Session 对象后，由 Session 来控制消息的下发。
Session 会判断消息是否是重要 Topic 消息， 是的话将消息标记 QoS 等级为 1，同时将消息存储到 Redis 的未接收消息队列，并将消息下发给客户端。等到客户端对消息的 ACK 后，再将未确认队列中的消息删除。
有一些业界方案是在内存中维护了一个列表，在扩容或缩容时这部分数据没法跟着迁移。也有部分业界方案是在长连接集群中维护了一个分布式内存存储，这样实现起来复杂度也会变高。
我们将未确认消息队列放到了外部持久化存储中，保证了单个 Broker 宕机后，客户端重新上线连接到其他 Broker 也能恢复 Session 数据，减少了扩容和缩容的负担。
5.6 滑动窗口
在发送消息时，每条 QoS 1 的消息需要被经过传输、客户端处理、回传 ACK 才能确认下发完成，路径耗时较长。如果消息量较大，每条消息都等待这么长的确认才能下发下一条，下发通道带宽不能被充分利用。
为了保证发送的效率，我们参考 TCP 的滑动窗口设计了并行发送的机制（详见：《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》）。我们设置一定的阈值为发送的滑动窗口，表示通道上可以同时有这么多条消息正在传输和被等待确认。
我们应用层设计的滑动窗口跟 TCP 的滑动窗口实际上还有些差异。
TCP 的滑动窗口内的 IP 报文无法保证顺序到达，而我们的通讯是基于 TCP 的所以我们的滑动窗口内的业务消息是顺序的，只有在连接状态异常、客户端逻辑异常等情况下才可能导致部分窗口内的消息乱序。
因为 TCP 协议保证了消息的接收顺序，所以正常的发送过程中不需要针对单条消息进行重试，只有在客户端重新连接后才对窗口内的未确认消息重新发送。消息的接收端同时会保留窗口大小的缓冲区用来消息去重，保证业务方接收到的消息不会重复。
我们基于 TCP 构建的滑动窗口保证了消息的顺序性同时也极大提升传输的吞吐量。
6、写在最后
知乎长连接网关由基础架构组 (Infra) 开发和维护，主要贡献者是@faceair、@安江泽 。
基础架构组负责知乎的流量入口和内部基础设施建设，对外我们奋斗在直面海量流量的的第一战线，对内我们为所有的业务提供坚如磐石的基础设施，用户的每一次访问、每一个请求、内网的每一次调用都与我们的系统息息相关。
附录：更多网络编程相关资料
[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》
《通俗易懂-深入理解TCP协议（上）：理论基础》
《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《UDP中一个包的大小最大能多大？》
《P2P技术详解(一)：NAT详解——详细原理、P2P简介》
《P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解》
《P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解》
《通俗易懂：快速理解P2P技术中的NAT穿透原理》
《高性能网络编程(一)：单台服务器并发TCP连接数到底可以有多少》
《高性能网络编程(二)：上一个10年，著名的C10K并发连接问题》
《高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了》
《高性能网络编程(四)：从C10K到C10M高性能网络应用的理论探索》
《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》
《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》
《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》
《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》
《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》
《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》
《不为人知的网络编程(五)：UDP的连接性和负载均衡》
《不为人知的网络编程(六)：深入地理解UDP协议并用好它》
《不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》
《不为人知的网络编程(八)：从数据传输层深度解密HTTP》
《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
《网络编程懒人入门(三)：快速理解TCP协议一篇就够》
《网络编程懒人入门(四)：快速理解TCP和UDP的差异》
《网络编程懒人入门(五)：快速理解为什么说UDP有时比TCP更有优势》
《网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门》
《网络编程懒人入门(七)：深入浅出，全面理解HTTP协议》
《网络编程懒人入门(八)：手把手教你写基于TCP的Socket长连接》
《网络编程懒人入门(九)：通俗讲解，有了IP地址，为何还要用MAC地址？》
《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《聊聊iOS中网络编程长连接的那些事》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》
《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》
《脑残式网络编程入门(二)：我们在读写Socket时，究竟在读写什么？》
《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》
《脑残式网络编程入门(四)：快速理解HTTP/2的服务器推送(Server Push)》
《脑残式网络编程入门(五)：每天都在用的Ping命令，它到底是什么？》
《脑残式网络编程入门(六)：什么是公网IP和内网IP？NAT转换又是什么鬼？》
《以网游服务端的网络接入层设计为例，理解实时通信的技术挑战》
《迈向高阶：优秀Android程序员必知必会的网络基础》
《全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等》
《美图App的移动端DNS优化实践：HTTPS请求耗时减小近半》
《Android程序员必知必会的网络通信传输层协议——UDP和TCP》
《IM开发者的零基础通信技术入门(一)：通信交换技术的百年发展史(上)》
《IM开发者的零基础通信技术入门(二)：通信交换技术的百年发展史(下)》
《IM开发者的零基础通信技术入门(三)：国人通信方式的百年变迁》
《IM开发者的零基础通信技术入门(四)：手机的演进，史上最全移动终端发展史》
《IM开发者的零基础通信技术入门(五)：1G到5G，30年移动通信技术演进史》
《IM开发者的零基础通信技术入门(六)：移动终端的接头人——“基站”技术》
《IM开发者的零基础通信技术入门(七)：移动终端的千里马——“电磁波”》
《IM开发者的零基础通信技术入门(八)：零基础，史上最强“天线”原理扫盲》
《IM开发者的零基础通信技术入门(九)：无线通信网络的中枢——“核心网”》
《IM开发者的零基础通信技术入门(十)：零基础，史上最强5G技术扫盲》
《IM开发者的零基础通信技术入门(十一)：为什么WiFi信号差？一文即懂！》
《IM开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！》
《IM开发者的零基础通信技术入门(十三)：为什么手机信号差？一文即懂！》
《IM开发者的零基础通信技术入门(十四)：高铁上无线上网有多难？一文即懂！》
《IM开发者的零基础通信技术入门(十五)：理解定位技术，一篇就够》
《百度APP移动端网络深度优化实践分享(一)：DNS优化篇》
《百度APP移动端网络深度优化实践分享(二)：网络连接优化篇》
《百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇》
《技术大牛陈硕的分享：由浅入深，网络编程学习经验干货总结》
《可能会搞砸你的面试：你知道一个TCP连接上能发起多少个HTTP请求吗？》
《知乎技术分享：知乎千万级并发的高性能长连接网关技术实践》
>> 更多同类文章 ……
[2] NIO异步网络编程资料：
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《有关“为何选择Netty”的11个疑问及解答》
《开源NIO框架八卦——到底是先有MINA还是先有Netty?》
《选Netty还是Mina：深入研究与对比（一）》
《选Netty还是Mina：深入研究与对比（二）》
《NIO框架入门(一)：服务端基于Netty4的UDP双向通信Demo演示》
《NIO框架入门(二)：服务端基于MINA2的UDP双向通信Demo演示》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
《Netty 4.x学习（一）：ByteBuf详解》
《Netty 4.x学习（二）：Channel和Pipeline详解》
《Netty 4.x学习（三）：线程模型详解》
《Apache Mina框架高级篇（一）：IoFilter详解》
《Apache Mina框架高级篇（二）：IoHandler详解》
《MINA2 线程原理总结（含简单测试实例）》
《Apache MINA2.0 开发指南（中文版）[附件下载]》
《MINA、Netty的源代码（在线阅读版）已整理发布》
《解决MINA数据传输中TCP的粘包、缺包问题（有源码）》
《解决Mina中多个同类型Filter实例共存的问题》
《实践总结：Netty3.x升级Netty4.x遇到的那些坑（线程篇）》
《实践总结：Netty3.x VS Netty4.x的线程模型》
《详解Netty的安全性：原理介绍、代码演示（上篇）》
《详解Netty的安全性：原理介绍、代码演示（下篇）》
《详解Netty的优雅退出机制和原理》
《NIO框架详解：Netty的高性能之道》
《Twitter：如何使用Netty 4来减少JVM的GC开销（译文）》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《Netty干货分享：京东京麦的生产级TCP网关技术实践总结》
《新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析》
《写给初学者：Java高性能NIO框架Netty的学习方法和进阶策略》
《少啰嗦！一分钟带你读懂Java的NIO和经典IO的区别》
《史上最强Java NIO入门：担心从入门到放弃的，请读这篇！》
《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》
>> 更多同类文章 …
（本文同步发布于：http://www.52im.net/thread-2737-1-1.html）