本文由腾讯技术团队peter分享，原题“腾讯网关TGW架构演进之路”，下文进行了排版和内容优化等。

1、引言

TGW全称Tencent Gateway，是一套实现多网统一接入，支持自动负载均衡的系统， 是公司有10+年历史的网关，因此TGW也被称为公司公网的桥头堡。

本文从腾讯公网TGW网关系统的应用场景、背景需求讲起，重点解析了从山海1.0架构到山海2.0架构需要解决的问题和架构规划与设计实现，以及对于未来TGW山海网关的发展和演进方向。

 

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4641-1-1.html）

2、专题目录

本文是专题系列文章的第11篇，总目录如下：

1. 《长连接网关技术专题(一)：京东京麦的生产级TCP网关技术实践总结》
2. 《长连接网关技术专题(二)：知乎千万级并发的高性能长连接网关技术实践》
3. 《长连接网关技术专题(三)：手淘亿级移动端接入层网关的技术演进之路》
4. 《长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践》
5. 《长连接网关技术专题(五)：喜马拉雅自研亿级API网关技术实践》
6. 《长连接网关技术专题(六)：石墨文档单机50万WebSocket长连接架构实践》
7. 《长连接网关技术专题(七)：小米小爱单机120万长连接接入层的架构演进》
8. 《长连接网关技术专题(八)：B站基于微服务的API网关从0到1的演进之路》
9. 《长连接网关技术专题(九)：去哪儿网酒店高性能业务网关技术实践》
10. 《长连接网关技术专题(十)：百度基于Go的千万级统一长连接服务架构实践》
11. 《长连接网关技术专题(十一)：揭秘腾讯公网TGW网关系统的技术架构演进》（* 本文）

3、TGW网关系统的重要性

TGW全称Tencent Gateway，是一套实现多网统一接入、支持自动负载均衡的系统， 是公司有10+年历史的网关，因此TGW也被称为公司公网的桥头堡。它对外连接了各大运营商并支撑公有云上EIP、CLB等产品功能，对内提供了公网网络的接入功能，如为游戏、微信等业务提供公网接入服务。

TGW主要有两大产品：

• 1）弹性EIP（比如购买一台虚拟机CVM或是一个NAT实例后，通过EIP连通外网）；
• 2）四层CLB。

四层CLB一般分为内网CLB和外网CLB：

• 1）内网CLB是在vpc内创建一个CLB实例，把多个CVM服务挂在了内网CLB上，为后端RS提供负载均衡的能力；
• 2）外网CLB面对的是公网侧负载均衡的需求。

当在内部部署CLB集群时，可分为IPV4或者IPV6两大类，根据物理网络类型又细分为BGP和三网两类。三网指这些IP地址是静态的，不像BGP一样能够在多个运营商之间同时进行广播。

以上就是四层TGW产品及功能，山海网关在原有产品基础上做了网络架构方面的演进。

4、Region EIP的引入

具体介绍下EIP和CLB两个产品。

过去CLB和EIP使用不同的IP地址池，导致资源池上的隔离问题。使得我们无法把EIP地址绑定到公有云CLB实例上。

例如：一个创业公司最初只购买一台虚拟机并挂载一个公网EIP来提供服务。随着用户量的增长，如果想将这个EIP地址迁移到一个公网CLB实例上，在原有架构下是无法实现这种迁移的。

此外：EIP和CLB部署在每个机房，因此在每个机房都需要建立EIP出口。但是各个机房的公网出口之间缺无法相互容灾。

所以这种情形下，我们确定了产品的目标：

• 1）希望将所有公网出口整合到一到两个机房之内，以避免重复建设，节省成本；
• 2）通过将出口集中，我们可以将对应的网关服务器也进行集中，进而提高设备的利用率；
• 3）通过这样的布局可实现跨机房的容灾方案。

因此：最早的Region EIP（REIP）计划应运而生。

以北京这类大型region为例的：我们将EIP专区建设到位于两个城市的超核机房。这两个机房通常会放置物理网络的交换设备，并为各自设立了一个REIP专区。在REIP专区内部署Region EIP集群。为了实现跨AZ容灾，两个机房的集群之间借助大小网段实现互相备份容灾的能力。一旦其中一个机房的集群发生故障或出现网络问题，另一个机房的集群可以立即承担起容灾任务。

同时：因为新的Region EIP的网络架构跟原来的网络架构不一样，通过网络架构升级以及机型升级，我们能够把单台Region EIP的性能做到原有单台EIP性能的5倍。这样我们通过容量的提升进一步提升了设备利用率，在完成全量Region EIP后，设备数量会从3000+台缩减至700+台。同时原有的CLB集群还保留在各个机房不变，这些CLB集群的外网接入能力由Region EIP承担。

5、公网CLB的演进

5.1概述

公网CLB最早是有公网接入能力的。引入到Region EIP之后，当初设想是公网CLB不再演进，尽量让存量用户迁移到另外一种形式，上层是Region EIP，下层是内网CLB。用户先买一个内网CLB，如果需要对公网提供服务就再买一个弹性EIP，把EIP跟内网CLB绑定在一起，提供CLB公网的能力，替代原有的公网CLB，这是最早公网CLB的替代方案。

两个方案的区别是：原有公网CLB，用户仅看到一个CLB实例。新的模式下，用户看到的是两个实例：一个EIP+一个内网CLB，两个实例都可以独立运营管理。这就是我们最早的两层架构设想，想把公网CLB跟外网解耦。

但是，真正去跟用户或产品交流时，这个想法遇到了比较大的挑战：

1）用户体验的改变：以前公网CLB用户看到是一个实例，但是现在用户看到两个实例，必然会给用户带来一些适配工作。比如用户进行创建、管理实例时，API不一样了。以前使用通过自动化脚本创建公网CLB实例的，现在脚本还要改变去适配新的API。

2）用户习惯改变：以前用户习惯在一个实例下，点击页面，就能够查看流量、链接数等监控信息。现在EIP流量需要到REIP查看，而链接数还需在CLB产品上看。

3）存量客户无法迁移：原来客户买的公网CLB实例，是无法直接无感知迁移到内网CLB+REIP这种新形式的。

在这些挑战下，这个替代方案没能真正落地。结合用户的要求，我们最终跟产品定下的策略是：公网CLB保持不变。原有的公网CLB继续保留，同时如果用户新增的公网CLB需求，也要继续支持。

5.2公网CLB模型

那么，公网CLB到底怎么演变？

我们的初衷并不是把公网CLB这个产品摒弃掉，而是要收敛公网入口。所以我们针对这个初始需求，提出了上面这个两级架构模型。

首先：用REIP将公网流量先引进来，再将这个流量通过隧道报文的形式转发给原有的公网CLB集群，这样公网CLB不需要原有外网接入的能力，不需要再跟外网打交道，可以演变成只在机房内部的集群；同时因为公网CLB的流量都会经过REIP，REIP自然也就是公网CLB的流量入口。从而达到我们最初收敛公网入口的目的。这样的架构升级，可实现用户无感知。架构升级切换过程中，用户在访问公网CLB，不会出现卡顿或者重连的现象。

这个架构模型也有一定的局限性的。公网CLB实例只能承载公网的流量，无法像上文提到的两层RERP+CLB那样，内外网随时进行转化。REIP+CLB实例中的CLB既承载内网侧CLB的流量，又承载公网侧CLB的流量。

6、山海架构 1.0

借助这个两级架构模型，我们能够把公网CLB保留下来，并且通过REIP把公网入口收敛。

进一步思考并完善，我们提出了下面的想法：跟产品进行解耦。

以前我们一个地区上线公网CLB产品，底层就要搭建有一个公网CLB的集群去支持。用户需要内网CLB服务，就要对应搭建个内网CLB的集群。底层集群类型跟产品是强耦合，有IPv4/IPv6， 公网/内网、BGP/三网组合出的多个产品形态。

这种模式在小地域部署，因为产品业务的流量小，集群利用率低，就会造成很大的成本压力。

为了应对这种小带宽低成本的诉求，我们将CLB+REIP的模型进一步抽象，引入山海架构：我们只建设CLB和REIP两类集群。通过这两类集群上的不同实例组合，满足多个产品形态的要求。从而实现产品形态和底层物理网络集群类型解耦。

解耦合的方式是：CLB和REIP通过不同的实例类型，组合出不同的产品形态。

山海架构在TGW内部做闭环，不涉及到产品侧和用户侧的改动。整个过程升级，对产品侧不做任何接口上的更新。因为产品侧的API接口保持不变，对用户侧就可以做到完全无感知。在产品侧保持不变，就需要我们在内部管控，识别接入用户实例是哪种形态的产品，拆分成不同形式的CLB和REIP的实例。其他的相关功能的比如流量统计、限速等模块也都要适配不同的产品形态，通过模块的适配，做到山海架构对上层产品侧应用的透明。

山海架构1.0归纳起来有两个重点：收敛公网入口和集群类型归一。

1）REIP：部署在城核机房，同时承载的是CLB和REIP两类产品的公网流量。之前EIP，在物理网络上有BGP+三网、v4/v6等多种集群类型。REIP借助vlan的隔离支持，把所有的网络类型都集中到一种REIP集群上来，我们称之为全通集群。在物理网络层面实现网络类型的归一， 然后再通过软件层的适配，实现REIP支持多通类型的网络接入能力。

2）CLB：在山海两级架构下，REIP集群处理公网侧的各种场景组合，CLB集群通过隧道与REIP处理公网流量。之前一个机房如果要把所有的产品能力支持起来，大概有7种集群类型。现在CLB集群可以用一种集群类型来支持所有的产品的公网CLB产品，以及内网CLB产品的能力。我们把三网+BGP以及内外网还有V4V6等集群类型都用一种类型来支持，山海架构完全落地后，开区的最小服务器数量可以降低到8台服务器，来承载所有的EIP和CLB产品需求。

归纳起来一句话：对于用户来说，产品形态没有改变，用户使用习惯也没有改变。而在底层，我们把集群类型收敛到一个CLB集群和一个REIP集群上。

7、山海架构1.0限速技术

在山海架构演进中，有许多技术点，本文选取限速技术进行分享。

首先Region EIP支持三网。以前BGP跟三网分开独立支持，山海网关统一用Region EIP支持。Region EIP本身的网络架构分成两个机房，每个机房放4台TGW设备，每个EIP只会走左边或者右边。一个EIP进来的流量经过上面这层交换机时，经过了ECMP分流，然后分到了4台设备上。这样对每个EIP其实是采用了分布式限速。

限速有两个要求：

• 1）精确性，限速上下浮动要小，要限得准；
• 2）要有容灾能力。

限速最极端的精准就是把它放到单点上去做限速，但是单点限速就会面临单点故障和容灾的问题。在X86服务器上，使用的是分布式限速，一个EIP均分到4台服务器上，每五秒钟做一次流量的的汇总统计，通过流量比例计算将这个EIP的带宽配额，重新分配并分发到4台设备上，以此来实现集群上的限速。在单台设备上，也是没隔一段时间，就重新计算配额并分配到每个CPU核上，我们目前用的是300毫秒周期。

需要说明的是：在限速的实现上，业务有多重实现方式，我们了解到有的实现的是静态分配，比如120兆的带宽，4台设备，我们每台设备分40M(三分之一)的带宽。1/3而不是1/4的带宽，目的是防止某一台设备断了之后，用户总带宽不达标，影响用户体验。在单台设备上限速，也有另外一种实现方式，大小桶。比如限速1M的带宽，那么每个核第一次取回100K或者200K配额。后续报文处理时候，先消耗上次取回的配额，如果带宽配额消耗光了，再重新取。周期调整跟大小桶这两种实现方式各有优缺点。从资源消耗来说，300毫秒周期的资源消耗相对会更少一些，两者大概有10%左右的性能偏差。

限速上另一诉求：小带宽的限速的精准限速。

大带宽比如100兆，分到每个核上相对富裕。小带宽如一M带宽，一秒钟100k字节等，分到四台机器再分到几十个核上，每个核都可能不到一个大报，这时候再去做精准限速就会非常困难，因为既然要提前分配资源，资源那么少，分配到单核上，可能一个包都过不去，但凡有一个报文过去了，又可能超了。所以在小带宽限速时，我们把它退化成类似于单点限速的模式。由于入方向带宽最小也是100兆，因此保持原有的分布式限速不变。只对出方向小带宽，使用单点限速。方案是这样的：

每台REIP有自己一个独享的内网地址，只有这台服务器故障时候，这个地址的流量才被分发到其他三台服务器。

入方向流量被分到四台REIP服务器后，REIP处理完通过tunnel转发给母机。隧道的外层源地址，只使用其中一台REIP服务器的独享的IP地址。每个外网IP地址在挂载到集群下管理时候，就确定下来了。

母机在接受到网关发过去的流量，解析外层报文地址，并记录在本地会话表里，我们称之为母机的自学习能力。当母机侧转发出方向报文时，就只会使用本地学习并记录的外层地址去封装隧道。这样出方向的流量，就回到单台TGW设备上，实现了单点限速。

独享的内网地址本身是有容灾能力：

• 1）当其服务器故障了，流量就被分散到集群其他服务器，放弃单点限速；
• 2）当服务器被修复上线后，又可以重新变成精准的单点限速。

这样保证小带宽精准限速的同时，又避免了单点故障。

在限速过程中，还有一个问题，因为CLB集群原来的限速是在CLB集群上自己做的，引入山海之后，REIP上有限速能力，那么公网CLB的限速要不要挪到REIP上？

我们经过多次讨论， 最终还是维持**这个限速在公网CLB上不变。

这里有几种场景考量：

1）内外网攻击：如果我们把它放到REIP上，这里可以扛住外网的攻击，但同时内网的攻击我们是防不住的，因为公网CLB上没有限速后，流量内网的攻击就会先把CLB上压过载，导致丢包，影响业务的稳定性。

2）有效流量的准确统计：原有架构下，从公网流量首先到达CLB，我们需要检查公网CLB上与port对应的服务是否已配置规则并启用。如果没有启用，则将报文直接丢弃且不记录为公网CLB的带宽使用量。山海架构下，如果先经过Region EIP限速，这类无服务访问流量（如恶意攻击和垃圾流量）也将占用限速资源。尽管这部分限速流量会送达至CLB集群，但由于缺乏相应服务支持，它们最终还是将被丢弃。结果导致用户带宽不及预期。比如用户购买10M带宽，实际有效运行的仅有8M流量，而其余2M被无服务流量占用了。

3）多重限速的影响：还有一个这个场景中，当Region EIP实施带宽限速后，这些流量最终可能进入公网CLB。然而，由于CLB的规格限制，例如新建连接数或并发连接数已达到上限，部分数据包可能会被丢弃。这些丢失的数据包已经消耗了购买的公网带宽，从而导致用户观察到的公网CLB流量带宽未达到预期。因此，我们保留公网CLB限速功能不变，仅进行引流调整。

8、山海架构1.0的优势

CLB产品及REIP产品，在使用山海1.0之后的几点优势。

1）CLB产品本身支持热迁移，扩容到山海热迁移，不会引起用户的断流，有助于运维做用户产品升级迭代。这方面有个典型案例，比如某台设备坏了或者发现某台设备上有问题，需要把流量迁走的时候，我们可以不用中断用户的流量的。我们了解到，以前有的竞品，因为热迁移做的不是特别完善，在设备出现问题或者是需要升级版本的时候，常选择低峰期做升级。

2）EIP在做限速的时候，在出方向时是小带宽，可以做到比较精准的限速。好处是用户做压测或测试的时，带宽不会抖动影响自己的业务的稳定性。

3）高低优先级限速。用户买一些比较小的比如10M带宽或者5M带宽，用来服务本身业务，同时也会ssh或者远程桌面登录EIP；因为一起我们是做无差别的限速丢包的话，这样会造成它本身的控制流量，如远程桌面的流量也会被丢包，造成登录的卡顿。用户需要在不超限速的前提下，优先保证远程桌面不卡，然后再提供其他的下载服务。我们把流量根据端口进行区分，比如22端口或者是远程桌面的3389端口的流量，标记为高优先级。在做限速时，只要高优先流量不超限速，就全部放行。当高优先级流量再叠加上低优先级的流量超限速时，把低优先级的流量丢掉，这样ssh访问服务器的时候能够非常顺畅。

4）山海架构上线后，基于vip粒度的调度，可以让调度更加灵活。比如原来一个集群为了节省路由条目，我们按照一个网段发路由，不是每个VIP都发路由的。山海两级架构之后，没有了这个限制，就可以按照VIP，把CLB实例调度到不同CLB集群。这样如果用户需要一个特别大规格的VIP的时候，我们可用一个集群的能力去扛用户一个VIP，从而满足超大规格实例的诉求。当然真实使用产品时，很少有客户把上百G的流量用一个VIP来承载。用户出于容灾考虑，通常不会把所有的鸡蛋放到一个篮子里。

9、山海架构 2.0

9.1概述

如前所述：山海 1.0 主要目标是整合公共网络并将所有公网出口集中在城市核心机房内。至于剩余的 CLB 群集，我们会继续将其保存在原有各机房的专区里。这是因为网关设备有其与服务器不同的网络诉求，例如普通服务器不能提供发布动态路由，并通过动态路由引流处理业务流量。

再比如：网关专区的收敛比1:1，而服务器虽然带宽也是100G， 但其收敛比率往往小于1：1。

在这种情况下，我们不能简单地将 CLB 网关群集群平移放置到服务器区。因此，CLB 网关群集通常在构建每个机房时，预先规划并预留相应的网关专区。机房建设起来后，如业务量小，又会因预留资源空置造成浪费。目前专区闲置机位也是一笔较大的费用。

同时，还有一种临时扩容的需求场景，例如VIP大客户，临时会有大流量的转发需求，这时常态运营水位没法满足需要，需要调配设备做集群扩容。如果本机房的设备不够还需要跨机房搬迁，搬迁周期比较长，对我们运营压力会很大。

所以，我们希望通过山海2.0能把专区建设的空置率降下来，同时提升弹性，能够低成本的快速扩缩容。

9.2引流交换机

在山海 2.0里，我们采用了“引流交换机”。在每个机房的建设时，我们可以放置两组共四台引流交换机。

考虑到单个交换机的容量可以达到 1 T 以上，有四台交换机工作，一个机房能够承受大约 4T~ 6T 的流量峰值。这意味着后续无需再额外扩容，一次性的建设和布局就可以满足长期的需求。相比于 CLB 群集占用的机位空间，四台交换机所需的机位显著减少。

我们把原来CLB集群对外声明路由的能力放到了引流交换机上，把CLB服务器用用通用服务器区的设备来代替。考虑收敛比和容灾，不会把一个集群放到一两个机架上，会相对分散些，更不会把整个机架全部再用成CLB集群。这样CLB集群不再单独建设网关专区，引流交换机把路由声明发出去，通过隧道跟CLB设备转发流量。

9.3山海2.0的变化

我们以内网CLB为例，原来一台虚拟机访问CLB集群，CLB集群把它的流量转到对应的RS。

引入交换机之后，其进出两个方向都会有变化：入方向（访问LB方向），虚拟机的流量先被引流到了引流交换机，交换机把报文做一次封装，然后发送给对应的服务器，进行负载均衡转换。最后处理后的结果，被转发给真正的RS。原来的两跳访问变成了现在的三跳。同样反方向流量返回时，RS的流量先回到引流交换机，然后被分发到对应的LD设备上。LD处理完之后，再把报文直接转到client虚拟机上。借助引流交换机的中转，我们就能够让负载均衡的专区设备的放到普通的服务器区里。

另外：这里的CLB服务器，可以跟其他的网关包括母机复用一些相同机型的服务器，当需要扩容时，就可以使用通用服务器。而不像以前CLB既有自己独立的机型，又对服务器的物理位置有要求。有了引流交换机跟LD之间是做隧道传输，LD具体的物理位置就没有像原来一样有硬性的要求。这样CLB可以通过通用服务器区域，调配服务器。

最后一项是：原有跟REIP类似的，CLB设备做路由通告时，也是按照网段通告，有引流交换机之后，我们可以在引流交换机上去做细粒度的调度，一个VIP或是几个vip放到一个集群。还可以在引流交换机上做更细粒度的调度，如IP+port这样的五元组的粒度的调度。

10、未来展望

目前网关设备最重要也是最大的一个方向就是做高性能、硬件卸载。依赖硬件来实现高性能的转发。

网关设备分为有状态和无状态两种：

• 1）无状态设备就像IP转换一样，只要依据规则，任何时刻来了报文，转换出来的形式都是固定的；
• 2）有状态设备是需要记录TCP、 UDP状态，记录转发到后端设备，当不同的时间转发即使相同的类型的流量，它转发的目的地也不一样，转换的格式也可能不一样。

硬件卸载在有状态和无状态时，基本上用到的设备都是DPU和交换机，用到的介质几乎都是FPGA。

FPGA和ASIC本质上是一个东西，无论友商还是我们自己内部研发，更多的是FPGA上做功能，并小规模的灰度上线验证，一旦稳定下来，就转化成批量的ASIC，以此来降低成本。

DPU和交换机在无状态设备上，交换机相对更有优势，因为无状态设备对容量的要求相对小些，像EIP网关以及内部无状态的网关大多用交换机形态实现。DPU目前更多的用在母机侧，做有状态类的网络处理。当然， 采用DPU不仅仅局限网络诉求，还有存储安全等其他需求。去年英特尔宣布已不再进行交换机tf芯片的演进迭代，大家对交换机的质疑会增大。

所以，也衍化了另一种方案：在一台额外的服务器中插入 DPU 网卡以实现卸载功能。

但不同方案有不同的优缺点：

1）使用交换机的最大优势在于其强大的交换性能（可达 1T或几个T及更高），可支持很大的接入容量。但是，交换机仅能是一个底座，若要扩展容量仍需依赖 FPGA 技术。

2） DPU 的优点则包括成熟的产业链、庞大的产量以及稳定的供应保障；此外，由于 DPU 在母机侧已被广泛验证和采用，许多功能的实现都相对固定。

这是两种方案各自的优缺点。

在两个产品运用负载均衡状态的交换上，业内不同的厂家也有不同的玩法，有的是交换机，有的是DPU。当前，无论是交换机还是 DPU，都依赖FPGA(ASIC)来做大容量的会话管理，同时越来越多的设备或多或少的支持P4。在 X86 上进行编程时，通常选择 DPDK。

相较之下：使用 P4 进行编程的门槛较低。P4 编写一般功能需求的代码非常简单快捷，只需一两周时间即可完成，甚至对于熟练者来说，可以在几个小时就开发出一个小功能。虽然充分发挥硬件的性能，P4类芯片还需要进行很深入细节的研究，但P4还是大大降低了数据面编程的门槛，特别是在高性能转发的需求方面。

另一个特点是：小型化。大家过去比较关注数据中心和海量数据的优化问题，随着业务发展，逐步转向降低运营成本和提高效率的场景，开设小型站点。这类小型站点，是典型的“麻雀虽小，五脏俱全”，希望用尽量少的设备成本来满足各种功能需求。所以我们将设备设计为具有较小规格的产品系列，并在易用性上进行改进，通过集群合并、虚拟机等承担更多的任务负载。这样在业务规模和流量不大，也能以较少的资源应对较高的功能性需求。一旦业务规模扩大，我们可将这些小型站点升级为传统的数据中心级物理设备。

以上未来网关两个主要的方向。

11、相关资料

[1] IPv6技术详解：基本概念、应用现状、技术实践（上篇）

[2] 网络编程入门从未如此简单(三)：什么是IPv6？漫画式图文，一篇即懂！

[3] 网络编程懒人入门(十五)：外行也能读懂的网络硬件设备功能原理速成

[4] 脑残式网络编程入门(六)：什么是公网IP和内网IP？NAT转换又是什么鬼？

[5] 脑残式网络编程入门(七)：面视必备，史上最通俗计算机网络分层详解

[6] 以网游服务端的网络接入层设计为例，理解实时通信的技术挑战

[7] 百度统一socket长连接组件从0到1的技术实践

[8] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[9] 百度APP移动端网络深度优化实践分享(二)：网络连接优化篇

[10] 新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践

[11] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

（本文已同步发布于：http://www.52im.net/thread-4641-1-1.html）

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第36 期。

[-1-] 跟着源码学IM(一)：手把手教你用Netty实现心跳机制、断线重连机制

[链接] http://www.52im.net/thread-2663-1-1.html

[摘要] 说到用Netty来开发IM或推送系统，以一个生产级产品的标准来说，最基本的心跳机制、断线重连机制肯定得有吧？好，如果你还不清楚这些，那就看看本文吧！

[-2-] 跟着源码学IM(二)：自已开发IM很难？手把手教你撸一个Andriod版IM

[链接] http://www.52im.net/thread-2671-1-1.html

[摘要] 本文适合没有任何即时通讯（IM）开发经验的小白开发者阅读，文章将教你从零开始，围绕一个典型即时通讯（IM）系统的方方面面，手把手为你展示如何基于Netty+TCP+Protobuf来开发出这样的系统。非常适合从零入门的Android开发者。

[-3-] 跟着源码学IM(三)：基于Netty，从零开发一个IM服务端

[链接] http://www.52im.net/thread-2768-1-1.html

[摘要] “文适合IM新手阅读，但最好有一定的网络编程经验，必竟实践性的代码上手就是网络编程。如果你对网络编程，以及IM的一些理论知识知之甚少，请务必首先阅读：《新手入门一篇就够：从零开发移动端IM》，该文为IM小白分类整理了详尽的理论资料，请按需补充相关知识。

[-4-] 跟着源码学IM(四)：拿起键盘就是干，教你徒手开发一套分布式IM系统

[链接] http://www.52im.net/thread-2775-1-1.html

[摘要] 本文记录了我开发的一款面向IM学习者的 IM系统——CIM（全称：CROSS-IM），同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM。

[-5-] 跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现

[链接] http://www.52im.net/thread-2799-1-1.html

[摘要] 本文正好借着在CIM系统中有这样两个需求（CIM是本文作者从零开发的一个学习性质的IM系统，详见《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》），正好来聊一聊我是如何理解IM长连接的心跳及重连机制，以及又是怎么踩坑已及填坑的。

[-6 -] 跟着源码学IM(六)：手把手教你用Go快速搭建高性能、可扩展的IM系统

[链接] http://www.52im.net/thread-2988-1-1.html

[摘要] 本文适合有一定网络通信技术基础的IM新手阅读。如果你对网络编程，以及IM的一些理论知识知之甚少，请务必首先阅读：《新手入门一篇就够：从零开发移动端IM》，按需补充相关知识。

[-7-] 跟着源码学IM(七)：手把手教你用WebSocket打造Web端IM聊天

[链接] http://www.52im.net/thread-3483-1-1.html

[摘要] 本文将基于Tomcat和Spring框架实现一个逻辑简单的入门级IM应用，对于即时通讯初学者来说，能找到一个简单直接且能顺利跑通的实例代码，显然意义更大，本文正是如此。希望能给你的IM开发和学习带来启发。

[-8-] 跟着源码学IM(八)：万字长文，手把手教你用Netty打造IM聊天

[链接] http://www.52im.net/thread-3489-1-1.html

[摘要] 上篇《跟着源码学IM(七)：手把手教你用WebSocket打造Web端IM聊天》中，我们使用 WebSocket 实现了一个简单的 IM 功能，支持身份认证、私聊消息、群聊消息。然后就有人发私信，希望使用纯 Netty 实现一个类似的功能，因此就有了本文。

[-9 -]  跟着源码学IM(九)：基于Netty实现一套分布式IM系统

[链接] http://www.52im.net/thread-3789-1-1.html

[摘要] 接下来的内容，我会为你介绍如何开发一个IM的方方面面，包括系统架构、通信协议、单聊群聊、表情发送、UI事件驱动等，以及全套的实践源码让你可以上手学习。

[-10-] 跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）

[链接] http://www.52im.net/thread-3816-1-1.html

[摘要] 本文将根据笔者这次的业余技术实践，为你讲述如何基于Netty+Zk+Redis来搭建一套高性能IM集群，包括本次实现IM集群的技术原理和实例代码，希望能带给你启发。

[-11 -] 跟着源码学IM(十一)：一套基于Netty的分布式高可用IM详细设计与实现(有源码)

[链接] http://www.52im.net/thread-4257-1-1.html

[摘要] 本文将要分享的是如何从零实现一套基于Netty框架的分布式高可用IM系统，它将支持长连接网关管理、单聊、群聊、聊天记录查询、离线消息存储、消息推送、心跳、分布式唯一ID、红包、消息同步等功能，并且还支持集群部署。

[-12 -] 跟着源码学IM(十二)：基于Netty打造一款高性能的IM即时通讯程序

[链接] http://www.52im.net/thread-4530-1-1.html

[摘要] 原本打算做个多人斗地主练习程序，但那需要织入过多的业务逻辑，因此一方面会带来不必要的理解难度，让案例更为复杂化，另一方面代码量也会偏多，所以最终依旧选择实现基本的IM聊天程序，既简单，又能加深对Netty的理解。

👉52im社区本周新文：《微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗》《移动端IM产品RainbowChat[专业版] iOS端 v9.0版已发布！》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由微信技术团队分享，原题“十年前的微信消息收发架构长啥样？”，下文进行了排版和内容优化等。

1、引言

2023 年，微信及 WeChat 的 DAU（月活用户）达到 13.4 亿，微信已经是很多人工作、生活中不可或缺的一个环节。从 2011 年 1 月 21 日上线至今，微信已经走过了 13 个年头，其背后的技术基座与架构也发生了巨大的变化。这些变化背后，所折射的也正是中国互联网高速发展的黄金年代。

好的架构是迭代出来的，却也少不了良好的设计，本文将带大家回顾微信背后最初的也是最核心的IM消息收发技术架构，愿各位读者能从中获得启发。

2、微信技术起步

微信诞生于 QQMail 团队，初始的整个微信后台架构都带着浓重的邮箱气息，消息收发架构作为微信最为核心的部分，同样是基于邮箱的存储转发机制演变而来。

微信定位为即时通讯IM软件，对消息的收发有2个基本的要求：

• 1）消息尽可能的实时送达；
• 2）不丢消息。

在邮箱的存储转发机制上做了改良后，微信的消息收发实现了以上2个基本要求。

3、消息发送架构

首先通过手机 A 给手机 B 发送一条微信消息来看消息发送的整体架构是怎样的（如下图所示）。

微信消息发送在整体架构上可以分为2个部分。

第一部分：手机A发送消息到服务器（上图中1、2、3部分）：

• 1）1 - 手机A发送发消息请求到接入层 ConnnectSvr；
• 2）2 - 接入层收到请求后，将请求转到逻辑层 SendSvr 进行处理；
• 3）3 - 逻辑层处理完各种逻辑（如反垃圾，黑名单等等）之后，将消息存入存储层 MsgStore。

第二部分：服务器发送通知到手机B（上图中4、5.1、5.2、6、7部分）：

1）4 - 逻辑层 SendSvr 将给手机 B 的新消息到达通知发送到通知处理服务器 PushSvr。

2）5.1 - PushSvr 查询手机 B 在接入层所在长连接的 ConnectSvr，并将通知发给该 ConnectSvr。

3）5.2 - PushSvr 发送一个 Push tips 给手机操作系统自建的第三方 Push 系统（如苹果的 APNsPush，微软的 WPPush，黑莓的 BBPush 等）。像苹果的 IOS 系统，在 APP 退出到后台10分钟后就会释放掉该 APP 所持有的所有资源（如 CPU，网络，内存等），导致之前建立的长连接通道也会一并断掉，此时通过5.1的方式进行通知是不可达的，所以还需要依赖与苹果自身的 apns 通道来达到实时通知的目的。

4）6 - 接入层 ConnnectSvr 通过手机 B 建立的长连接通道将新消息达到通知发送给手机 B。

5）7 - 第三方 Push 服务器通过自建的 Push 通过发送 Push tips 到手机 B。

4、消息接收架构

手机 B 在收到新消息到达通知后进行消息收取的整体架构如下图所示：

 

消息收取的流程主要分为3个步骤：

• 1）手机 B 发起收取消息的请求到接入层服务器 ConnnectSvr；
• 2）接入层服务器 ConnnectSvr 接到请求后转给逻辑层服务器 ReceiveSvr 进行处理；
• 3）ReceiveSvr 从存储层 MsgStore 中获取到需要下发的消息。

5、消息收发架构小结

在上述第4、5两节中分享的消息收发架构保障之下，微信可以保证手机 A 在发出消息 100ms 级别内让手机 B 收取到该条消息。

当然，对于退出后台的苹果 iOS 的微信用户，在苹果的 APNs 服务器正常的情况下，也可以保证在秒级别内通知到手机 B 点开 APP 进入前台来收取消息。

6、消息防丢失机制

虽然消息收发架构保证了消息收发双方能够及时收发消息，但该架构不能保证消息在传输过程中不发生丢弃。

当然为了达到任意一条消息都不丢的状态，最简单的方案是手机端对收到的每条消息都给服务器进行一次 ack 确认，但该方案在手机端和服务器之间的交互过多，并且也会遇到在弱网络情况下 ack 丢失等问题。

为了完美的做到消息不丢，微信消息系统对消息收发引入了 sequence 机制。

PS：感兴趣的话，以下是更多与IM消息送达保证有关的文章，可以一并阅读：

1. 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨
2. 融云技术分享：全面揭秘亿级IM消息的可靠投递机制
3. 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
4. IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

7、消息防丢失机制技术实现

7.1sequence 机制

• 1）每个用户都有42亿的 sequence 空间（从1到 UINT_MAX），从小到大连续分配；
• 2）每个用户的每条消息都需要分配一个 sequence；
• 3）服务器存储有每个用户已经分配到的最大 sequence；
• 4）手机端存储有已收取消息的最大 sequence。

PS：微信sequence序列号生成的具体算法和实现详见《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》。

7.2消息收取sequnece确认机制

当服务器和手机端都拥有了一个 sequence 之后，服务器和手机端之间就可以根据两者 sequence 的差异来收取消息，同时保证手机端未收取下去的消息最终能够收取下去。

具体流程如下图表示：

1）根据服务器和手机端之间 sequence 的差异，可以很轻松的实现增量下发手机端未收取下去的消息。

2）对于在弱网络环境差的情况，丢包情况发生概率是比较高的，此时经常会出现服务器的回包不能到达手机端的现象。由于手机端只会在确切的收取到消息后才会更新本地的 sequence，所以即使服务器的回包丢了，手机端等待超时后重新拿旧的 sequence 上服务器收取消息，同样是可以正确的收取未下发的消息。

3）由于手机端存储的 sequence 是确认收到消息的最大 sequence，所以对于手机端每次到服务器来收取消息也可以认为是对上一次收取消息的确认。一个帐号在多个手机端轮流登录的情况下，只要服务器存储手机端已确认的 sequence，那就可以简单的实现已确认下发的消息不会重复下发，不同手机端之间轮流登录不会收到其他手机端已经收取到的消息。

如上图4所示：假如手机 A 拿 Seq_cli = 100 上服务器收取消息，此时服务器的 Seq_svr =  150，那手机 A 可以将 sequence 为[101 - 150]的消息收取下去，同时手机 A 会将本地的 Seq_cli 置为150。

如上图5所示：手机 A 在下一次再次上来服务器收取消息，此时 Seq_cli = 150，服务器的 Seq_svr = 200，那手机 A 可以将 sequence为[151 - 200]的消息收取下去。

如上图6所示：假如原手机 A 用户换到手机 B 登录，并使用 Seq_cli = 120 上服务器收取消息，由于服务器已经确认 sequence <= 150 的消息已经被手机收取下去了，故不会再返回 sequence 为[121 - 150]的消息给手机 B，而是将 sequence 为[151 - 200]的消息下发给手机 B。

这里虽然 sequence 为[151 - 200]的消息有可能是被手机 A 和手机 B 都收取到，但由于手机 A 在收到 sequence 为[151 - 200]的消息时并没有给服务器进行确认或者这些消息手机 A 压根就没有收取到，所以为了防止消息丢失，sequence 为[的消息也是需要下发给手机 B 的。

8、本文小结

以上简单文字描述的就是微信最初的IM消息收发的架构。

该架构实现了即时通讯软件对消息收发所需的两个基本要求：

• 1）消息尽可能的实时送达 ；
• 2）不丢消息。

以上：是 2014 年微信古早时期的消息收发架构的基本介绍，时过境迁，微信的消息收发架构已经发生了巨大的变化，但我们还是可以从中看到技术演变的价值与力量。

程序员最大的成就与幸福，或许就是自己的代码跑在千万人的设备上，默默支撑着海量的需求。

9、参考资料

[1] iOS的推送服务APNs详解：设计思路、技术原理及缺陷等

[2] 了解iOS消息推送一文就够：史上最全iOS Push技术详解

[3] 消息推送技术干货：美团实时消息推送服务的技术演进之路

[4] 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）

[5] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[6] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[7] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[8] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[9] 一套分布式IM即时通讯系统的技术选型和架构设计

[10] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[11] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[12] IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总

[13] 零基础IM开发入门(一)：什么是IM系统？

[14] 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨

[15] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

10、微信团队的其它文章

《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》

《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》

《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》

《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》

《那些年微信开发过的鸡肋功能，及其带给我们的思考》

《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》

《同为IM社交产品中的王者，QQ与微信到底有什么区别》

《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》

《社交应用教父级人物的张小龙和马化腾的同与不同》

《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》

《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》

《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》

《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》

《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》

《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》

《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》

《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》

《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践》

《微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的》

《微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等》

《微信技术分享：揭秘微信后台安全特征数据仓库的架构设计》

《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践》

《企业微信针对百万级组织架构的客户端性能优化实践》

《揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链》

《微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题》

《微信团队分享：微信后端海量数据查询从1000ms降到100ms的技术实践》

《大型IM工程重构实践：企业微信Android端的重构之路》

《IM技术干货：假如你来设计微信的群聊，你该怎么设计？》

（本文已同步发布于：http://www.52im.net/thread-4636-1-1.html）

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持 UDP 、TCP 、WebSocket 三种协议，支持 iOS、Android、H5、标准Java、小程序、Uniapp，服务端基于Netty编写。

工程开源地址是：

• 1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

关于RainbowChat

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► iOS端更新记录：http://www.52im.net/thread-2735-1-1.html
► 全部运行截图：iOS端全部运行截图 （另：Android端运行截图 点此查看）
► 在线体验下载：App Store安装地址 （另：Android端下载体验 点此查看）

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。

* RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架 MobileIMSDK 实现）。

v9.0 版更新内容

此版更新内容（更多历史更新日志）：

• 1）[新增] 新增“@”功能；
• 2）[新增] 新增消息引用功能（支持引用全部消息类型）；
• 3）[bug] 解决显示Android端发起的的音视频呼叫记录时，显示的是JSON文本的问题；
• 4）[bug] 解决了消息转发时，“最近消息”列表中的表情内容没有被转义成表情图标的问题；
• 5）[bug] 聊天界面中对新发的图片消息等长按时不显示弹出菜单的问题（直到表格被刷新后才会正常）；
• 6）[优化] 首页消息列表中的语音消息将显示语音时长（跟新版微信一样）；
• 7）[优化] 其它优化及bug修复。

新增功能运行截图（更多截图点此查看）：

本文由微信技术团队仇弈彬分享，原题“微信海量数据查询如何从1000ms降到100ms？”，本文进行了内容修订和排版优化。

1、引言

微信的多维指标监控平台，具备自定义维度、指标的监控能力，主要服务于用户自定义监控。作为框架级监控的补充，它承载着聚合前 45亿/min、4万亿/天的数据量。

当前，针对数据层的查询请求也达到了峰值 40万/min，3亿/天。较大的查询请求使得数据查询遇到了性能瓶颈：查询平均耗时 > 1000ms，失败率居高不下。

针对大数据量带来的查询性能问题，微信团队对数据层查询接口进行了针对性的优化，将平均查询速度从1000ms+优化到了100ms级别。本文为各位分享优化过程，希望对你有用！

2、技术背景

微信多维指标监控平台（以下简称多维监控），是具备灵活的数据上报方式、提供维度交叉分析的实时监控平台。

在这里，最核心的概念是“协议”、“维度”与“指标”。

例如：如果想要对某个【省份】、【城市】、【运营商】的接口【错误码】进行监控，监控目标是统计接口的【平均耗时】和【上报量】。在这里，省份、城市、运营商、错误码，这些描述监控目标属性的可枚举字段称之为“维度”，而【上报量】、【平均耗时】等依赖“聚合计算”结果的数据值，称之为“指标”。而承载这些指标和维度的数据表，叫做“协议”。

多维监控对外提供 2 种 API：

1）维度枚举查询：用于查询某一段时间内，一个或多个维度的排列组合以及其对应的指标值。它反映的是各维度分布“总量”的概念，可以“聚合”，也可以“展开”，或者固定维度对其它维度进行“下钻”。数据可以直接生成柱状图、饼图等。

2）时间序列查询：用于查询某些维度条件在某个时间范围的指标值序列。可以展示为一个时序曲线图，横坐标为时间，纵坐标为指标值。

然而，不管是用户还是团队自己使用多维监控平台的时候，都能感受到明显的卡顿。主要表现在看监控图像或者是查看监控曲线，都会经过长时间的数据加载。

团队意识到：这是数据量上升必然带来的瓶颈。

目前：多维监控平台已经接入了数千张协议表，每张表的特点都不同。维度组合、指标量、上报量也不同。针对大量数据的实时聚合以及 OLAP 分析，数据层的性能瓶颈越发明显，严重影响了用户体验。

于是这让团队人员不由得开始思考：难道要一直放任它慢下去吗？答案当然是否定的。因此，微信团队针对数据层的查询进行了优化。

3、优化分析1：用户查询行为分析

要优化，首先需要了解用户的查询习惯，这里的用户包含了页面用户和异常检测服务。

于是微信团队尽可能多地上报用户使用多维监控平台的习惯，包括但不限于：常用的查询类型、每个协议表的查询维度和查询指标、查询量、失败量、耗时数据等。

在分析了用户的查询习惯后，有了以下发现：

1）时间序列查询占比 99% 以上：

出现如此悬殊的比例可能是因为：调用一次维度枚举，即可获取所关心的各个维度。

但是针对每个维度组合值，无论是页面还是异常检测都会在查询维度对应的多条时间序列曲线中，从而出现「时间序列查询」比例远远高于「维度枚举查询」。

2）针对1天前的查询占比约 90%：

出现这个现象可能是因为每个页面数据都会带上几天前的数据对比来展示。异常检测模块每次会对比大约 7 天数据的曲线，造成了对大量的非实时数据进行查询。

4、优化分析2：数据层架构

分析完用户习惯，再看下目前的数据层架构。

多维监控底层的数据存储/查询引擎选择了 Apache-Druid 作为数据聚合、存储的引擎，Druid 是一个非常优秀的分布式 OLAP 数据存储引擎，它的特点主要在于出色的预聚合能力和高效的并发查询能力。

它的大致架构如图：

具体解释就是：

5、优化分析3：为什么查询会慢

查询慢的核心原因，经微信团队分析如下：

1）协议数据分片存储的数据片段为 2-4h 的数据，每个 Peon 节点消费回来的数据会存储在一个独立分片。

2）假设异常检测获取 7 * 24h 的数据，协议一共有 3 个 Peon 节点负责消费，数据分片量级为 12*3*7 = 252，意味着将会产生 252次 数据分片 I/O。

3）在时间跨度较大时、MiddleManager、Historical 处理查询容易超时，Broker 内存消耗较高。

4）部分协议维度字段非常复杂，维度排列组合极大（>100w），在处理此类协议的查询时，性能就会很差。

6、优化实践1：拆分子查询请求

根据上面的分析，团队确定了初步的优化方向：

• 1）减少单 Broker 的大跨度时间查询；
• 2）减少 Druid 的 Segments I/O 次数；
• 3）减少 Segments 的大小。

在这个方案中，每个查询都会被拆解为更细粒度的“子查询”请求。例如连续查询 7 天的时间序列，会被自动拆解为 7 个 1天的时间序列查询，分发到多个 Broker，此时可以利用多个 Broker 来进行并发查询，减少单个 Broker 的查询负载，提升整体性能。

但是这个方案并没有解决 Segments I/O 过多的问题，所以需要在这里引入一层缓存。

7、优化实践2：拆分子查询请求+Redis Cache

7.1概述

这个方案相较于 v1，增加了为每个子查询请求维护了一个结果缓存，存储在 Redis 中（如下图所示）。

假设获取 7*24h 的数据，Peon 节点个数为 3，如果命中缓存，只会产生 3 次 Druid 的 Segments I/O （最近的 30min）数据，相较几百次 Segments I/O 会大幅减少。

接下来看下具体方法。

7.2时间序列子查询设计

针对时间序列的子查询，子查询按照「天」来分解，整个子查询的缓存也是按照天来聚合的。

以一个查询为例：

{

    "biz_id": 1, // 查询协议表ID：1

    "formula": "avg_cost_time", // 查询公式：求平均

    "keys": [

        // 查询条件：维度xxx_id=3

        {"field": "xxx_id", "relation": "eq", "value": "3"}

    ],

    "start_time": "2020-04-15 13:23", // 查询起始时间

    "end_time": "2020-04-17 12:00"// 查询结束时间

}

其中 biz_id、 formula,、keys 了每个查询的基本条件。但每个查询各不相同，不是这次讨论的重点。

本次优化的重点是基于查询时间范围的子查询分解，而对于时间序列子查询分解的方案则是按照「天」来分解，每个查询都会得到当天的全部数据，由业务逻辑层来进行合并。

举个例子：04-15 13:23 ～ 04-17 08:20 的查询，会被分解为 04-15、04-16、04-17 三个子查询，每个查询都会得到当天的全部数据，在业务逻辑层找到基于用户查询时间的偏移量，处理结果并返回给用户。

每个子查询都会先尝试获取缓存中的数据，此时有两种结果：

经过上述分析不难看出：对于距离现在超过一天的查询，只需要查询一次，之后就无需访问 DruidBroker 了，可以直接从缓存中获取。

而对于一些实时热数据，其实只是查询了cache_update_time-threshold_time 到 end_time 这一小段的时间。在实际应用里，这段查询时间的跨度基本上在 20min 内，而 15min 内的数据由 Druid 实时节点提供。

7.3维度组合子查询设计

维度枚举查询和时间序列查询不一样的是：每一分钟，每个维度的量都不一样。

而维度枚举拿到的是各个维度组合在任意时间的总量，因此基于上述时间序列的缓存方法无法使用。在这里，核心思路依然是打散查询和缓存。

对此，微信团队使用了如下方案。

缓存的设计采用了多级冗余模式，即每天的数据会根据不同时间粒度：天级、4小时级、1 小时级存多份，从而适应各种粒度的查询，也同时尽量减少和 Redis 的 IO 次数。

每个查询都会被分解为 N 个子查询，跨度不同时间，这个过程的粗略示意图如下：

举个例子：例如 04-15 13:23 ～ 04-17 08:20 的查询，会被分解为以下 10 个子查询：

04-15 13:23 ～ 04-15 14:00

04-15 14:00 ～ 04-15 15:00

04-15 15:00 ～ 04-15 16:00

04-15 16:00 ～ 04-15 20:00

04-15 20:00 ～ 04-16 00:00

04-16 00:00 ～ 04-17 00:00

04-17 00:00 ～ 04-17 04:00

04-17 00:00 ～ 04-17 04:00

04-17 04:00 ～ 04-17 08:00

04-17 08:00 ～ 04-17 08:20

这里可以发现：查询 1 和查询 10，绝对不可能出现在缓存中。因此这两个查询一定会被转发到 Druid 去进行。2～9 查询，则是先尝试访问缓存。如果缓存中不存在，才会访问 DruidBroker，在完成一次访问后将数据异步回写到 Redis 中。

维度枚举查询和时间序列一样，同时也用了 update_time 作为数据可信度的保障。因为最细粒度为小时，在理想状况下一个时间跨越很长的请求，实际上访问 Druid 的最多只有跨越 2h 内的两个首尾部查询而已。

8、优化实践3：更进一步（子维度表）

通过子查询缓存方案，我们已经限制了 I/O 次数，并且保障 90% 的请求都来自于缓存。但是维度组合复杂的协议，即 Segments 过大的协议，仍然会消耗大量时间用于检索数据。

所以核心问题在于：能否进一步降低 Segments 大小？

维度爆炸问题在业界都没有很好的解决方案，大家要做的也只能是尽可能规避它，因此这里，团队在查询层实现了子维度表的拆分以尽可能解决这个问题，用空间换时间。

具体做法为：

• 1） 对于维度复杂的协议，抽离命中率高的低基数维度，建立子维度表，实时消费并入库数据；
• 2） 查询层支持按照用户请求中的查询维度，匹配最小的子维度表。

9、优化成果

9.1缓存命中率>85%

在做完所有改造后，最重要的一点便是缓存命中率。因为大部分的请求来自于1天前的历史数据，这为缓存命中率提供了保障。

具体是：

• 1）子查询缓存完全命中率（无需查询Druid）：86%；
• 2）子查询缓存部分命中率（秩序查询增量数据）：98.8%。

9.2查询耗时优化至 100ms

在整体优化过后，查询性能指标有了很大的提升：

平均耗时 1000+ms -> 140ms；P95：5000+ms -> 220ms。

10、相关文章

[1] 微信后台基于时间序的海量数据冷热分级架构设计实践

[2] IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议

[3] 社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践

[4] 微信后台基于时间序的新一代海量数据存储架构的设计实践

[5] 陌陌技术分享：陌陌IM在后端KV缓存架构上的技术实践

[6] 现代IM系统中聊天消息的同步和存储方案探讨

[7] 微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]

[8] 腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享

[9] IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践

[10] 微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等

[11] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

[12] 现代IM系统中聊天消息的同步和存储方案探讨

11、微信团队的其它文章

《Android版微信安装包“减肥”实战记录》

《iOS版微信安装包“减肥”实战记录》

《移动端IM实践：iOS版微信界面卡顿监测方案》

《微信“红包照片”背后的技术难题》

《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》

《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》

《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》

《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》

《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》

《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》

《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》

《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》

《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》

《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》

《微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的》

《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践》

《企业微信针对百万级组织架构的客户端性能优化实践》

《揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链》

《微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题》

（本文已同步发布于：http://www.52im.net/thread-4629-1-1.html）

本文由冀浩东分享，原题“单核QPS近6000S，陌陌基于OceanBase的持久化缓存探索与实践”，为了阅读便利，本文进行了排版和内容优化等。

1、引言

挚文集团于 2011 年 8 月推出了陌陌，这款立足地理位置服务的开放式移动视频IM应用在中国社交平台领域内独树一帜。陌陌和探探作为陌生人社交领域的主流IM应用，涵盖了多种核心业务模块，包括直播服务、附近动态功能、即时通讯（IM）业务以及增值服务等，每个业务场景都具有其独特性和挑战。

在本文中，陌陌数据库负责人冀浩东将聚焦探讨陌陌的 KV 系统架构选型思路，深入解析如何进行此类系统的甄选决策，同时进一步分享陌陌团队在采用 OceanBase（OBKV）过程中所经历的探索与实践经验。

2、关于作者

冀浩东：陌陌（现挚文集团）数据库负责人。目前负责陌陌和探探两个数据库团队建设以及集团数据库存储运营工作。在大规模数据源稳定性建设 、团队建设、成本优化、机房迁移等方面等领域积累了深厚的专业经验与实战心得。

3、陌陌的主要IM业务场景特点

1）直播业务：在陌陌众多业务场景中，直播业务占据了显著位置，其特点就在于随时可能出现的流量突发场景。由于低延时和高并发的需求，直播场景对数据库系统的实时处理能力提出了较高要求。平台需要确保在大量用户同时在线观看和互动时，数据能够被及时、准确地处理和分发。

2）附近动态：此功能则涉及到用户的地理位置信息、活动轨迹以及社交关系等复杂数据。这类数据会迅速积累，并随着时间的推移形成大规模的数据集。数据具有明显的冷热分层特性，即某些数据在某一时刻可能会成为热点，如当某用户发布的帖子引发热议并成为热门话题时。这要求系统能够有效管理并快速响应热点数据的访问需求。

3）IM 业务：此场景的核心特点是低延迟和高并发通信。信息的送达时间必须精确，对实时性有极高的要求。为了保证用户体验，应用程序需要确保消息能够即时、可靠地在用户之间传递。

4）增值服务：则主要侧重于数据的一致性和实时性。在处理用户购买、赠送虚拟物品或享受会员特权等操作时，系统需要确保数据的准确性并及时更新用户账户状态。同时，为了提供优质的增值服务，实时性也是不可或缺的因素，例如实时计算用户的积分、等级或者权益等。

陌陌和探探在运营这些业务场景时，都需要强大的数据处理和管理系统来应对各种特性和挑战，以确保为用户提供高效、稳定且满足个性化需求的社交体验。

针对以上的业务场景，我们应该如何选择 KV 系统呢？

4、陌陌后端KV缓存架构的演进阶段

在公司的成长过程中，存储选型通常会经历四个阶段。

4.1初始阶段

公司的主要目标是能够运行起来。

在创业初期，基于新开发的 App 进行运营工作时，由于业务能力可能还未成熟，为了应对快速迭代的业务需求，对系统的期望不会过高。只需要确保技术层面能够满足基本的业务需求并逐步演进即可。在这个阶段，常见的架构选择包括 Redis 主从架构和 Redis Cluster 等原生架构。

Redis 主从集群架构的优势在于可以迅速构建主从集群或分片集群，并且许多设计可以直接在客户端操作。然而，这种简单的操作方式可能导致设计与客户端业务代码的高度耦合，不利于后期的弹性扩容。

相比之下，Redis Cluster 集群架构支持动态扩容和高可用性。

然而，使用 Redis Cluster 时，业务依赖客户端感知节点变更。如果客户端未能正确处理节点变更，可能会导致服务中断或业务性能下降，因此对于对错误敏感的业务，Redis Cluster 可能会引入额外的复杂性。尽管 Redis Cluster 具有去中心化、组件少、提供 Smart Client 以及支持水平扩展等优点，但也存在批处理功能不友好和缺乏有效流控机制等问题。

4.2第二阶段

进入第二阶段，随着公司的发展和用户数量的增长，需要架构具备快速扩展的能力。

这一阶段的代表性架构例如 Codis、Twemproxy 等基础性 Redis分片架构。

其中，Codis提供了服务端分片方案、中心化管理、故障自动转移、节点水平扩展（1024 槽位）、动态扩缩容，以及支持 pipeline 和批处理等功能。

然而，Codis的当前版本较为陈旧，官方仅提供 3.2.9 版本，更新版本需要自行修复和适配，且由于组件多、资源消耗大。

4.3第三阶段

随着业务的进一步发展和公司进入相对稳定期，可能会发现先前急于扩张时遗留了一些问题。

例如：是否过度使用内存，数据是否可以冷热分层等。这些问题需要重新检验和优化。这个优化过程是第三阶段的重点。

在这个阶段，常见的持久化架构选择包括 oneStore-Pika、Tendis 和 Pika 等。

4.4第四阶段

最后，在第四阶段，公司业务和技术可能已经进入了深度复杂的领域，简单的优化调整可能无法带来显著的收益，甚至可能出现无法进一步优化的情况。

这时，可以通过引入更稳定的架构或者采用新的解决思路来应对挑战。

我们个人推荐考虑多模态架构，它能够适应多种数据类型和工作负载，提供更大的灵活性和优化空间。

总的来说，公司在不同发展阶段的存储选型应根据业务需求、技术成熟度、成本效益以及未来的扩展性和优化空间等因素进行综合考虑和决策。随着公司的发展和业务复杂性的增加，存储架构也需要不断进化和优化，以确保系统的稳定、高效和可持续发展。

5、陌陌自研的KV缓存“oneStore”

针对当前公司的业务状况，陌陌面临的最显著挑战在于集群规模的不断增长。

当单集群分片数量超过 1000 个，数据量超过 10TB，以及 QPS 超过 100 万时，现有的 Codis 架构和 Redis Cluster 架构已然无法满足需求，达到了其承载能力的极限。

为了解决这一瓶颈问题，公司自主研发了一款名为 oneStore 的存储产品（如下图所示）。

这一架构经过了分阶段的优化和改进过程，旨在突破原有的限制，以适应更高的分片数量、更大的数据量以及更密集的查询请求。通过 oneStore 架构，陌陌力求实现业务扩展的无缝对接和性能的大幅提升。

1）第一阶段：提供服务端 Proxy 方案，并通过自主研发的 oneStore Watcher 哨兵组件进行架构精简。这样一来，只需要部署一套哨兵集群，就能有效地管理一个业务区域。

2）第二阶段：提供客户端 SDK 方案。虽然服务端 Proxy 方案表现优秀，但随着业务的稳定，公司着眼于降本增效。直接使用客户端 SDK 方案，感知集群拓扑变化，并且通过 SDK 直连后端 Redis 地址，这样可以去除服务端 Proxy 组件，节省技术资源开销。然而，我们并没有完全摒弃服务端 Proxy 方案。因为目前陌陌的客户端 SDK 方案仅支持 Java 和 C++，对于 PHP、Python 等其他语言的用户，仍需要通过服务端 Proxy 访问数据源。这两种方案的成功运用，帮助我们统一了公司层面 Redis 的接入方式，并显著提升了机房迁移的效率。

随着业务的进一步稳定，陌陌开始从成本角度进行优化，选择 Pika 替代部分请求量不高的 Redis 集群，再提升架构的持久化能力（如下图所示）的同时降低存储成本。

然而现阶段 Pika 主要用来存储一些相对较冷数据，对于热数据的处理性能仍有待提高，后续团队也会持续关注并努力提升这一方面的性能。

总的来说，目前陌陌还面临一些需要解决和优化的场景：

1）单机多实例之间互相影响的问题：陌陌迫切需要解决单机多实例之间相互影响的问题，以确保各个实例的稳定运行和高效协作。这涉及到系统的整体稳定性和协同性，需要有针对性的优化和调整。

2）数据持久化支持：陌陌计划增强数据持久化的支持能力，以实现完整的数据持久化解决方案，以保障数据的完整性和可靠性。不仅仅局限于冷数据，而是要覆盖更广泛的数据类型，以确保数据的完整性和可靠性。这将是系统长期稳定性的一个重要保障。

所以，陌陌需要通过一个简单可靠可扩展的 KV 系统来解决以上问题。

6、陌陌的分布式KV缓存选型

6.1OceanBase

OBKV 是 OceanBase 数据库提供的通过 API 接口访问 Table 模型 Hbase 模型的能力。

有关OceanBase 数据库的来历，详见：《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路 。

之所以选择 OceanBase（OBKV），主要看中其两大优势：

• 1）性能更好；
• 2）稳定性高。

6.2关于性能

OceanBase（OBKV）基于 Table 模型构建，与 Redis 数据结构持久化方案这个典型的表模型匹配，且性能比传统持久化存储更强 ，能构建更丰富的数据结构。

下图是OceanBase（OBKV）在大量写数据的场景（TPS 17000），由于不同阶段都有任务在写数据，可以看出 TPS 非常陡峭，并且响应延时在 2 毫秒以下，事务的响应时间明细与预期是相对应的。

下图为 CPU 监控图：可以看到 CPU 使用率在 10% 以下，相对稳定。MemStore 的使用比例也是正常的，在 24% 以内，波动范围非常小，符合预期。

整体来看：OceanBase（OBKV） 生产环境波动小，资源占用稳定。

6.3关于稳定性

OceanBase（OBKV）基于 OceanBase ，存储引擎经过丰富的大规模 TP 场景验证，能提供高并发、低延时的能力。

从下图OceanBase（OBKV） 的多租户功能可见其稳定性。黑色线代表OceanBase（OBKV）租户，蓝色线的租户是 MySQL 租户。在 11:30 左右发起压测以后，OceanBase（OBKV） 租户的响应正常， MySQL 租户也没有受到影响。从服务器层面来看，CPU 负载是因为压测而上升的，而 MySQL 租户并不受影响。

因此可以得出：多租户功能能够有效解决单机多实例的相互影响问题。下图展示了是线上 MySQL 生产租户的表现，TPS 为 5000时，整体表现非常稳定。CPU 和内存使用波动较小，符合预期。

此外：能够便捷地通过 KV 接口将数据存入数据库，并运用 SQL 进行数据查询。OceanBase（OBKV）进一步增强了这一便捷性，支持二级索引以及服务端TTL功能，这有助于显著简化上层服务架构的设计。

尽管如此，OceanBase（OBKV）也存在一定的局限性，如仅提供单机事务处理能力；若要开启分布式事务支持，则可能会影响到系统在高并发环境下的性能表现和低延时响应能力。但鉴于当前陌陌业务的需求，我们认为OceanBase（OBKV）的单机事务能力完全符合要求，并因此共同构建了结合OceanBase（OBKV）- Redis 储存方案。

7、陌陌的分布式KV集群架构改进

陌陌与 OceanBase 开源团队共同打造了一个内部代号为 modis 的项目。

该项目整体架构涵盖了接入层、数据结构层、缓冲层、存储层以及管理平面等多个层次（具体可参考下图）。

值得注意的是：缓冲层在未来的规划中将用于有效解决热点读取及大 KEY 问题的挑战。而在存储层方面，陌陌将对其进行标准化抽象设计，构建出标准的 Storage 结构，以便能够灵活接入包括但不限于OceanBase（OBKV）在内的多种存储解决方案。

在测试评估过程中，将 Pika 数据（总计 158GB）成功迁移到 OceanBase（OBKV）-Redis 集群后，存储占用空间显著减少至 95GB，这一举措带来了存储成本的显著优化，总体上节约了大约 40% 的存储成本。

为了评估性能表现，特意构建了一个专门的测试环境（具体规格参见下图），并在该环境中模拟了不同并发线程场景以观测其峰值性能情况。

基于多租户管理的思路，不会对单一租户分配过多资源，而是优先观察各个租户在使用过程中哪个率先达到性能瓶颈，并据此计算单核的 QPS。当前，陌陌提供的标准规格为 12C40G 内存。未来，为了更好地适应业务需求的变化，可能会推出更小规格的配置方案，例如 4C8G 或 8C16G 等规格，这些决策将完全取决于实际业务的具体需要。

下图展示了 128 个线程数  QPS 70000 情况下 OceanBase（OBKV）-Redis 的性能表现。

具体是：

• 1）P90 响应延迟为 1.9 ms；
• 2）P95 响应延迟为 2.2 ms；
• 3）P99响应延迟为6.3 ms；

平均计算下来，单核读写比例是 4:1，此时单核能力接近 6000 QPS。

此外：在运维管理方面，深入对比了 OceanBase（OBKV）、Pika 以及 TiKV 在日常运维操作中的特性差异。目前，只有 OceanBase（OBKV）提供了原生的多租户支持功能，这一优势有效地解决了在单机部署多实例时所面临的相互干扰的问题。值得一提的是，OceanBase（OBKV）凭借完备的图形化界面管理工具和参数变更即刻生效的特点，对于数据库运维工作来说，无疑是极其贴心且高效的解决方案。

总的来说，OceanBase（OBKV）-Redis 实现了性能的显著提升、更少的磁盘使用以及运维管理的极大简化。

这主要得益于 OceanBase（OBKV）-Redis 的几个优势：

• 1）多租户隔离，解决单机多实例互相影响的困境；
• 2）存储成本更低。通过 Encoding 框架 + 通用压缩 ，进行表模型存储；
• 3）性能更高。将请求过滤直接下压存储，不用序列化以及反序列化，支持服务端 TTL。

8、相关文章

[1] 知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路

[2] 微信后台基于时间序的新一代海量数据存储架构的设计实践

[3] 现代IM系统中聊天消息的同步和存储方案探讨

[4] 腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享

[5] 社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践

[6] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

[7] 阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史

[8] 阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路

[9] 阿里IM技术分享(九)：深度揭密RocketMQ在钉钉IM系统中的应用实践

[10] 阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践

[11] 阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计

[12] IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！

[13] 小红书万亿级社交网络关系下的图存储系统的架构设计与实践

[14] IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议

[15] 微信后台基于时间序的海量数据冷热分级架构设计实践

（本文已同步发布于：http://www.52im.net/thread-4627-1-1.html）

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第35 期。

​[- 1 -] 直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路

[链接] http://www.52im.net/thread-1236-1-1.html

[摘要] 本文作者是美拍的架构师，经历了直播弹幕从无到有，从小到大的过程，借此文为大家分享构建弹幕系统的经验，希望能为正在开发或正打算开发弹幕、消息推送、IM聊天等系统的技术同行带来一些启发。

[- 2 -] 直播系统聊天技术(二)阿里电商IM消息平台，在群聊、直播场景下的技术实践

[链接] http://www.52im.net/thread-3252-1-1.html

[摘要] 本文来自淘宝消息业务团队的技术实践分享，分析了电商IM消息平台在非传统IM应用场景下的高发并、强互动群聊和直播业务中的技术特点，总结并分享了在这些场景下实现大量多对多实时消息分发投递的一些架构方面的设计实践。

[- 3 -] 直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路

[链接] http://www.52im.net/thread-3376-1-1.html

[摘要] 本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进，希望能为你的直播聊天互动中的实时聊天消息架构设计带来启发。

[- 4 -] 直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践

[链接] http://www.52im.net/thread-3515-1-1.html

[摘要] 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。

[- 5 -] 直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践

[链接] http://www.52im.net/thread-3835-1-1.html

[摘要] 本文将主要从高可用、弹性扩缩容、用户管理、消息分发、客户端优化等角度，分享直播间海量聊天消息的架构设计技术难点的实践经验。

[- 6 -] 直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践

[链接] http://www.52im.net/thread-3994-1-1.html

[摘要] 本文针对秀场直播，结合我们一年以来通过处理不同的业务线上问题，进行了技术演进式的IM消息模块架构的升级与调整，并据此进行了技术总结、整理成文，希望借此机会分享给大家。

[- 7 -] 直播系统聊天技术(九)：千万级实时直播弹幕的技术实践

[链接] http://www.52im.net/thread-4299-1-1.html

[摘要] 本文基于网易云信针对TFBOYS某场线上演唱会的技术支持，为你分享千万级在线用户量的直播系统中实时弹幕功能的技术实践，希望能带给你启发。

[- 8 -] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[链接] http://www.52im.net/thread-3631-1-1.html

[摘要] 本文总结了企业微信的IM消息系统架构设计，阐述了企业业务给IM架构设计带来的技术难点和挑战，以及技术方案的对比与分析。同时总结了IM后台开发的一些常用手段，适用于IM消息系统。

[- 9 -]  融云IM技术分享：万人群聊消息投递方案的思考和实践

[链接] http://www.52im.net/thread-3687-1-1.html

[摘要] 本文根据融云技术团队的实践经验，总结了万人群聊消息投递方案的一些思考和实践，希望能给你带来启发。

[- 10 -] 实时社群技术专题(一)：支持百万人超级群聊，一文读懂社群产品Discord

[链接] http://www.52im.net/thread-4300-1-1.html

[摘要] 本文为系列文章的首篇，文章内容不讨论Discord具体的技术实现，仅从其产品定义的角度上对Discord软件进行详尽和具体的介绍，希望能帮助你对Discord从产品形态上有较为完整的认知，也方便你阅读本系列文章的后续篇章。

[- 11 -] 实时社群技术专题(二)：百万级成员实时社群技术实现（消息系统篇）

[链接] http://www.52im.net/thread-4321-1-1.html

[摘要] 本文是序列文章的第2篇，将要分享的是云信的实时社群产品“圈组”（“圈组”是云信的类Discord产品实现方案）的消息系统技术设计实践。

[- 12 -] 海量用户IM聊天室的架构设计与实践

[链接] http://www.52im.net/thread-4404-1-1.html

[摘要] 本文将分享网易云信针对海量用户IM聊天室的架构设计与应用实践，希望能带给你启发。

👉52im社区本周新文：《陌陌技术分享：陌陌IM在后端KV缓存架构上的技术实践》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由ELab团队公众号授权发布，原题《Rust语言在IM客户端的实践》，来自抖音电商前端团队的分享，本文有修订和改动。

1、引言

本文将介绍飞鸽IM前端团队如何结合Rust对飞鸽客户端接待能力进行的技术提升，一步步从概念验证、路径分解到分工开发，再到最后上线收益论证，并分享了其中遇到的技术挑战与经验总结等。

本项目是一个长周期的复杂项目，相信本项目落地的经验对其他同学及团队能有所借鉴。

2、技术背景

飞鸽是在抖音电商业务上面向商家和用户的聊天工具，其拉通售前、售中、售后渠道，为商家履约提供重要支撑。

对于飞鸽桌面端IM而言，我们会面临很多基础挑战，比如做好会话稳定性、操作流畅性、冷启动速度等，而在满足98%以上的用户需求且业务趋于稳定后，一些在冲刺后遗留的性能天花板问题暴露在我们面前，其中 高并发接待 & 多开是两个重要的挑战，是旧账与难啃的硬骨头。

为何持续会有这些挑战存在？

1）历史技术选型，包含者成本、人力、效率等考量，飞鸽客户端使用的技术栈是react + electron：

* im sdk与业务渲染代码都由 js 编写，im sdk同时是cpu密集型 & io 密集型的组件，在高并发场景下，渲染频率也比较高，业务与sdk相互抢占cpu资源与io资源，导致收发消息慢、操作卡顿（高并发限制）。

* 由于im sdk运行在webview中，所以收发消息依赖webview存活，故多开账号 = 多个webview，内存成本线性增长。

2）im页面在web层面多次优化后已接近架构上限，无法基于现有架构做更多天花板的突破。

对于以上这些挑战，我们给出的解法是：对现有架构进行调整，使用Rust语言对im sdk进行重写，彻底解除这一块的性能瓶颈！

3、为什么选Rust语言？

飞鸽im sdk是一个对运行稳定性要求高的组件，其工程量大、逻辑复杂，对于异步特性使用非常频繁，其对于内存安全、 线程安全有着比较严格的要求。

假如使用C++，作为新手并没有把握能够将复杂的IM SDK少bug的编写下来（团队限制）。

Rust学习曲线虽然陡峭，但是其为安全设计的各类语言特性、强大的编译器，能够将新人编写代码的问题数降到最低（逻辑问题除外）。

并且飞书团队提供了客户端的rust生态库，帮助我们解决很多的基建问题，所以这里使用Rust是相当合适的。

Rust学习成长曲线：

4、飞鸽IM客户端历史架构的问题

如背景中所描述，历史架构存在这两个问题：

• 1）IM SDK 与 业务JS代码共用Weview资源，接待密集的时候，sdk与业务，互相抢占cpu与io资源，导致容易卡顿、消息延迟；
• 2）多开的账号必须依赖IM Webview存活（否则无法收到消息），内存线性增长。

5、飞鸽IM客户端新架构与预期目标

具体是：

• 1）Rust独立进程承担所有的im sdk的计算压力，可以大幅减轻js线程压力，可提升压力场景接待体验；
• 2）Rust im SDK 解除浏览器中的IO限制（如同域名并发数限制）；
• 3）解除Webview存活依赖，依靠rust进程也可收消息，为更多账号的多开能力提供了铺垫。

6、先用Rust进行技术可行性验证

为了验证推测切实可行，我们提前做了完备的POC验证。

在POC中，我们针对“单进程单线程模型”、“多进程模型”、“多线程模型”，这三种模型搭建了mvp demo，即简易的客服聊天模型，并进行压力测试，并监测其内存、cpu等指标。

通过POC，我们得出的结论是：

具体就是：

• 1）rust 整体优于 js，计算占比越重，优势越明显（高压时cpu差别能到达3倍以上）；
• 2）架构选型上，rust进程独立是最好的方案，稳定性更优、性能损耗相差较小。

7、新架构开始实施

路要一步步走，整个项目粗估下来会有上百的工作日，作为业务团队，我们无法在短期内投入大量的资源去做这个项目，所以需要一步一步拆解、验证、拿收益。

团队内native开发资源有限，这件事情的进行也需要团队进行学习、成长。下面我们将详细分享这个过程 。

8、新架构实施阶段1：Rust SDK工程基建

造房子先得有一个地基 —— Rust工程的基础建设，是Native业务的前置条件！

桌面端同学牵头搭建了整个RustSDK地基，地基解决的问题如下图所示：

需要做的工作：

• 1）业务容器：有规律的组织代码结构，进行业务隔离、资源隔离；
• 2）跨进程调用封装：降低业务调用难度；
• 3）建设日志系统、日志回捞：降低排查问题的难度；
• 4）构建跨平台异步执行环境：简化异步代码编写，底层封装，便于跨平台代码迁移；
• 5）跨平台编译，跨平台集成；
• 6）... ...

9、新架构实施阶段2：IM基础能力夯实

在拥有一部分地基后，我们开始针对IM SDK的基础能力进行实现和验证。

因为只有完成基础能力验证之后，我们才会有信心在新的架构上叠加更多的功能。

这阶段我们关注以下指标（ 希望其存在优化，至少不劣化）：

• 1）长链在线率；
• 2）消息发送成功率；
• 3）卡顿率；
• 4）Rust进程崩溃率、无响应率。

仅实现长链能力下沉，验证&提升其稳定：

本阶段论证结果如下：

• 1）Rust Crash率， 达成预期；
• 2）Rust无响应率 - 未达预期，可优化；
• 3）长链在线率 - 达成预期，但是存在优化空间；
• 4）卡顿率 - 不劣化 达成预期；
• 5）消息发送成功率 - 不劣化，达成预期。

这阶段的工作是考验耐心的，因为这个阶段并不能带来实质性的用户体验提升、也无法拿到明显的提升数据，只是作为中间阶段，它有存在的必要性。

这阶段后，在稳定性治理、基础能力验证、 Rust 语言经验、指标制定合理性这几方面，我们踩上了一个更结实的台阶，更有信心去进行更复杂的下一阶段。

10、 新架构实施阶段3：使用Rust实现IM SDK全部能力

夯实基础后，我们开始发力冲刺，大刀阔斧的对IM SDK进行重新设计、实现、联调以及上线。

此阶段要实现im sdk的全部能力、 并对线上运行的js im sdk进行替换。

由于飞鸽im对于通信模块的稳定程度要求是很高的，替换过程就像是在高速行驶的车辆上替换轮胎，如果出现问题也容易导致大量的客服负面反馈。

因此，新rust sdk的稳定性、异常问题时的兜底方案、灰度时的监控观察、对新增反馈的留意都很重要，放量过程会存在一定精神压力。

工作内容大致如下。

1）多实例的Rust IM SDK设计（商家单聊、群聊、平台客服）、Js -> Rust IMSDK跨端调用协议设计：

• a）分析、拆解所有Js Im SDK至今具有的能力，并以贴合Rust的方式重新设计；
• b）需要在协议设计中，尽可能的合并 & 简化 Js -> Rust的调用，以减少IPC通信成本。

2）开发：

• a）Rust IM SDK核心实现；
• b）Rust\Js适配同学紧密合作，根据协议进行业务实现、业务适配；
• c）密切沟通，发现问题及时纠偏；
• d）编写单测；

3）测试：

• a）各类IM场景回归测试；
• b）性能进行验证。

4）异常兜底方案实现：

设计数据冗余，当Rust进程出现崩溃、无响应、不可恢复的网络错误时，识别并fallback到 web版本，使用冗余数据快速恢复im sdk正常运行状态，确保用户体验。

5）稳妥的上线方案 & 稳定性治理。

6）调用&适配优化，结合Native能力进一步性能优化。

7）结果回收。

8）其中各个步骤都会存在一些挑战，在后后面的内容会提到。

调用简化模型：

IM Core简化模型：

11、新架构实施阶段4：基于稳定的RustIM SDK实现形态升级

最后的阶段，我们基于完善的Rust IM SDK的能力进行形态的升级。

本阶段正在进行中，完成后会做更多的分享。

1）多窗口改造：销毁后台的多开账号，让多开账号数量突破到25个。

2）消息提醒、通知流程改造。

3）消息本地化能力：加快消息上屏。

12、技术挑战与实践总结

12.1编程语言 & IM领域知识突破

一个有战斗力的团队，一定是持续学习、进步的。

比如：

• 1）获取学习的纯粹快乐：当沉浸在学习中，并感受到自己在进步的时候，会是一个快乐的状态；
• 2）逐步克服小挑战，及时获得正反馈；
• 3）在同事中找到伙伴和老师，询问与探讨：建立团队中的学习氛围。

12.2长周期技术项目，如何持续保持信心 ？

比如 ：

• 1）Leader与同事认可与支持 — 团队基础、价值观鼓励；
• 2）关注长期收益，训练自己延迟满足感；
• 3）做好阶段性分解与验证，缩短单个周期（如本文的一二阶段拆解，可逐步累积信心）；
• 4）增强自身实力，做好问题把控，及时发现&解决问题。

12.3高效合作

团队Native开发同学少，且各自并行业务需求，需合理的安排开发路线，减少总开发时长。

• 1）合理的设计开发并行路线，减少串行依赖
• 2）协议与接口先行；
• 3）各同学负责其相近&擅长的部分；
• 4）联调时缩短彼此距离，高效沟通。

12.4保障用户体验的灰度上线

1）编写模块的健康自检，检测到异常时用最小的代价切换备用老方案。

2）完善业务监控&技术指标监控：crash率、无响应率、长链在线率、发消息成功率、请求成功率、卡顿率等。

3）对真实用户使用体验进行跟踪：

• a）书反馈群组维护，及时获得用户反馈；
• b）与商家客服保持线下联系，获取一手体验情况。

4）放量节奏的把控：

• a）大型改动可以先给白名单用户试用，收集反馈；
• b）放出能够识别问题的量，解决问题后再继续放量；
• c）放量期间主动查询用户实时反馈数据，有问题及时解决。

12.5如何减少IPC通信成本带来的开销

频率过高的IPC通信可能使得CPU优化适得其反，因为老版本都运行在Js中，所以调用频率是没有节制的（循环读取数据也经常出现），必须要在设计上降低下来——降低业务JS线程的压力。

以下措施可以将本场景通信成本降低90%以上。

1）更高效的数据协议 protobuf：相较于json，数据更小、解析和序列化性能更高、跨语言生成代码工具。

2）Rust push to js：使用数据收集去重 + debounce批量更新的策略，合并多个数据回调接口，减少通信频率。

3）Js call rust（单次基础耗时4ms）：

• a）适当缓存数据，不用每次都回源查询；
• b）需要频繁调用的逻辑下沉Rust，Rust逻辑自完善。

12.6结果回收：极端场景下的优化大盘数据体现不明显

针对某种场景做的优化工作不容易在大盘数据中得到体现（尤其在灰度阶段），我们应该针对特殊场景建立新指标。

即编写策略，识别并收集极端场景下的数据：为了衡量极端场景的的卡顿优化，建立了忙碌与卡顿指标，可以衡量出用户接待忙碌程度与卡顿率的关系，并且通过此指标将优化清晰的衡量出来。

12.7Rust SDK的问题治理

具体是：

• 1）前期的问题不稳定，需更多信息辅助排查，日志尽量完整；
• 2）与真实用户群体保持联系，可加快问题验证、问题发现的过程；
• 3）需要建设便捷的日志回捞 & 日志分析工具（帮助快速找到日志还原现场）。

13、新架构带来的收益

压力评测：

数据表现：

解读一下：

• 1）客服发送消息，大盘端到端耗时降低 40%；
• 2）消息发送成功率三个9 -> 四个9；
• 3）im页面大盘卡顿率降低 15%；
• 4）密集接待场景，卡顿率降低 50%。

全量至今，再无大量进线导致卡顿的反馈。回访历史反馈用户，皆无因大量接待导致的卡顿现象

14、相关文章

[1] 阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践

[2] IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践

[3] IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的

[4] 如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源

[5] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[6] IM开发干货分享：IM客户端不同版本兼容运行的技术思路和实践总结

[7] IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践

[8] 从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结

[9] IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践

[10] IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK改造实践总结

[11] 抖音技术分享：抖音Android端手机功耗问题的全面分析和详细优化实践

[12] 社交软件红包技术解密(十二)：解密抖音春节红包背后的技术设计与实践

（本文已同步发布于：http://www.52im.net/thread-4620-1-1.html）

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第34 期。

[- 1 -] 快速裂变：见证微信强大后台架构从0到1的演进历程（一）

[链接] http://www.52im.net/thread-168-1-1.html

[摘要] 2个月的开发时间，微信后台系统经历了从0到1的过程。从小步慢跑到快速成长，经历了平台化到走出国门，微信交出的这份优异答卷，解题思路是怎样的？

[- 2 -] 如何保证IM实时消息的“时序性”与“一致性”？

[链接] http://www.52im.net/thread-714-1-1.html

[摘要] 实时消息时序和一致性是分布式系统架构设计中非常难的问题（尤其IM应用这种以消息为中心的应用形态），困难在哪？有什么常见优化实践？这就是本文要讨论的内容。

[- 3 -] IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？

[链接] http://www.52im.net/thread-715-1-1.html

[摘要] “用户在线状态的一致性”（单聊好友在线状态、群聊用户在线状态）是IM应用领域比较难解决的一个技术问题，如何精准实时的获得好友、群友的在线状态，是今天将要探讨的话题。

[- 4 -]IM群聊消息如此复杂，如何保证不丢不重？

[链接] http://www.52im.net/thread-753-1-1.html

[摘要] 由于“消息风暴扩散系数”的存在（概念详见《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》），群消息的复杂度要远高于一对一的单聊消息。群消息的实时性、可达性、离线消息是今天将要讨论的核心话题。

[- 5 -] 微信后台团队：微信后台异步消息队列的优化升级实践分享

[链接] http://www.52im.net/thread-801-1-1.html

[摘要] 本文分享了该组件2.0版本的功能特点及优化实践，希望能为类似业务（比如移动端IM系统等）的消息队列设计提供一定的参考。

[- 6 -] 移动端IM中大规模群消息的推送如何保证效率、实时性？

[链接] http://www.52im.net/thread-1221-1-1.html

[摘要] 当然，实际在生产环境下，群消息的发送都会想尽办法进行压缩，并开展各种改善性能的处理办法，而不是像上述举例里的直接扩散写（即2000人群里，一条消息被简单地复制为2000条一对一的消息投递）。具体有哪些优先策略？本文或许可以带给你一些启发。

[- 7 -] 现代IM系统中聊天消息的同步和存储方案探讨

[链接] http://www.52im.net/thread-1230-1-1.html

[摘要] 本文内容主要涉及IM系统中的消息系统架构，探讨一种适用于大用户量的消息同步以及存储系统的架构实现，能够支持消息系统中的高级特性『多端同步』以及『消息漫游』。在性能和规模上，能够做到全量消息云端存储，百万TPS以及毫秒级延迟的消息同步能力。

[- 8 -] 关于IM即时通讯群聊消息的乱序问题讨论

[链接] http://www.52im.net/thread-1436-1-1.html

[摘要] 问题描述：客户端A、B、C，服务端S，例如：A发三条群消息，B、C收到的消息都是乱序，目前问题：A发第一条消息失败之后排到队列，这时服务端还在持续发消息，那么第二条消息送达到B、C，然后客户端最先显示的就不是第一条消息，导致乱序出现。

[- 9 -]  IM群聊消息的已读回执功能该怎么实现？

[链接] http://www.52im.net/thread-1611-1-1.html

[摘要] 那么群聊消息的收发流程、消息的送达保证、已读回执机制，到底该怎么实现呢？这就是今天要讨论的话题。

[- 10 -] IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？

[链接] http://www.52im.net/thread-1616-1-1.html

[摘要] 任何技术方案，都不是天才般灵感乍现想到的，一定是一个演进迭代，逐步优化的过程。今天就聊一聊，IM群聊消息，为啥只需要存一份。

[- 11 -] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[链接] http://www.52im.net/thread-2015-1-1.html

[摘要] 本文将分享的是一套生产环境下的IM群聊消息系统的高可用、易伸缩、高并发架构设计实践，属于原创第一手资料，内容较专业，适合有一定IM架构经验的后端程序员阅读。

[- 12 -] [技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？

[链接] http://www.52im.net/thread-2017-1-1.html

[摘要] 听到这个问题，全厂的人都炸了。要知道一个微信群最多只能有500人啊，QQ群也只有2000而已。当你有机会加入一个2000人QQ群的时候，你就已经感受到“信息爆炸”的可怕……

[- 13 -] IM群聊机制，除了循环去发消息还有什么方式？如何优化？

[链接] http://www.52im.net/thread-2213-1-1.html

[摘要] 目前我是用循环来获取群成员，然后获取群成员ID去循环调用senddata()方法，想不用循环或者用其他什么方式来优化群聊循环发送这个机制，各位大佬有什么办法没？

[- 14 -] 网易云信技术分享：IM中的万人群聊技术方案实践总结

[链接] http://www.52im.net/thread-2707-1-1.html

[摘要] 本文内容是网易云信团队为了响应万人群聊功能需求，在设计实现万人群聊技术方案中总结的技术实践，借此机会分享给各IM开发者同行。

[- 15 -] 阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处

[链接] http://www.52im.net/thread-2848-1-1.html

[摘要] 本文适合有一定IM后端架构设计经验的开发者阅读，或许出于商业产品技术秘密的考虑，分享者在本次所分享的内容上有所保留，鉴于阿里对于钉钉在技术上的内容分享做的非常少，所以本文虽然内容不够全面，但仍然值得一读。

👉52im社区本周新文：《抖音技术分享：飞鸽IM桌面端基于Rust语言进行重构的技术选型和实践总结》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第33 期。

[- 1 -] IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计

[链接] http://www.52im.net/thread-3675-1-1.html

[摘要] 本文将重点讨论的是“关注”功能对应的技术实现：先总结常用的基于时间线Feed流的后台技术实现方案，再结合具体的业务场景，根据实际需求在基本设计思路上做一些灵活的运用。

[- 2 -] 阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化

[链接] http://www.52im.net/thread-3748-1-1.html

[摘要] 本文将要分享的是闲鱼IM消息在解决离线推送的到达率方面的技术实践，内容包括问题分析和技术优化思路等，希望能带给你启发。

[- 3 -] 阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践

[链接] http://www.52im.net/thread-3856-1-1.html

[摘要] 本篇将要分享的是闲鱼IM系统中在线和离线聊天消息数据的同步机制上所遇到的一些问题，以及实践性的解决方案。

[- 4 -] 探探的IM长连接技术实践：技术选型、架构设计、性能优化

[链接] http://www.52im.net/thread-3780-1-1.html

[摘要] 本文将要分享的是陌生人社交应用探探的IM长连接模块从技术选型到架构设计，再到性能优化的整个技术实践过程和经验总结。

[- 5 -] IM开发干货分享：浅谈IM系统中离线消息、历史消息的最佳实践

[链接] http://www.52im.net/thread-3887-1-1.html

[摘要] 本文将基于IM消息系统的技术实践，分享关于离线消息和历史消息的正确理解，以及具体的技术配合和实践，希望能为你的离线消息和历史消息技术设计带来最佳实践灵感。

[- 6 -] IM开发干货分享：IM客户端不同版本兼容运行的技术思路和实践总结

[链接] http://www.52im.net/thread-4202-1-1.html

[摘要] 本文将基于笔者的IM产品开发和运营实践，为你分享如何实现不同APP客户端版本与服务端通信的兼容性处理方案。

[- 7 -] 字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8

[链接] http://www.52im.net/thread-1693-1-1.html

[摘要] 字符编码是计算机技术的基石，对于程序员来说尤其重要，字符编码的知识是必须要懂的。

[- 8 -] IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质

[链接] http://www.52im.net/thread-2868-1-1.html

[摘要] 对于乱码这个看似不起眼，但并不是一两话能讲清楚的问题，是很有必要从根源了解字符集和编码原理，知其然知其所以然显然是一个优秀码农的基本素养，所以，便有了本文，希望能帮助到你。

[- 9 -]  史诗级计算机字符编码知识分享，万字长文，一文即懂！

[链接] http://www.52im.net/thread-4210-1-1.html

[摘要] 前一阵跟同事碰到了字符乱码的问题，了解后发现这个问题存在两年了，我们程序员每天都在跟编码打交道，但大家对字符编码都是一知半解：“天天吃猪肉却很少见过猪跑”，今天我就把它彻底讲透！

[- 10 -] 百度统一socket长连接组件从0到1的技术实践

[链接] http://www.52im.net/thread-4359-1-1.html

[摘要] 本文旨在探讨socket长连接技术在移动端的实践，并以iOS端为例，重点分享了百度在实现统一socket长连接组件过程中的技术选型和整体架构设计逻辑。并结合IM即时通讯聊天应用案例，展示长连接组件是如何在移动应用领域为类似业务场景提供解决方案的。

[- 11 -] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[链接] http://www.52im.net/thread-4470-1-1.html

[摘要] 本文将介绍淘宝 APP 统一网络库演进的过程，讲述如何围绕体验持续构建南北向从监测到加速一体化的终端网络架构，通过构建 NPM 弱网诊断感知能力，落地原生多通道技术/多协议择优调度手段，贴合厂商附能网络请求加速，实现去 SPDY 及规模化 IPv6/H3 协议簇的平滑过渡，为用户提供弱网更好、好网更优的 APP 加载浏览体验，支撑业务创造更多的可能性。

[- 12 -] 揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链

[链接] http://www.52im.net/thread-4471-1-1.html

[摘要] 本文将摘取企业微信的其中一个技术分支——IM体系之下的“关系链”内核要素，为你揭秘企业微信是如何支持超大规模IM组织架构的。

👉52im社区本周新文：《长连接网关技术专题(九)：去哪儿网酒店高性能业务网关技术实践》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由去哪儿网技术团队田文琦分享，本文有修订和改动。

1、引言

本文针对去哪儿网酒店业务网关的吞吐率下降、响应时间上升等问题，进行全流程异步化、服务编排方案等措施，进行了高性能网关的技术优化实践。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4618-1-1.html）

2、作者介绍

田文琦：2021年9月加入去哪儿网机票目的地事业群，担任软件研发工程师，现负责国内酒店主站技术团队。主要关注高并发、高性能、高可用相关技术和系统架构。主导的酒店业务网关优化项目，荣获22年去哪儿网技术中心TC项目三等奖。

3、专题目录

本文是专题系列文章的第9篇，总目录如下：

1. 《长连接网关技术专题(一)：京东京麦的生产级TCP网关技术实践总结》
2. 《长连接网关技术专题(二)：知乎千万级并发的高性能长连接网关技术实践》
3. 《长连接网关技术专题(三)：手淘亿级移动端接入层网关的技术演进之路》
4. 《长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践》
5. 《长连接网关技术专题(五)：喜马拉雅自研亿级API网关技术实践》
6. 《长连接网关技术专题(六)：石墨文档单机50万WebSocket长连接架构实践》
7. 《长连接网关技术专题(七)：小米小爱单机120万长连接接入层的架构演进》
8. 《长连接网关技术专题(八)：B站基于微服务的API网关从0到1的演进之路》
9. 《长连接网关技术专题(九)：去哪儿网酒店高性能业务网关技术实践》（* 本文）

4、技术背景

近来，Qunar 酒店的整体技术架构在基于 DDD 指导思想下，一直在进行调整。其中最主要的一个调整就是包含核心领域的团队交出各自的“应用层”，统一交给下游网关团队，组成统一的应用层。

这种由多个网关合并成大前台(酒店业务网关)的融合，带来的好处是核心系统边界清晰了，但是对酒店业务网关来说，也带来了不小的困扰。

系统面临的压力主要来自两方面：

• 1）首先，一次性新增了几十万行大量硬编码、临时兼容、聚合业务规则的复杂代码且代码风格迥异，有些甚至是跨语言的代码迁移；
• 2）其次，后续的复杂多变的应用层业务需求，之前分散在各个子网关中，现在在源源不断地汇总叠加到酒店业务网关。

这就导致了一系列的问题：

• 1）业务网关吞吐性能变差：应对流量尖峰时期的单机最大吞吐量与合并之前相比，下降了20%
• 2）内部业务逻辑处理速度变差：主流程业务逻辑的处理时间与合并之前相比，上涨了10%。
• 3）代码难以维护、开发效率低：主站内部各个模块之间严重耦合，边界不清，修改扩散问题非常明显，给后续的迭代增加了维护成本，开发新需求的效率也不高。

酒店业务网关作为直接面对用户的系统，出现任何问题都会被放大百倍，上述这些问题亟待解决。

5、吞吐量下降问题分析

现有系统虽然业务处理部分是异步化的，但是并不是全链路异步化（如下图所示）。

同步 servlet 容器，servlet 线程与业务逻辑线程是同一个，高峰期流量上涨或者尤其是遇到流量尖峰的时候，servlet 容器线程被阻塞的时候，我们服务的吞吐量就会明显下降。

业务处理虽然使用了线程池确实能实现异步调用的效果，也能压缩同步等待的时间，但是也有一些缺陷。

比如：

• 1）CPU 资源大量浪费在阻塞等待上，导致 CPU 资源利用率低；
• 2）为了增加并发度，会引入更多额外的线程池，随着 CPU 调度线程数的增加，会导致更严重的资源争用，上下文切换占用 CPU 资源；
• 3）线程池中的线程都是阻塞的，硬件资源无法充分利用，系统吞吐量容易达到瓶颈。

6、响应时间上涨问题分析

前期为了快速落地酒店 DDD 架构，合并大前台的重构中，并没有做到一步到位的设计。

为了保证项目质量，将整个过程切分为了迁移+重构两个步骤。迁移之后，整个酒店业务网关的内部代码结构是割裂、混乱的。

总结如下：

我们最核心的一个接口会调用70多个上游接口，上述问题：边界不清、不内聚、各种重复调用、依赖阻塞等问题导致了核心接口的响应时间有明显上涨。

7、 解决方案Part1：全流程异步化提升吞吐量

全流程异步化方案，我们主要采用的是 Spring WebFlux。

7.1选择的理由

1）响应式编程模型：Spring WebFlux 基于响应式编程模型，使用异步非阻塞式 I/O，可以更高效地处理并发请求，提高应用程序的吞吐量和响应速度。同时，响应式编程模型能够更好地处理高负载情况下的请求，降低系统的资源消耗。

2）高性能：Spring WebFlux 使用 Reactor 库实现响应式编程模型，可以处理大量的并发请求，具有出色的性能表现。与传统的 Spring MVC 框架相比，Spring WebFlux 可以更好地利用多核 CPU 和内存资源，以实现更高的性能和吞吐量。

3）可扩展性：Spring WebFlux 不仅可以使用 Tomcat、Jetty 等常规 Web 服务器，还可以使用 Netty 或 Undertow 等基于 NIO 的 Web 服务器实现，与其它非阻塞式 I/O 的框架结合使用，可以更容易地构建可扩展的应用程序。

4）支持函数式编程：Spring WebFlux 支持函数式编程，使用函数式编程可以更好地处理复杂的业务逻辑，并提高代码的可读性和可维护性。

5）50与 Spring 生态系统无缝集成：Spring WebFlux 可以与 Spring Boot、Spring Security、Spring Data 等 Spring 生态系统的组件无缝集成，提供了完整的 Web 应用程序开发体验。

7.2实现原理和异步化过程

上图中从下到上每个组件的作用：

• 1）Web Server：适配各种 Web 服务， 监听客户端请求，并将其转发到 HttpHandler 处理；
• 2）HttpHandler：以非阻塞的方式处理响应式 http 请求的最底层处理器，不同的处理器处理的请求都会归一到 httpHandler 来处理，并返回响应；
• 3）DispatcherHandler：调度程序处理程序用于异步处理 HTTP 请求和响应，封装了HandlerMapping、HandlerAdapter、HandlerResultHandler 的调用，实际实现了HttpHandler的处理逻辑；
• 4）HandlerMapping：根据路由处理函数 (RouterFunction) 将 http 请求路由到相应的handler。WebFlux 中可以有多个 handler，每个 handler 都有自己的路由；
• 5）HandlerAdapter：使用给定的 handler 处理 http 请求，必要时还包括使用异常处理handler 处理异常；
• 6）HandlerResultHandler：处理返回结果，将 response 写到输出流中；
• 7）Reactive Streams：Reactive Streams 是一个规范，用于处理异步数据流。Spring WebFlux 实现了 Reactor 库，该库基于响应式流规范，处理异步数据流。

在整个过程中 Spring WebFlux 实现了响应式编程模型，构建了高吞吐量、高并发的 Web 应用程序，同时也具有响应快速、可扩展性好、资源利用率高等优点。

下面我们来看下 webFlux 是如何将 Servlet 请求异步化的：

1）ServletHttpHandlerAdapter 展示了使用 Servlet 异步支持和 Servlet 3.1非阻塞I/O，将 HttpHandler 适配为 HttpServlet。

2）第10行：request.startAsync()开启异步模式，然后将原始 request 和 response 封装成 ServletServerHttpRequest 和 ServletServerHttpResponse。

3）第36行：httpHandler.handle(httpRequest, httpResponse) 返回一个 Mono 对象(即Publisher)，对 Request 和 Response 的所有具体处理都在 Mono 对象中定义。

所有的操作只有在 subscribe 订阅的那一刻才开始进行，HandlerResultSubscriber 是 Reactive Streams 规范中标准的 subscriber，在它的 onComplete 事件触发时，会结束 servlet 的异步模式。

对 Servlet 返回结果的异步写入，以 DispatcherHandler 为例说明：

1）第2行：exchange 是对 ServletServerHttpRequest 和 ServletServerHttpResponse 的封装。

2）第10-15行：在系统预加载的 handlerMappings 中根据 exchange 找到对应的 handler，然后利用 handler 处理 exchange 执行相关业务逻辑，最终结果由 result 将 ServletServerHttpResponse 写入到输出流中。

最后：除了 Servlet 的异步化，作为业务网关，要实现全链路异步化还需要在远程调用方面要支持异步化。在 RPC 调用方式下，我们采用的异步 Dubbo，在 HTTP 调用方式下，我们采用的是 WebClient。

WebClient 默认使用的是 Netty 的 IO 线程进行发送请求，调用线程通过订阅一些事件例如：doOnRequest、doOnResponse 等进行回调处理。异步化的客户端，避免了业务线程池的阻塞，提高了系统的吞吐量。

在使用 WebClient 这种异步 http 客户端的时候，我们也遇到了一些问题：

1）首先：为了避免默认的 NettyIO 线程池可能会执行比较耗时的 IO 操作导致 Channel 阻塞，建议替换成其他线程池，替换方法是 Mono.publishOn(reactor.core.scheduler.Schedulers.newParallel("biz_scheduler", 300))。

2）其次：因为线程发生了切换，无法兼容 Qtracer (Qunar内部的分布式全链路跟踪系统)，所以在初始化 WebClient 客户端的时候，需要在 filter 里插入对 Request 的修改，记录前一个线程保存的 Qtracer 的上下文。WebClient.Builder wcb = WebClient.builder().filter(new QTraceRequestFilter())。

8、解决方案Part2：服务编排降低响应时间

Spring WebFlux 并不是银弹，它并不能保证一定能降低接口响应时间，除了全流程异步化，我们还利用 Spring WebFlux 提供的响应式编程模型，对业务流程进行服务编排，降低依赖之间的阻塞。

8.1服务编排解决方案

在介绍服务编排之前，我们先来了解一下 Spring WebFlux 提供的响应式编程模型 Reactor。

它有最重要的两个响应式类 Flux 和 Mono：

• 1）一个 Flux 对象表明一个包含0..N 个元素的响应式序列；
• 2）一个 Mono 对象表明一个包含零或者一个（0..1）元素的结果。

不管是 Flux 还是 Mono，它的处理过程分三步：

• 1）首先声明整个执行过程(operator)；
• 2）然后连通主过程，触发执行；
• 3）最后执行主过程，触发并执行子过程、生成结果。

每个执行过程连通输入流和输出流，子过程之间可以是并行的，也可以是串行的这个取决于实际的业务逻辑。我们的服务编排就是完成输入和输出流的编排，即在第一步声明执行过程（包括子过程），第二步和第三步完全交给 Reactor。

下面是我们服务编排的总体设计：

如上图所示：

1）service：是最小的业务编排单元，对 invoker 和 handler 进行了封装，并将结果写回到上下文中。主流程中，一般是由多个 service 进行并行/串行地编排。

2）Invoker：是对第三方的异步非阻塞调用，对返回结果作 format，不包含业务逻辑。相当于子过程，一个 service 内部根据实际业务场景可以编排0个或多个 Invoker。

3）handler：纯内存计算，封装共用和内聚的业务逻辑。在实际的业务开发过程中，对上下文中的任一变量，只有一个 handler 有写权限，避免了修改扩散问题。也相当于子过程，根据实际需要编排进 service 中。

4）上下文：为每个接口都设计了独立的请求/处理/响应上下文，方便监控定位每个模块的处理正确性。

上下文设计举例：

在复杂的 service 中我们会根据实际业务需求组装 invoker 和 handler，例如：日历房售卖信息展示 service 组装了酒店报价、辅营权益等第三方调用 invoker，优惠明细计算、过滤报价规则等共用的逻辑处理 handler。

在实际优化过程中我们抽象了100多个 service，180多个 invoker，120多个 handler。他们都是小而独立的类，一般都不会超过200行，减轻了开发同学尤其是新同学对代码的认知负担。边界清晰，逻辑内聚，代码的不可知问题也得到了解决。

每个 service 都是由一个或多个 Invoker、handler 组装编排的业务单元，内部处理都是全异步并行处理的。

如下图所示：ListPreAsyncReqService 中编排了多个 invoker，在基类 MonoGroupInvokeService 中，会通过 Mono.zip(list, s -> this.getClass() + " succ")将多个流合并成为一个流输出。

在 controller 层就负责处理一件事，即对 service 进行编排（如下图所示）。

我们利用 flatMap 方法可以方便地将多个 service 按照业务逻辑要求，进行多次地并行/串行编排。

1）并行编排示例：第12、14行是两个并行处理的输入流 afterAdapterValidMono、preRankSecMono ，二者并行执行各自 service 的处理。

2）并行处理后的流合并：第16行，搜索结果流 rankMono 和不依赖搜索的其他结果流preRankAsyncMono，使用 Mono.zip 操作将两者合并为一个输出流 afterRankMergeMono。

3）串行编排举例：第16、20、22行，afterRankMergeMono 结果流作为输入流执行 service14 后转换成 resultAdaptMono，又串行执行 service15 后，输出流 cacheResolveMono。

以上是酒店业务网关的整体服务编排设计。

8.2编排示例

下面来介绍一下，我们是如何进行流程编排，发挥网关优势，在系统内和系统间达到响应时间全局最优的。

8.2.1）系统内：

上图示例中的左侧方案总耗时是300ms。

这300ms 来自最长路径 Service1的200ms 加上 Service3 的100ms：

• 1）Service1 包含2个并行 invoker 分别耗时100ms、200ms，最长路径200ms；
• 2）Service3 包含2个并行invoker 分别耗时50ms、100ms，最长路径100ms。

而右图是将 Service1 的200ms 的 invoker 迁移至与 Service1 并行的 Service0 里。

此时，整个处理的最长路径就变成了200ms：

• 1）Service0 的最长路径是200ms；
• 2）Service1+service3 的最长路径是100ms+100ms=200ms。

通过系统内 invoker 的最优编排，整体接口的响应时间就会从300ms 降低到200ms。

8.2.2）系统间：

举例来说：优化前业务网关会并行调用 UGC 点评（接口耗时100ms）和 HCS 住客秀（接口耗时50ms）两个接口，在 UGC 点评系统内部还会串行重复调用 HCS 住客秀接口（接口耗时50ms）。

发挥业务网关优势，UGC 无需再串行调用 HCS 接口，所需业务聚合处理（这里的业务聚合处理是纯内存操作，耗时可以忽略）移至业务网关中操作，这样 UGC 接口的耗时就会降下来。对全局来说，整体接口的耗时就会从原来的100ms 降为50ms。

还有一种情况：假设业务网关是串行调用 UGC 点评接口和 HCS 住客秀接口的话，那么也可以在业务网关调用 HCS 住客秀接口后，将结果通过入参在调用 UGC 点评接口的时候传递过去，也可以省去 UGC 点评调用 HCS 住客秀接口的耗时。

基于对整个酒店主流程业务调用链路充分且清晰的了解基础之上，我们才能找到系统间的最优解决方案。

9、优化后的效果

9.1页面打开速度明显加快

优化后最直接的效果就是在用户体感上，页面的打开速度明显加快了。

以详情页为例：

9.2接口响应时间下降50%

列表、详情、订单等主流程各个核心接口的P50响应时间都有明显的降幅，平均下降了50%。

以详情页的 A、B 两个接口为例，A接口在优化前的 P50 为366ms：

A 接口优化后的 P50 为36ms：

B 接口的 P50 响应时间，从660ms 降到了410ms：

9.3单机吞吐量性能上限提升100%，资源成本下降一半

单机可支持 QPS 上限从100提升至200，吞吐量性能上限提升100%，平稳应对七节两月等常规流量高峰。

在考试、演出、临时政策变化、竞对故障等异常突发事件情况下，会产生瞬时的流量尖峰。在某次实战的情况下，瞬时流量高峰达到过二十万 QPS 以上，酒店业务网关系统经受住了考验，能够轻松应对。

单机性能的提升，我们的机器资源成本也下降了一半。

9.4圈复杂度降低38%，研发效率提升30%

具体就是：

• 1）优化后酒店业务网关的有效代码行数减少了6万行；
• 2）代码圈复杂度从19518减少至12084，降低了38%；
• 3）网关优化后，业务模块更加内聚、边界清晰，日常需求的开发、联调时间均有明显减少，研发效率也提升了30%。

10、本文小结与下一步规划

1）通过采用 Spring WebFlux 架构和系统内/系统间的服务编排，本次酒店业务网关的优化取得了不错的效果，单机吞吐量提升了100%，整体接口的响应时间下降了50%，为同类型业务网关提供一套行之有效的优化方案。

2）在此基础上，为了保持优化后的效果，我们除了建立监控日常做好预警外，还开发了接口响应时长变化的归因工具，自动分析变化的原因，可以高效排查问题作好持续优化。

3）当前我们在服务编排的时候，只能根据上游接口在稳定期的响应时间，来做到最优编排。当某些上游接口响应时间存在波动较大的情况时，目前的编排功能还无法做到动态自动最优，这部分是我们未来需要优化的方向。

11、相关文章

[1] 从C10K到C10M高性能网络应用的理论探索

[2] 一文读懂高性能网络编程中的I/O模型

[3] 一文读懂高性能网络编程中的线程模型

[4] 以网游服务端的网络接入层设计为例，理解实时通信的技术挑战

[5] 手淘亿级移动端接入层网关的技术演进之路

[6] 喜马拉雅自研亿级API网关技术实践

[7] B站基于微服务的API网关从0到1的演进之路

[8] 深入操作系统，彻底理解I/O多路复用

[9] 深入操作系统，彻底理解同步与异步

[10] 通俗易懂，高性能服务器到底是如何实现的

[11] 百度统一socket长连接组件从0到1的技术实践

[12] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[13] 百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践

（本文已同步发布于：http://www.52im.net/thread-4618-1-1.html）

本文由得物技术暖树分享，有修订和改动。

1、引言

本文分享的是得物针对现有的消息推送系统的消息送达耗时、实时性、稳定性等方面问题，从零到一构建完整的消息推送质量监控体系和机制的技术实践。

2、消息推送的作用

2.1 什么是消息推送

消息推送每天都在我们的手机上发生，如下图所示，除非你的手机没有安装App或关闭了通知栏权限。

2.2 消息推送的价值

从用户的生命周期来看，消息推送对于提高App活跃度、提升用户粘性和用户留存率都起到了重要作用。

比如：

• 1）提升新用户次日留存，低成本促活，对平台的短期留存率影响显著；
• 2）提升老用户活跃度，push可以通过外部提醒起到拉活的作用；
• 3）流失用户召回，当用户流失后，若push权限未关闭，通过消息推送的方式，有可能重新唤醒用户。

对于第 2）点，很多内容平台类App的用户push首次启动占比可达 10%以上，因此push对DAU的增量贡献不容小觑。

3、业务背景和技术痛点

消息中心为得物App提供了强大，高效的用户触达渠道。其中push对于得物DAU的贡献有可观的占比，这也就意味着每一条推送消息都是一次与用户沟通的宝贵机会。所以推送的稳定性成为我们关注的首要问题。

那么我们遇到的以下痛点就亟待解决：

1）消息中心没有明确消息推送的耗时标准，业务和技术之间存在gap，业务方对于推送的消息什么时候到达没有明确的心理预期。

2）从技术上来讲消息推送各个节点的耗时不明确，无法对各个节点的耗时做针对性的优化，这也就需要我们针对消息推送的节点耗时进行监控。

3）消息推送的稳定性依赖于第三方的推送通道，而三方通道对于我们来讲就是个黑盒子，如何做到三方通道异常及时发现并止损也是需要考虑的问题。

4）在我们正常的迭代过程中有时候不可避免的会出现些异常或者有坏味道的代码，这些问题能不能及时发现、及时止损，能不能及时告警出来。

4、稳定性监控体系

SLA（Service-Level Agreement），也就是服务等级协议，指的是系统服务提供者（Provider）对客户（Customer）的一个服务承诺。这是衡量一个大型分布式系统是否“健康”的常见方法。

在开发设计系统服务的时候，无论面对的客户是公司外部的个人、商业用户，还是公司内的不同业务部门，我们都应该对自己所设计的系统服务有一个定义好的SLA。因为SLA是一种服务承诺，所以指标可以多种多样。

最常见的四个SLA指标：

• 1）可用性；
• 2）准确性；
• 3）系统容量；
• 4）延迟。

 

对于消息推送而言，我们主要关注的是消息能否及时可靠的送达给用户，也就是SLA中关注的时效性和稳定性的问题。

目前消息中心针对实效性和稳定性的开发已经完成并初显成效。

系统架构图：

下面主要针对时效性和稳定性的监控做一些介绍。

5、时效性监控的技术实现

5.1 节点的拆分

如何做到时效性的无死角监控，那么我们就要对消息推送的整个流程进行拆分，把整个流程拆分成若干个独立且无依赖的可监控节点。

从消息系统流转图中可以看到：整个推送流程是清晰明了的，消息的的推送主要会经历推送鉴权、用户查询、防疲劳过滤、防重复过滤等的逻辑处理，考虑到每个业务逻辑的处理是相互独立且无依赖的，那我们就可以根据具体的业务处理逻辑进行节点的拆分，这样就可以做到拆分无遗漏，监控无死角。

拆分后的具体节点如下：

5.2 节点耗时的计算

具体的节点拆分逻辑和耗时逻辑的计算如下图：

 

节点耗时的计算：记录节点消息推送到达的时间，并计算节点推送耗时，例如：防疲劳耗时 = T7(antiFatigueConsumeTime) - T6(checkrepeatConsumeTime)。

节点阻塞量的计算：记录节点消息推送的瞬时阻塞量， 例如：防疲劳节点阻塞量 = 防疲劳的总量 - 防疲劳已经处理的量。

5.3 节点指标的制定

既然需要监控的节点已经拆分明确了，那针对这些节点我们监控哪些指标才是有意义的呢。

1）目前消息推送高峰耗时较长，各业务域对于消息的到达时间也没有明确的心理一个预期，另外消息中心也无法感知推送在整个链路各个节点的耗时情况，无法针对节点耗时做到有针对性的优化，所以节点的推送量和推送耗时就是我们需要重点关注的指标。

2）节点的阻塞量可以让我们及时感知到推送中存在的积压问题，在大促期间，消息的推送量也会达到一个高峰，消息目前是否有堆积，处理的速度是否跟的上，是否需要临时扩容，那么节点的阻塞量就成了一个比较有意义的参考指标。

考虑到消息推送是有优先级的并且区分单推和批量推，所以我们要针对不同的优先级和推送方式设置不同的标准。

消息推送耗时的具体标准如下：

5.4 技术方案的实现

为了能感知到消息推送中发生的异常和耗时情况，这就需要我们标准化监控指标和监控的节点。

其中耗时指标可以感知节点的耗时和代码的坏味道，阻塞量可以监控到节点的堆积情况，推送成功率可以感知节点的推送异常等。

另外节点拆分后我们可以很快定位到异常发生的具体位置，经过拆分监控的主要节点包括鉴权、风控、用户查询、防疲劳、防重复、厂商调用等。

另外消息中心每天推送大量消息给得物用户，SLA监控任何一个操作嵌入主流程中都可能导致消息推送的延迟。这也就要求监控和主流程进行隔离，主流程的归主流程，SLA 的归 SLA，SLA 监控代码从主流程逻辑中剥离出来，彻底避免SLA代码对主流程代码的污染,这也就要求SLA逻辑计算需要独立于推送业务的主流程进行异步计算，防止SLA监控拖垮整个主流程，那么Spring AOP+Spring Event就是最好的实现方式 。

5.5 成果

消息推送实效性监控做完之后，对服务节点耗时异常可以及时感知，同时也完成了关键节点耗时的指标化。

可以明确的看到所有节点在各个时间的耗时情况，同时也对消息推送针对各个节点的的优化起到了指导作用。

时效性节点监控：

时效性节点告警：

6、厂商推送监控的技术实现

6.1 监控指标制定

消息推送接入的有多个推送通道，如何做到对这些通道做到无死角的监控，及时感知呢。

1）在做厂商监控之前，我们就已经遇到了厂商通道推送跌零的情况，这种情况下整个推送通道都挂掉了，我们要及时通知厂商进行修复，所以厂商推送跌零告警和厂商余量监控是必须的。

2）从现有数据来看，厂商的推送成功率、回执成功率、点击率都稳定在一定的的区间。如果厂商推送的指标数据偏离这个区间则说明推送有异常，所以推送成功率、回执成功率、点击率的监控是必须的。

3）另外从业务请求发送的用户数来看，每天的消息推送基本是稳定的，相对应的厂商的回执数量和点击数量也是稳定的，那么对厂商推送成功的数量，回执的数量和点击的数量监控也有一定的参考意义。

业务侧请求发送的用户数：

厂商监控告警：

6.2 技术方案实现

厂商每天有数亿的消息推送，这也就意味着厂商的监控不能嵌在主流程中处理。厂商的监控代码要从主流程逻辑中剥离出来，避免监控拖垮主流程，同样避免监控异常影响到推送的主流程。

针对厂商推送的监控，目前使用的是有界内存队列实现：

6.3 成果

消息推送厂商监控上线之后，可以及时感知到厂商推送的异常信息，对于厂商推送的异常和厂商规则的更改等可以做到及时的感知。

 

7、 稳定性监控体系带来的收益

7.1 异常的及时发现

监控上线后及时发现了发现了厂商推送线程关闭失败，厂商推送跌零、厂商营销消息规则更改、厂商通道偶发不可用等问题，并做到了及时的止损。

1）在时效性监控上线之后，发现了因厂商推送线程创建关闭失败导致线程数逐渐上升问题，避免了线上故障的发生。

2）厂商异常导致推送跌零，监控发现后及时通知到厂商并止损。

3）发现厂商营销消息规则更改的异常，并及时经梳理各大厂商文档后发现除了多个厂商通道在未来一个月内也会有规则的更改，消息平台及时适应了厂商规则，接入厂商系统通道，做到了及时止损。

7.2 服务性能的提升

时效性监控上线后发现了多个服务可以优化的点，其中多个厂商和推送节点在高峰推送时耗时较高，很明显节点耗时和厂商推送 SDK 连接池和连接时间参数需要优化。优化后消息推送整体的吞吐量实现了翻倍的提升。

8、 展望未来

由于时间问题，目前消息监控只做了时效性和厂商推送稳定性相关的监控，但是监控上线后带来的收益还是比较可观的，可以预见的是监控的构建在未来必将带给我们更大的收益，后续我们可以从以下点丰富现有监控。

1）考虑到业务预的推送量和推送时间是稳定的，那么我们可以针对业务维度添加推送数据的监控，及时感知上游推送数据的变化。

2）其次我们可以针对各个节点的推送异常、漏斗转化率、服务性能等做监控，进一步丰富消息平台的监控体系。

3）对于消息推送来讲也要考虑推送的转化率问题，那么卸载、屏蔽等指标也是我们需要监控的点，通过这些业务指标及时感知推送的效果，做到精细化的管控。

9、本文小结

消息平台监控上线后带来的收益还是比较可观的，包括多次异常的及时发现和止损，还有发现多个个可以优化的性能点，实现了服务高峰吞吐量的翻倍。

同时也解决了我们现在遇到的以下痛点：

1）时效性明确的给到了不同优先级的耗时标准，避免了业务和技术之间的gap，业务方对于推送的耗时也有了明确的心理预期。

2）时效性使得节点耗时的性能问题可以一目了然，通过对现有节点耗时问题的优化，消息服务的吞吐量实现了翻倍的提升。

3）厂商稳定性监控使得厂商异常可以及时感知，其中厂商稳定性监控上线后发现多起厂商推送的异常，并做到了及时的解决和止损。

4）SLA时效性和厂商稳定性上线后，消息中心可以及时感觉到推送链路的异常和代码的坏味道，特别是对于新上线的代码，如果存在异常可以及时感知。

10、相关文章

[1] 极光推送系统大规模高并发架构的技术实践分享

[2] 魅族2500万长连接的实时消息推送架构的技术实践分享

[3] 专访魅族架构师：海量长连接的实时消息推送系统的心得体会

[4] 实践分享：如何构建一套高可用的移动端消息推送系统？

[5] Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)

[6] 腾讯信鸽技术分享：百亿级实时消息推送的实战经验

[7] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[8] 京东京麦商家开放平台的消息推送架构演进之路

[9] 技术干货：从零开始，教你设计一个百万级的消息推送系统

[10] 长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践

[11] 喜马拉雅亿级用户量的离线消息推送系统架构设计实践

[12] 直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路

[13] 消息推送技术干货：美团实时消息推送服务的技术演进之路

[14] 揭秘vivo百亿级厂商消息推送平台的高可用技术实践

11、 得物分享的其它文章

《IM跨平台技术学习(七)：得物基于Electron开发客服IM桌面端的技术实践》

《得物从0到1自研客服IM系统的技术实践之路》

《得物自研客服IM中收发聊天消息背后的技术逻辑和思考实现》

（本文已同步发布于：http://www.52im.net/thread-4614-1-1.html）

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，支持iOS、Android、H5、小程序、Uniapp、标准Java平台，服务端基于Netty编写。

工程开源地址是：

• 1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

关于RainbowChat

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► 版本更新记录：http://www.52im.net/thread-1217-1-1.html
► 全部运行截图：Android端、iOS端
► 在线体验下载：专业版(TCP协议)、专业版(UDP协议)      （关于 iOS 端，请：点此查看）

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。

* RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架  MobileIMSDK 实现）。

v11.0 版更新内容

此版更新内容（更多历史更新日志）：

（1）Android端主要更新内容【新增“@”功能、消息引用功能等】：

• 1）[新增] 新增“@”功能；
• 2）[新增] 新增消息引用功能（支持引用全部消息类型）；
• 3）[bug] 解决了转发的是收到的短视频消息时，发送者这边不从网络加载预览图的问题；
• 4）[bug] 解决了离线好友消息在首页“消息”列表上显示的时间不是最后一条消息的发送时间问题；
• 5）[优化] 首页消息列表中的语音消息将显示语音时长（跟新版微信一样）；
• 6）[优化] 其它优化及bug修复。

（2）服务端主要更新内容：

• 1）[新增] 增加了“@”功能相关数据字段和代码逻辑的实现；
• 2）[新增] 增加了消息引用功能相关数据字段和代码逻辑的实现；
• 3）[优化] 更新了消息推送特权接口，支持陌生人、好友、群聊3种消息的推送，且增加了主机ip检查（提高安全性）；

此版新增功能运行截图（更多截图点此查看）：

本文由百度搜索技术平台研发部分享，本文有修订和改动。

1、引言

分布式数据传输系统是一种用于在多个计算节点之间高效传输大量数据的系统，诣在高效的解决大规模数据迁移、备份、跨地域复制等问题。其广泛应用在实时数据流传输、跨数据中心数据迁移、多媒体传输等场景，在大多数企业中的日志管理、业务数据建库等场景中也都会使用到。

众所周知，数据的高效传输往往直接影响着企业对市场先机的把握，对企业发展有重要意义，特别是在金融领域，如证券行业，它对分布式数据传输系统的设计提出了更高的要求，证券领域数据变化飞快，一个高时效、稳定的数据流传输系统不仅能有效的提升用户体验，更能提供用户一手的投资信息，有助于用户的投资决策，进而拉进企业与用户的距离。

本文将通过一个百度搜索旗下的金融场景案例来分享构建高实时、高可用的分布式数据传输系统的技术实践。

2、业务背景

作为百度搜索场景下时效性要求较高的业务，金融承载着每天数千万次的用户搜索请求。

而在2021年以前，金融业务的数据一直都是采用传统的互联网引入方式，该方式的特点是接入成本较低，但受公网等不可控因素影响，数据时效性较差，且数据断流、错误等问题频出，随即而来的就是业务维护成本较高，十分不利于产品迭代。

我们基于此发起了一个证券数据直连项目，诣在通过接驳全球各大证券交易所数据中心来构建一个高时效、高可用的分布式传输系统，从而有效的解决传统数据引入方式（公网抓取、推送）所带来的时效性、稳定性、正确性等问题，进而满足全国乃至全球用户的金融需求。

3、设计目标

3.1业务目标

接驳全球各大证券交易所Level-1行情数据，来覆盖全量上市公司股票、外汇、期货、ETF、涡轮牛熊等证券业务来满足用户需求，时效性追平金融行业竞品，为打造强大的金融生态做数据基建储备。

Level-1行情简称LV1行情：是交易所根据交易规则发布的即时行情信息，数据格式包括基于FIX/FAST协议的接口和TXT文件、二进制数据流等，行情通过交易所信息技术公司的高速地面网和宽带广播卫星系统发布或上证所信息网络有限公司的互联网和专线传输。

3.2技术目标

1）基础设施建设：协同交易所、运营商完成物理专线的链路部署，通过物理专线接入的方式在百度云机房接入上海、深圳、香港、纳斯达克证券交易所数据中心，适配交易所单、组播协议将二进制流/文本数据引入到百度内部，再分别完成华南、华北、华东、香港（支持海外访问）地域的数据存储与转发，同时支持负载和流量调度来支撑各地域的用户请求。(注：这里的物理专线特指光缆）

2）时效性和稳定性提升：行情数据检索99分位耗时不超过200ms，数据稳定性从99%提升至99.99%以上，数据灾备能力从1主0备升级至1主2备。

3）数据安全：基于百度安全能力，构建类似的防火墙策略来严格控制每一个机房、每一个集群的出入权限，并且配置好相应的安全组策略。

4、关键思路

从功能和网络拓扑上来看，一个高时效、高可用的金融数据传输系统至少需要包含以下几个部分，我们逐个来进行解读。

4.1接入层

适配全球各大交易所单、组播传输协议，确保数据能在专线物理网络正常传输。

接入主要有2种方式：

• 1）一种是走互联网；
• 2）一种是走物理专线。

前者相对比较灵活：各类数据协议基本都可以支持，有直接走HTTP（GET/POST），或者是走消息队列的发布订阅等等，接入成本较低，属立即接入那种，但受公网的不可控因素影响，在传输效率和安全性上相对后者会有比较大的差距，我们一般会把互联网的方式当做一个灾备能力存在。

专线方式的特点：是仅点对点传输，由于用的是独立的光缆，在有限带宽内理论可以做到无争用状态，不受公网影响，属可靠传输，传输协议私有化，增加了更多的认证机制。因此也更安全，区分不同应用场景，像证券类数据传输，一般交易所采用的是单播、组播方式，当下用的多的是组播。另外专线中也有主备的概念，一般会预留1-2条线路做灾备，整体下来，专线的费用要更昂贵一些，接入的周期也更长，往往长达几个月。

4.2网络层

完成华南、华北、华东百度云机房虚拟网络架构建设，包括子网、路由、网关等。

虚拟网络的核心组成部分主要是子网、路由、网关、虚拟机，其中每个子网关联着一个虚拟机集群，我们把整个组成部分（域）统称为一个VPC（Virtual private Cloud），路由又区分为TGW路由和对等连接。

这里主要关注对等连接，它是为用户提供了VPC级别的网络互联服务，使用户实现在不同虚拟网络之间的流量互通，实现同区域/跨区域，同用户/不同用户之间稳定高速的虚拟网络互联，其核心是基于对路由表的操作，对等连接也支持配置地域级的DNS同步。

网关又分为NAT网关和专线网关：

1）一个对外：比如设置SNAT和DNAT规则用于统一网段的外网出口；

2）一个对内：对内其实就是确保能够走专线和内部网络打通。

4.3传输层

完成各机房内的数据解析、存储、同步、转发等。

对于接入层获取到的数据我们分为三个级别：

1）像交易所主要是二进制流、文本为一级数据，我们需要保留近一段时间的原始数据落在本地（一级数据管理集群），以便用作应急回放。

2）而解码后的数据为二级数据，落在二级数据管理集群上，主要用于跨地域同步。

3）最后，对解码后的数据进行计算&加工，作为三级数据，落在三级数据管理集群用于承接应用服务。同时，按协议解码后的数据按照使用场景区分为实时流（如分时）、延时流（如K线），延时流经过实时流计算得来，实时流同步进内存用于提升IO效率，延迟流通过实时流的计算后异步进DB，DB维护在三级数据管理集群上。

4.4应用层

负载/流量调度、监控能力等建设。

应用层的设计，主要有两个方面的考虑：

1）一方面是对于接入层的负载和流量调度，如通过部署websocket/http服务来支撑百度用户流量，使用BLB（Baidu Load Balance）将同一区域的多台百度智能云服务器虚拟成一个组，设置一个内网或外网的服务地址，将前端并发访问转发给后台多台云服务器（BCC），实现应用程序的流量均衡，性能上实现业务水平扩展。

负载均衡还通过故障自动切换及时地消除服务的单点故障，提升服务的可用性，支持服务器调度权重策略配置，并支持TCP、HTTP等协议。

2）一方面是对监控的应用，如请求/数据传输日志落盘、统计、分析以及流量和sla监控等。

4.5小结

将以上四层能力建设后，此时单机房内的网络拓扑应该如下图所示。

注：DCC/BBC/BCC都是百度云范畴的机器类型，更多细节可以参考百度智能云私有网络：https://cloud.baidu.com/doc/VPC/s/Vjwvytu2v。

5、核心难点1

公网和私有网络方式下如何在云上完成多协议适配，尤其是在私有网络中适配单播、组播协议以及如何做组播转单播。

5.1公网&私有网络接入介绍

对于一个数据传输系统来说，最重要的一点其实就是能支持多协议的数据适配来提升系统的灵活性，证券交易所一般提供的接入方式有公网接入和私有网络接入，公网接入的成本较低，一般周粒度就可完成，没有复杂协议约束。

而私有网络往往会有更高的要求，协议上大部分都要求具备单播介入能力，少部分像纳斯达克和深圳交易所会要求下游支持组播接入。绝大多数的云厂商是无法直接在虚拟机上适配的，传统券商基本都是完全使用昂贵的物理机资源来承载，虽然物理机插拔更方便也更稳定，但运维管理成本也更高。

两种方式在效果和成本上也有本质的区别：

1）公网接入：公网比较常见的数据接入方式主要是HTTP/HTTPS方式，当然也会有RPC/FTP，只是用的相对少一些。

为了提升数据传输安全，双方可以在调用前协商好数据加密算法和密钥。优点是接入成本较低，能快速应用，尤其在跨洋传输上会有体现。缺点是走的公共线路，网络不可靠，且数据易被截获，当攻击者捕获两端的数据包后，哪怕不能完全解析，也可以实施一些流量攻击手段以影响服务稳定性。总的来说，一般不会对于安全性、时效性要求较高的数据采用该方式接入，更多是只是一种备用方式（特殊场景除外，如跨洋传输）。

2）私有网络接入：公司内网其实就属于一个私有网络，但是对于跨公司传输数据的场景，要想构建私有网络，一般会走物理专线接入的方式。

这种点对点传输方式的显著优点是专网专用且安全性较高，基本不受公共网络影响（自然灾害等不可抗力除外），在带宽范围内基本可以做到无网络争用状态（数据即发即达），由于是私有网络（双端内网传输），基本不用担心数据安全问题，而且往往还会增加额外的数据校验手段，尤其在金融场景，会有严格的token（硬/软）认证，该方式的缺点是成本相比公网传输接入成本更高，一般要持续数月，费用更昂贵，一般在上百万元，依赖选取的传输介质（一般选择光纤）和带宽。

5.2私有网络中单播、组播协议接入方案

私有网络有单播、广播、组播之分。

1）单播：相对比较好适配一些，走静态路由的方式在同一个VLANID下分别配置云端和IDC端的IP段作为IPV4专线互联地址即可。

2）广播：一般是对于服务端而言，比如证券交易所下游对接着全球范围的所有券商，数据源是相同的，一般会采用广播的机制把数据推送给所有下游。

3）组播：一般是要求下游需要适配，现如今大部分业务都已经上公有云，在云上常用虚拟化技术来完成服务器集群的部署。

对于虚拟机来说，更多的支持单播传输，不支持组播传输，往往需要在专门的物理设备（组播路由器、或特定的组播软件）上配置转发组播报文的路由，路由表关联着具体的路由协议（如PIM），再用IGMPV3协议来完成组播成员和报文的管理，通过动态BGP维护邻居关系（现在的云厂商上对BGP的可能是固定分配AS号，如果有AS的要求还是需要在物理机上单独做），我们可以圈出一部分物理资源专门承载组播数据传输，通过配置IGMP Snooping（可以将组播报文转发到二层数据链路层，实现组转单，注意版本需要是3，否则无法转发IGMPV3报文）+ AP完成组播转单播配置，再通过双网卡（WAN口+LAN口）形式实现专线网络数据接入&同步到百度内网，物理机通过三层交换机来关联，构造出类似下面的网络拓扑（如下图所示）。

6、核心难点2

6.1概述

数据管理&跨地域同步，数据灾备能力、时效性提升。

数据的分层管理主要是应对单机房内的场景，而对于跨机房或者说跨地域的主要难点是数据同步，后者需要更多的考虑跨机房数据传输效率和灾备管理，核心是网络设计。

6.2数据管理

按使用场景的不同，将数据分交易所二进制流数据（原始数据流）、文本数据、业务数据/日志等。

1）原始数据流：主要应对单机房、跨机房传输场景，当出现下游业务服务异常导致的数据展现错误时，存储的原始数据流可以很好的对数据进行回放，以便快速恢复业务，尤其是应对金融证券数据传输场景，证券交易所一般不会推送重复数据，如果下游业务服务异常导致存储的业务数据全部失效或为脏数据，那可能只能通过refresh主动请求上游来重新获取。

但这样做可能会出现核心数据丢失，由于这种方式的效率较低，还会扩大业务受损的影响面，因此一般会先存储交易所下发的原始数据流，业务可以自定义存储方式和周期，当出现问题时，可以通过『重播』原始数据流来止损。

另外原始数据流还能用于在对等网络中的跨机房恢复业务数据。

2）业务数据流：主要应对单机房传输的场景，根据模块分工的不同，分证券的实时行情、历史行情等等，对于单机房数据集群的管理我们有很多方式，对于自研的DB，在调度上可以用一些标准的分布式管理手段（如zk），数据同步的手段一般需要自定义，对于传统的DB如Mysql、Redis、Mongo等，一般有标准化的数据同步方式和调度模式。

6.3跨地域同步

跨机房地域同步的前提是多个机房之间需要有直接或间接关联关系的专用物理网络，即确保网络是可达的，然后再结合虚拟网络完成子网及路由配置。

对于具有直接网络关联关系的2个机房来说，我们的对等网络（Peer Connection）设计稍微简单一些。

现在各个云厂商也基本都支持直接配置了，其原理是首先在同一个VPC下划分好子网并规划好集群规模，其次通过配置路由表的方式完成本端和对端的下一跳关联，这样就完成了2个直接对端的对等网络建设。

接着再配置和内网专线的路由，就能做到云机房->内网机房的网络互通。

但如果2个机房没有直接关联关系，而又需要完成本端和对端数据同步怎么办呢，比如有A B C三个机房，只有A-B B-C有直接关联关系，而我们想要让A-C关联，这时候不可能说再建立一条物理链路，我们可以采用类似桥接的方式（或者叫隧道），同时关联A-B-C三个机房，其中B作为一个"网桥"，再通过NAT技术完成IP地址转换，确保C可以识别从A过来的路由，而A-B B-C 正常采用对等网络的方式完成基础网络配置，这样就可以胯多个机房进行通信，由于是物理网络传输，机房间的耗时不会有很大差别（30ms内）。

由于网络细节的篇幅较多，我们不做详细的赘述，这里我们看看跨地域同步的网络架构（如下图所示）。

注：图中网段可以根据不同场景做划分，这里只做简单介绍。

6.4数据灾备能力、时效性提升

数据灾备：我们一般选择离各个证券交易所就近的一个接入点，比如上证选择在上海机房接入，深证选择在广州接入，纳斯达克在香港接入，每个接入点配置2条专线用做物理链路的主备，同时扩展一条互联网通路（注意这里的互联网也是直接和交易所对接，已经不是传统数据引入渠道）做次备，链路默认都是活跃状态，有专们的物理设备会根据专线的健康状况（自定义逻辑）自动切换。

最后，再根据上面提到的跨地域同步的原理，在云机房关联各条物理链路，在每条物理链路上抽象出独立的VPC，通过构建网络拓扑实现跨机房数据复制及灾备。

时效性：物理专线（光缆）接入方式天然的优势就是数据"即发即达"，因为在固定带宽内基本不存在网络争用，而且现在大部分线路都会配置中继，其损耗带来的影响相对可控，因此接入方式就决定了数据传输的时效性。

相比传统互联网接入方式，单从数据上来看，专线接入SLA超过5个9（互联网接入2个9），当然也会配置上重传机制来进一步提升数据到达的可靠性。

交易所下发数据的数据频率按市场划分，A股一般3s/笔，港美股没有特殊限制，即有成交即下发，除去光损耗带来的影响，最快可以到3ms/笔，由于频率越高，对机器要求也越高，为此我们特殊做了一些限频操作，整体的数据时效性基本会在60ms（99.99+分位）内。

7、核心难点3

7.1概述

集群管理&单地域、跨地域流量调度。

流量调度生效在应用层，主要是找到一种高效的调度/负载方式来对内/外的业务提供数据支撑，从协议上/应用场景划分主要有TCP/HTTP，策略上因业务而异，主要还是基于对流量分配中权重的定义。

比如有基于RS健康检查的分配，每隔一段时间探测一下下游集群的健康状况来动态调整流量配比，也可以根据下游机器的连接数来分配，还可以基于对资源访问的热度来分配，区分单地域和跨地域场景如下面所述。

7.2单地域场景

现在各个云厂商都有相应的流量调度产品支撑，比如百度云上有BLB（Baidu Load Balance），可以很轻松构建一个调度规则出来，在BLB下可以设置调度集群的协议（TCP/HTTP），然后关联对应的服务器集群，最后给不同的服务器集群配置权重策略。

当流量进来时，BLB会帮我们完成自动分配，在某一个集群出现问题时，可以手动调整集群权重来干预流量配比，即所谓的切流。

7.3多地域场景

多个机房间的流量调度策略是在云上一般是隔离开的，当然我们可以在多个机房的最上层再抽象出一个专门的调度集群，对外暴露一个VIP。

在这个VIP上配置多个地域之间的调度关系，互联网公司基本上也都是这么做的，更多的是针对超大集群规模的场景，而且VIP的选取也是有条件/成本的。

但如果想低成本快速在云上创建一个能支持多地域同时访问且具备自动化流量调度的应用，且云上又不支持多地域共享VIP的功能时，我们可以尽可能多的基于云上已有的功能自己完成，在每个机房内部单独抽出一个类似nginx的集群，每个集群上维护着不同于本地域的调度关系，它们的下游就是不同于本机房的BLB，同时互相检查对方的健康状况并上报监控系统，这样当出现异常时，除了能针对性的在本机房内完成BLB级的流量调度，还能做到多机房间的流量切换，以提升机房间的灾备能力。当然，也需要有足够的容量。

8、总体设计

上图各个模块的作用如下（各模块均采用多路复用）：

1）源数据接入集群：适配2种方式（互联网/物理专线）+各类协议（互联网、单播、组播）的数据源接入；

2）源数据转发集群：确保各机房源数据的一致性，降低由于业务服务本身带来的数据不一致问题；

3）数据解析集群：公共模块，主要是针对源数据进行统一的处理，以便转发给下游各业务；

4）业务数据集群（实时/延时流）：负责将数据解析集群下发的内容转换成业务详细数据，也就是B端或C端用户看到的数据；

5）网关集群：负责承载用户访问流量；

6）监控集群：负责收集各个集群上报的日志情况，并作为稳定性管理手段之一。

可以看到：机房B相比其他机房，少了接入层配置，这主是基于成本和性能上考虑，把机房B当做数据传输枢纽，不仅能保证本机房数据传输，也能支持跨机房的数据同步&复制。该分布式传输系统从数据接入到监控集群，整体机器规模不大（100左右），但可支撑超过10亿的流量。

9、本文小结

一个良好的产品体验及产品矩阵，其背后一定离不开一个高可用、高时效的数据支撑，尤其是在金融领域，用户只可能会为一手的信息、完善的产品功能买单。

自21年完成数据通路建设以来，金融的稳定性和业务规模都有了质的飞跃，证券数据时效性问题从季度数十个降低到年度1个以内，99分位耗时更是从过去的分钟级降低到60ms以内，数据SLA从2个9左右提升至5个9以上，产品覆盖股票、外汇、基金、期货等诸多领域，也是第一个在搜索领域支持行情长连接的业务，基于搜索生态也孵化出来了像百度股市通PC站、app等多个独立端产品，目前正在结合AI能力进行持续优化，期望从完善用户体验->帮助用户决策进阶，也让金融投资变得更智能，更简单。

本文主要结合一个金融数据接入案例对分布式数据传输系统做了一个简单的介绍，包括传输系统中的一些核心节点的设计，如数据接入层的多协议适配、数据的分层管理以及跨地域的数据同步对应的网络拓扑等，通过实验得出结论，该方案能很好的应用在各种规模的分布式数据传输系统设计中。当然，由于篇幅问题，也省略了很多实现上的细节，读者有任何问题可以留言，可以一起探讨，也会尽量答复。

10、相关文章

[1] 技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解

[2] 以网游服务端的网络接入层设计为例，理解实时通信的技术挑战

[3] 知乎千万级并发的高性能长连接网关技术实践

[4] 手淘亿级移动端接入层网关的技术演进之路

[5] 喜马拉雅自研亿级API网关技术实践

[6] 石墨文档单机50万WebSocket长连接架构实践

[7] 小米小爱单机120万长连接接入层的架构演进

[8] B站基于微服务的API网关从0到1的演进之路

[9] 百度统一socket长连接组件从0到1的技术实践

[10] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

11、其它百度技术分享

《百度APP移动端网络深度优化实践分享(一)：DNS优化篇》

《百度APP移动端网络深度优化实践分享(二)：网络连接优化篇》

《百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇》

《全面了解移动端DNS域名劫持等杂症：原理、根源、HttpDNS解决方案等》

《深入了解百度开源的分布式RPC框架brpc的方方面面》

《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》

《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》

《百度统一socket长连接组件从0到1的技术实践》

《百度网盘千万节点的P2P架构设计(PPT) [附件下载]》

《即时通讯音视频开发（二十）：一文读懂视频的颜色模型转换和色域转换》

《揭秘百度IM消息中台的全量用户消息推送技术改造实践》

《百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践》

（本文已同步发布于：http://www.52im.net/thread-4602-1-1.html）

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第32 期。

[- 1 -] IM开发干货分享：如何优雅的实现大量离线消息的可靠投递

[链接] http://www.52im.net/thread-3069-1-1.html

[摘要] 本文作者将以自已IM开发过程中的真实总结，分享针对大量离线聊天消息，在确保用户端体验不降级的前提下，保证离线消息的可靠投递。

[- 2 -] IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践

[链接] http://www.52im.net/thread-3088-1-1.html

[摘要] 本文主要以Android客户端为例，记录了有赞旗下 App 中使用自研 IM，并将IM提炼成组件化SDK的设计思路。

[- 3 -] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[链接] http://www.52im.net/thread-3445-1-1.html

[摘要] 本文主要聚焦这套亿级用户的IM架构的一些比较细节但很重要的热门问题上，比如：消息可靠性、消息有序性、数据安全性、移动端弱网问题等。

[- 4 -] IM扫码登录技术专题(一)：微信的扫码登录功能技术原理调试分析

[链接] http://www.52im.net/thread-2941-1-1.html

[摘要] 本文将以轻松活泼的语言形式，为你分析和讲解微信手机扫码登录的技术原理，希望在你的IM中开发此功能时有所启发。

[- 5 -] IM扫码登录技术专题(二)：市面主流的扫码登录技术原理调试分析

[链接] http://www.52im.net/thread-2892-1-1.html

[摘要] 本文将简要的介绍扫码登录功能的技术实现逻辑，并实际结合淘宝、微信的扫码登录功能，学习和研究大厂主流应用的技术实现思路。

[- 6 -] IM扫码登录技术专题(三)：通俗易懂，IM扫码登录功能详细原理一篇就够

[链接] http://www.52im.net/thread-3525-1-1.html

[摘要] 最近刚好看到一个二维码的技术原理讲解视频，正好借此机会将扫码登录的详细技术原理梳理并总结一下，方便自已回顾，也希望能帮助到想在IM里开发类似功能的同行们。

[- 7 -] IM扫码登录技术专题(四)：你真的了解二维码吗？刨根问底、一文掌握！

[链接] http://www.52im.net/thread-3735-1-1.html

[摘要] 二维码技术使用起来很简单，本系列的前三篇文章也专门针对IM扫码登录这个功能做了详细的分享，但本着学习技术不留死角的习惯，我认为有必要单独学习一下到底什么是二维码。

[- 8 -] 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨

[链接] http://www.52im.net/thread-3574-1-1.html

[摘要] 本文内容仅供参考，具体的解决方案请务结合自已的系统构架和实现情况，多阅读几篇即时通讯网上有关这个技术话题的文章，取其精华，找到适合自已的技术方案和思路才是最明智的。

[- 9 -]  阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践

[链接] http://www.52im.net/thread-3615-1-1.html

[摘要] 本文总结了阿里闲鱼技术团队使用Flutter在对闲鱼IM进行移动端跨端改造过程中的技术实践等，文中对比了传统Native与现在大热的Flutter跨端方案在一些主要技术实现上的差异，以及针对Flutter技术特点的具体技术实现，值得同样准备使用Flutter开发IM的技术同行们借鉴和参考。

[- 10 -] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[链接] http://www.52im.net/thread-3638-1-1.html

[摘要] 本文根据融云亿级IM消息系统的技术实践，总结了分布式IM消息的可靠投递机制，希望能为你的IM开发和知识学习起到抛砖引玉的作用。

[- 11 -] IM全文检索技术专题(三)：网易云信Web端IM的聊天消息全文检索技术实践

[链接] http://www.52im.net/thread-3651-1-1.html

[摘要] 本文将具体来聊聊网易云信是如何实现IM客户端全文检索能力的，希望能带给你启发。

[- 12 -]  IM开发干货分享：万字长文，详解IM“消息“列表卡顿优化实践

[链接] http://www.52im.net/thread-3732-1-1.html

[摘要] 本文将要分享是融云IM技术团队基于对自有产品“消息”列表卡顿问题的分析和实践（本文以Andriod端为例），为你展示一款IM在解决类似问题时的分析思路和解决方案，希望能带给你启发。

👉52im社区本周新文：《百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由21CTO万能的大雄分享，本文有修订和改动。

1、引言

在当今快速发展的技术环境中，对跨平台桌面应用程序的需求正在不断激增。

开发人员面临着选择正确框架之挑战，以便可以高效构建可在 Windows、macOS 和 Linux 上无缝运行的应用程序。

在本文中，我们将比较五种流行的桌面应用程序开发框架：Electron、Flutter、Tauri、React Native 和 Qt，希望可以帮助你根据项目需求做出明智的技术选型决策。

2、系列文章

本文是系列文章中的第10篇，本系列总目录如下：

《IM跨平台技术学习(一)：快速了解新一代跨平台桌面技术——Electron》

《IM跨平台技术学习(二)：Electron初体验(快速开始、跨进程通信、打包、踩坑等)》

《IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实践总结》

《IM跨平台技术学习(四)：蘑菇街基于Electron开发IM客户端的技术实践》

《IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK改造实践总结》

《IM跨平台技术学习(六)：网易云信基于Electron的IM消息全文检索技术实践》

《IM跨平台技术学习(七)：得物基于Electron开发客服IM桌面端的技术实践》

《IM跨平台技术学习(八)：新QQ桌面版为何选择Electron作为跨端框架》

《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存占用优化》

《IM跨平台技术学习(十)：快速选型跨平台框架Electron、Flutter、Tauri、React Native等》（* 本文）

3、初识框架

1）Electron：

* 技术背景：Electron 由 GitHub 开发，因其使用 HTML、CSS 和 JavaScript 等 Web 技术构建跨平台桌面应用程序的能力而广受欢迎。

* 主要功能：Electron 通过其 Node.js 集成提供对本机 API 的轻松访问，使开发人员能够创建功能丰富的应用程序。它还支持用 C++ 编写的本机插件，尽管构建这些插件可能更复杂且容易出错。

2）Flutter：

* 技术背景：Flutter 由 Google 创建，以其在移动应用程序开发中的使用而闻名，但也可用于桌面应用程序。

* 主要特点：Flutter 提供了一组丰富的可定制 UI 小部件，其 Dart 代码被编译为本机机器代码，从而实现快速执行并减少开销。它采用独特的“基于小部件”架构，提供丰富的可定制 UI 小部件。

3）Tauri：

* 技术背景：Tauri 是一个较新的框架，旨在创建安全且轻量级的桌面应用程序。它旨在弥合 Rust 和 Web 技术之间的差距。

* 主要功能：Tauri 支持使用 Rust 或 C 构建本机插件，从而可以访问 Web 平台中不可用的本机 API 和功能。

4）React Native：

* 技术背景：React Native，同样来自 Facebook，主要以移动应用程序开发而闻名，但也有桌面应用程序开发的扩展。

* 主要功能：React Native 提供了一种访问本机 API 和功能的方法，但与其他框架相比，它可能需要更多的努力。它支持无缝集成第三方库。

5）Qt：

* 技术背景：Qt 是一个 C++ 框架，绑定了多种语言，包括 Python 和 JavaScript。这是一个历史悠久、历史悠久的框架。

* 主要功能：Qt 提供出色的本机集成功能，允许开发人员访问本机 API 和功能。它提供了一套用于构建跨平台桌面应用程序的全面工具，并强调本机外观和感觉。

4、跨平台能力

在跨平台功能方面，Electron、Flutter、Tauri 和 Qt 足以在多个操作系统上运行应用程序。它们为 Windows、macOS 和 Linux 提供广泛的支持，使其成为需要广泛兼容性的项目的合适选择。

React Native 虽然主要是为移动设备设计的，但可以扩展以创建桌面应用程序。然而，它的跨平台支持可能不像其他框架那样无缝，并且可能需要额外的努力才能在所有平台上实现一致的性能和 UI。

5、性能表现

性能是桌面应用程序开发的关键因素。

以下是这些框架的性能特征：

• 1）Electron：以其较高的资源使用率而闻名，Electron 应用程序可能会占用更多内存和 CPU，从而影响较旧或功能较弱的计算机的性能；
• 2）Flutter：Flutter 的性能值得称赞，这要归功于它的编译代码和 GPU 加速。它提供快速的启动时间和流畅的动画；
• 3）Tauri：Tauri 因其轻量级特性和低资源消耗而脱颖而出。它是构建快速且响应灵敏的桌面应用程序的绝佳选择；
• 4）React Native：React Native 桌面应用程序可以节省资源，但跨平台优化性能可能需要额外的工作；
• 5）Qt：Qt 的性能非常出色，提供类似本机的速度和响应能力。它是资源密集型应用程序的首选。

6、用户界面

创建丰富且响应迅速的用户界面是桌面应用程序开发的一个重要指标。

以下是这些框架在 UI 功能方面的比较：

• 1）Electron：Electron 提供了大量预构建的 UI 组件和广泛的主题选项。开发人员可以轻松创建具有视觉吸引力的应用程序；
• 2）Flutter：Flutter 基于小部件的方法允许高度可定制且具有视觉吸引力的用户界面。它提供了广泛的开箱即用的小部件；
• 3）Tauri：Tauri 不像其他框架那样提供那么多的 UI 组件，但允许对用户界面进行严格控制，这有利于创建独特的设计；
• 4）React Native：通过React Native，开发人员可以使用第三方库和组件进行UI设计。可能需要额外的工作才能实现完全定制的外观；
• 5）Qt：Qt 擅长提供与目标平台无缝集成的类似本机的 UI 元素。它是需要精美原生外观的应用程序的首选。

7、开发经验

流畅的开发工作流程对于生产力至关重要。

以下是这些框架在开发经验方面的比较：

• 1）Electron：Electron 提供了一套广泛的开发工具和一个活跃的社区。调试和热重载得到良好支持；
• 2）Flutter：由于其基于 widget 的架构和强大的文档，Flutter 的开发体验得到了简化。热重载是一个突出的功能；
• 3）Tauri：Tauri 仍然相对较新，但使用 Rust 和 JavaScript 提供了简化的开发过程。它强调快速发展；
• 4）React Native：React Native 为 Web 和移动开发人员提供了熟悉的开发体验。然而，过渡到桌面可能需要一个学习曲线；
• 5）Qt：Qt 提供了一个成熟的开发环境，具有广泛的 IDE 和工具。它以其稳定性和全面的文档而闻名。

8、原生集成

访问本机平台功能和 API 对于许多桌面应用程序至关重要。

让我们看看这些框架如何处理本机集成：

• 1）Electron：Electron 通过 Node.js 集成提供对本机 API 的轻松访问。它还支持用 C++ 编写的本机插件，尽管构建这些插件可能更复杂且容易出错；
• 2）Flutter：Flutter 的 Dart 代码被编译为本机机器代码，从而实现快速执行并减少开销。它采用了一种称为“基于小部件”架构的独特方法，提供了一组丰富的可定制 UI 小部件；
• 3）Tauri：Tauri 支持使用 Rust 或 C 构建原生插件，可用于访问 Web 平台中不可用的原生 API 和功能；
• 4）React Native：React Native 提供了一种访问本机 API 和功能的方法，但与其他框架相比可能需要更多的努力。它支持无缝集成第三方库；
• 5）Qt：Qt 提供出色的本机集成功能。它是一个 C++ 框架，绑定了多种语言，包括 Python 和 JavaScript，可用于访问本机 API 和功能。

9、社区与生态系统

开发人员社区的规模和活跃度，可以显着影响框架的成功和第三方库的可用性。

这些框架的表现如下：

• 1）Electron：Electron 拥有一个庞大而活跃的社区，提供大量可用的插件和扩展；
• 2）Flutter：Flutter 拥有不断增长的社区和越来越多的软件包，主要专注于移动开发，但也有桌面扩展；
• 3）Tauri：Tauri 仍在成长，但其社区充满热情并致力于其发展。其生态系统正在稳步扩展；
• 4）React Native：React Native 拥有完善的社区，主要专注于移动开发。桌面扩展社区规模较小，但正在不断增长；
• 5）Qt：Qt 拥有悠久的历史和强大的生态系统，拥有庞大的工具、小部件和扩展库。

10、 框架们的成功案例

让我们探索一些现实世界的用例和使用这些框架构建的应用程序示例，以更好地了解它们在不同场景中的优点和缺点。

以下是具体的场景举例：

• 1）Electron：广泛用于构建跨平台桌面应用程序，包括代码编辑器（VSCode）、通信工具（Slack）和娱乐应用程序（Spotify）；
• 2）Flutter：Flutter 逐渐成为富媒体应用程序的选择，已用于 Google Ads、阿里巴巴和 Reflectly 等应用程序；
• 3）Tauri：Tauri 正在获得轻量级、安全应用程序的青睐，包括密码管理器 (LosePass) 和通信工具 (Mailspring)；
• 4）React Native：虽然主要是一个移动框架，但 React Native 已扩展到 Discord 和 Microsoft Teams 等应用程序中的桌面使用；
• 5）Qt：Qt 是一种多功能选择，可用于从工业软件到游戏和汽车信息娱乐系统的广泛应用。

11、开发时的挑战

虽然每个框架都有其优点，但必须意识到潜在的挑战和限制。

比如这些：

• 1）Electron：Electron 应用程序可能会占用大量资源，可能会导致旧硬件上出现性能问题；
• 2）Flutter：如果您主要是移动开发人员，那么使用 Flutter 进行桌面开发可能会涉及一个学习曲线；
• 3）Tauri：作为一个相对较新的框架，与更成熟的选项相比，Tauri 可能拥有较小的社区和较少的第三方库；
• 4）React Native：将 React Native 转换到桌面可能需要额外的努力，并且某些特定于平台的功能可能更难访问；
• 5）Qt：Qt 的学习曲线，特别是对于刚接触 C++ 的开发人员来说，可能是一个挑战。

12、本文小结

为桌面应用程序开发选择正确的框架很大程度上取决于项目的具体要求，例如目标平台、性能预期、UI 需求和所需的开发体验。

如果正在寻找一个允许你利用 Web 技术的框架，Electron和React Native是不错的选择。Electron 拥有庞大的社区和广泛的预构建组件，而 React Native 提供强大的组件系统，并允许在移动和桌面平台之间重用代码。

如果性能和小包大小是优先考虑的，请考虑Flutter或Tauri。Flutter 提供快速的启动时间和流畅的动画，而 Tauri 则以其轻量级和低资源消耗而闻名。

如果你需要一个具有出色本机集成和本机外观的框架，Qt是一个可靠的选择。

如果你正在开发需要丰富的、可定制的用户界面的复杂应用程序，Flutter可能是最佳选择，因为它基于 widget 的开发方法。

还请各位开发者要记住，请考虑与每个框架相关的学习曲线，特别是如果你或团队尚不熟悉所涉及的技术。比如，Tauri 需要 Rust 或 C 的前置知识，而 Flutter 使用 Dart 做为预备知识。

13、相关资料

[1] Electron官方开发者手册

[2] Flutter官方手册

[3] Tauri官方手册

[4] React Native开发指南

[5] QT官方文档和手册

[6] 快速了解新一代跨平台桌面技术——Electron

[7] Electron初体验(快速开始、跨进程通信、打包、踩坑等)

[8] vivo的Electron技术栈选型、全方位实践总结

[9] 融云基于Electron的IM跨平台SDK改造实践总结

[10] 闲鱼IM基于Flutter的移动端跨端改造实践

[11] 网易云信基于Electron的IM消息全文检索技术实践

（本文已同步发布于：http://www.52im.net/thread-4598-1-1.html）

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第31 期。

​[- 1 -] IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）

[链接] http://www.52im.net/thread-1998-1-1.html

[摘要] 如何优雅地解决“消息序列号只要保证顺序性而不需要兼顾唯一性”的问题呢？这就是本文所要分享的内容，强烈建议深入理解和阅读。

[- 2 -] IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）

[链接] http://www.52im.net/thread-1999-1-1.html

[摘要] 本篇将会介绍 seqsvr 分布式容灾架构的演变。

[- 3 -] IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略

[链接] http://www.52im.net/thread-2747-1-1.html

[摘要] 本文要分享的是融云即时通讯云产品中的聊天消息ID生成算法和策略，一个19字节的ID就能包含：时间戳、消息类型、会话ID、序列号，小ID、大用途，值得借鉴！

[- 4 -]IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法

[链接] http://www.52im.net/thread-2751-1-1.html

[摘要] 对于美团的Leaf-segment这个ID生成方案，因为生成的ID全局唯一、全局有序，所以非常适合IM这种应用场景，这也是即时通讯网整理并分享给社区的原因。

[- 5 -] IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现

[链接] http://www.52im.net/thread-2953-1-1.html

[摘要] 本文是专题系列文章的第5篇，专门介绍百度开源的分布式消息ID生成器UidGenerator的算法逻辑、实现思路、重点源码解读等，或许能带给你更多的启发。

[- 6 -] IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)

[链接] http://www.52im.net/thread-3129-1-1.html

[摘要] 本文将要分享的是滴滴开源的分布式ID生成器Tinyid的技术原理、使用方法等等，希望能进一步为你打开这方面的技术视野。

[- 7 -] IM消息ID技术专题(七)：深度解密vivo的自研分布式ID服务(鲁班)

[链接] http://www.52im.net/thread-4378-1-1.html

[摘要] 本文通过对分布式ID的3种应用场景、实现难点以及9种分布式ID的实现方式进行介绍，并对结合vivo业务场景特性下自研的鲁班分布式ID服务从系统架构、ID生成规则与部分实现源码进行分享，希望为本文的阅读者在分布式ID的方案选型或技术自研提供参考。

[- 8 -] IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总

[链接] http://www.52im.net/thread-3008-1-1.html

[摘要] 本文将根据微信官方目前已公开的资料，将它的一些常用功能参数和逻辑规则资料进行了汇总整理，希望能助力你的IM开发！

[- 9 -]  IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的

[链接] http://www.52im.net/thread-3036-1-1.html

[摘要] 今天这篇不是原理性文章，而是为大家分享一下由笔者主导开发实施的IM即时通讯聊天系统，针对大量离线消息（包括消息漫游）导致的用户体验问题的升级改造全过程。

[- 10 -] 零基础IM开发入门(一)：什么是IM系统？

[链接] http://www.52im.net/thread-3065-1-1.html

[摘要] 本系列文章将尽量从理论概念入手，通俗易懂的梳理IM中的基础技术概念和热门技术点，希望能帮你理清看似一团乱麻的IM知识体系，助你找到清晰的IM技术学习方向。

[- 11 -] 零基础IM开发入门(二)：什么是IM系统的实时性？

[链接] http://www.52im.net/thread-3143-1-1.html

[摘要] 对于技术门外汉来说，到底什么是IM的“实时性”？该如何理解它？这就是本文想要讨论的主题。

[- 12 -] 零基础IM开发入门(三)：什么是IM系统的可靠性？

[链接] http://www.52im.net/thread-3182-1-1.html

[摘要] 本篇主要讲解IM系统中的“可靠性”这个话题，内容尽量做到只讲原理不深入展开，避开深层次的技术性探讨，确保通俗易懂。

[- 13 -] 零基础IM开发入门(四)：什么是IM系统的消息时序一致性？

[链接] http://www.52im.net/thread-3189-1-1.html

[摘要] 本文尽量以通俗简显的文字为你讲解IM消息时序一致性问题的产品意义、发生原因、解决思路等。

👉52im社区本周新文：《IM跨平台技术学习(十)：快速对比跨平台框架Electron、Flutter、Tauri、React Native等》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由字节跳动技术团队李晨光、匡建鑫、陈鉴平分享，本文有修订和改动。

1、引言

新媒体互动直播已成为了广大网民最重要的休闲娱乐方式之一。丰富的传统文化、新闻、竞技体育、法律、知识共享等内容，通过移动端互动直播的形式得以更加高效的展现传播，既让优质的直播内容可以实现爆发式传播扩散，又可以让用户有更多的机会感受，学习甚至主动参与直播互动。超低延时视频直播技术正在走上一条全新的发展之路。

本文将带您了解超低延时视频直播技术的优化和演进历程。

2、系列文章

本文是系列文章中的第 11 篇，本系列总目录如下：

• 《视频直播技术干货(一)：揭秘百万级粉丝互动的Facebook实时视频直播》
• 《视频直播技术干货(二)：P2P技术如何将实时视频直播带宽降低75%？》
• 《视频直播技术干货(三)：实时直播答题系统的实现思路与技术难点分享》
• 《视频直播技术干货(四)：首次披露快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
• 《视频直播技术干货(五)：七牛云使用QUIC协议实现实时视频直播0卡顿》
• 《视频直播技术干货(六)：新浪微博实时直播答题的百万高并发架构实践》
• 《视频直播技术干货(七)：实时视频直播首屏耗时400ms内的优化实践》
• 《视频直播技术干货(八)：淘宝高清、低延时的实时视频直播技术解密》
• 《视频直播技术干货(九)：千万级直播系统后端架构设计的方方面面》
• 《视频直播技术干货(十)：一文读懂主流视频直播系统的推拉流架构、传输协议等》
• 《视频直播技术干货(十一)：超低延时视频直播技术的演进之路》（* 本文）

3、低延时直播技术的作用

网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素，驱动音视频服务时延逐渐降低， 使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展， 并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期，我国实时音视频行业的场景效能逐渐深化，步入到理性增长阶段。

延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度，场景丰富多样。

在这些极端场景下，延时在用户侧希望越小越好，接近于实时通信的低延迟模式可以最大化地激发用户的参与感，无缝地与内容生产方产生互动效应，调动用户所见即所得的积极性。比如在主播秀场的PK、送礼、工会冲榜、打赏的活动关键环节，竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应，为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。

下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用；从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。

4、传统直播技术中RTMP协议的延迟问题

RTMP 协议是最传统的直播协议，主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发，端到端延迟一般控制在 3 到 7 秒。

问题是 RTMP 的可扩展性存在缺陷，同时对于延迟的进一步下探存在一定的技术困难。

RTMP 协议情况下：为了满足延时降低必然压缩播放器的下载缓冲区，这样会引发显著的卡顿问题，使得播放的观感产生不舒适的感受（延时下探至 2 秒以下）。

5、传统直播技术在实时互动场景中的不足

1）视频延时和弹幕交互的延时存在显著差异，问题聊天内容互动与视频传输图像节奏不匹配：

2）观众与主播互动形式单一，是单向内容传导无法做到双向（在 RTC 技术引入之前无法显著解决）。

3）单向传导的局限第一个方面表现在：观众端拉流传输无法做到根据网络情况自适应调节。用户只能以固定的码率进行流媒体传输无法做到动态感知，在网络情况实时变化的场景（比如弱网，移动基站切换等）固定单向码率传输有较大概率造成丢帧卡顿等因素影响观播体验。另一方面在网络条件更好时，固定码率传输无法动态提升视频传输码率（更高的画质带来更加舒适的体验）

4）在直播和连麦场景共存的互动直播场景下，主播采用传统RTMP推流在遇到连麦PK场景时，会产生推流/本地连麦合流/服务器连麦合流的切换问题，这种场景变换的切换会使得观众端产生瞬间的卡顿问题。如果采用基于webRTC直播技术的超低延时直播方案，这种推流--连麦逻辑的合流切换问题可以得到比较友好的解决（只需要改变服务器转发-订阅流通道的分发逻辑，不涉及推流媒体数据流的旁路调度切换）。

6、 超低延时直播与标准直播的区别

6.1超低延时直播

超低延时直播是近年来新兴起的一类应用。

如电商直播、赛事直播等场景，兼具高并发与低延时的特性，传统直播 3-20s 的时延难以满足其需求，但对实时互动的要求又不及视频会议等典型的实时音视频应用，无需将时延降低至 400ms 以下。

为此，超低延时直播融合了传统直播与实时音视频的技术架构，通过取长补短的方式实现了介于二者之间的端到端时延。

尽管针对超低延时直播厂商尚无一套标准的技术路径，但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造， 在实际应用过程中，厂商会平衡成本及性能指标等因素，在不同的协议和网络架构之间进行选择。

6.2传输层协议的差异

基于 UDP 协议的可靠性优化，为弱网对抗策略提供依据。

传统直播 FLV/RTMP 等采用的是 TCP 协议（或者 QUIC 协议）TCP 是牺牲传输实时性来换取数据完整性的可靠传输协议。

弱网环境下，其在数据传输前的“三次 握手”连接会带来较大延时。

而 UDP 作为不可靠的传输协议，其最大的优点为高实时性，但不保证数据的到达和排序。

实时音视频 产品（如 RTM 超低延时直播）往往采用 UDP 协议，并在此之上进行协议层与算法层的优化，来提高传输的可靠性与逻辑性。

相关文章可阅读：

1. 《网络编程懒人入门(五)：快速理解为什么说UDP有时比TCP更有优势》
2. 《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》
3. 《不为人知的网络编程(六)：深入地理解UDP协议并用好它》
4. 《不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》

6.3UDP 协议的优化

UDP 协议往往和 RTP/RTCP 协议一起在实际应用中出现。

RTP 负责数据传输，其协议头中的序列号、 端口类型、时间戳等字段，可为数据包的分组、组装、排序提供逻辑依据。

RTCP 作为 RTP 的控制协议，负责对 RTP 的传输质量进行统计反馈，并为弱网对抗策略提供控制参数。

7、RTM 协议本身的演进历程

a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"

a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"

a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range

a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type

a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp

a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config

RTP 使用 RTP 私有扩展头携带 DTS/CTS 值，每一帧 RTP 数据包通过 RFC5285-Header-Extension 扩展头携带该帧的 DTS 值，每一帧首个 RTP 包和 VPS/SPS/PPS 包通过 RFC5285-Header-Extension 扩展头携带该帧的 CTS 值，通过 PTS = DTS + CTS 计算当前帧的时间戳。用于启播快速音画同步和播放器播控逻辑精准音画同步。

扩展头携带帧的起始/结束序号：如果首帧的前几个包丢失，那么可根据起始序号快速发起重传加快首帧；如果当前帧的后几个包丢失，那么可根据该帧的结束序号快速发起重传，降低延时，减少卡顿。

扩展头携带帧的类型：如果携带并解析了正确的帧类型，客户端可以不用解析 metadata ；同时在弱网情形，客户端可以跳过 B 帧直接解码 P 帧，加速出帧并减少潜在卡顿。

扩展头携带 P 帧的参考帧信息：如果发生弱网情形，那么客户端可以依照扩展头指定的参考帧关系及其对应时间戳，跳过 B 帧解码 ，减少卡顿发生。

为了加速信令交互的速度，CDN 可以在某些条件下不去查询媒体信息，直接向客户端返回支持的音视频能力；此时 SDP 的媒体描述中将不包含有具体的音视频配置详细信息。在音频层面，此时AnswerSDP 中不包含 aac 解码所需的头信息；此时我们需要采取 RTP 扩展头模式携带 AAC-Config 供客户端在 RTP 收包时刻自行解析处理完成解码动作，作用是减少信令交互时间，提升拉流成功率。

miniSDP 信令标准实现部分（抖音)。

CDN 信令异步回源。

RTP 携带扩展头组成部分。

8、WebRTC 协议在直播播放器的移植

RTM 低延时直播基于 WebRTC 技术衍生，基于 WebRTC 标准构建点到点传输一般有如下几个步骤：

• 1）通信双方要进行媒体协商，会话详细规范即 SDP(Session Description Protocol) 交互；
• 2）随后进行交互式网络地址协商（查询对端真实 IP 地址）准备构建媒体传输通道；
• 3）当上述条件准备完毕即进入最终的 Peer to Peer 点对点媒体数据传输。

信令部分客户端-服务器单独开发，利用了 SDP 标准报文模式。媒体传输部分采用开源的 WebRTC 框架和字节自研的实时音视频媒体引擎进行媒体传输。

9、RTC 信令协议的改造升级

MiniSDP压缩协议：https://github.com/zhzane/mini_sdp。

标准 SDP 比较冗长（5-10KB 左右），不利于快速高效传输。在直播场景下，会尤其影响首帧时间。

MiniSDP 对标准 SDP 文本协议进行高效能压缩，将原生 SDP 转换成更小的二进制格式，使其能够通过一个 UDP 包来传输。

降低信令交互时间，提高网络传输效能，降低直播拉流首帧渲染时间，提高拉流秒开率/成功率等 QoS 统计指标。

10、CDN对RTM 信令的异步回源优化

降低 RTM 信令交互时间，降低 RTM 拉流首帧渲染时间。

原来的流程在服务端缓存不命中时需要等待回源拿到数据，才能返回带有 AacConfig 信息的 AnswerSDP。客户端收到 AnswerSDP 后发送 STUN，而服务端只能在收到 STUN 才能开始下发数据。

如下图左：当异步回源情况下，服务端不再等待回源结果直接返回 AnswerSDP，之后回源和WebRTC 建连流程同步进行。

如上图右：等到 WebRTC 建连成功且回源拿到数据立即下发 RTP 数据。

11、视频渲染卡顿的优化（百秒卡顿平均降低4秒）

改善人均看播时长，改变 RTC 引擎的组帧/解码策略；禁止 RTC 在低延时模式下的丢帧，改善直播的视频渲染卡顿。

传统的 RTC 场景优先保时延，全链路会触发各种丢帧（包括但不限于解码模块，网络模块），FLV 直播场景会优先保证观播体验（不丢帧，良好的音画同步效果）。

RTM 要想减少卡顿，取得 qoe 的收益，播控策略需进行定制化，定制逻辑修改点：

1）确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ，内核层有一层强制的音画同步逻辑，可以确保音视频的播放体验；

2）同时上层在监控网络模块和解码模块的缓存长度，有相应的兜底逻辑：

• a. 判断硬解确实解不过来，dec_cache_frames 过多，上报错误，会降级到软解；
• b. jitterbuffer 异常，缓存的 frame_list 过多，触发播放器异常逻辑，上报错误，重新拉流。

12、RTM播控逻辑的优化

改善移动端看播渗透，RTC 统一内核方案天生存在缺陷（ MediaCodec 硬件解码器初始化耗时久）。将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播放内核，复用了 FLV 的视频解码模块（ MediaCodec 避免重新初始化）。显著的降低了安卓平台的首帧渲染时间，提升了拉流的成功率。

RTC 内核通用逻辑：

改进的 RTM 内核播控逻辑：

13、相关文章

[1] TCP/IP详解 - 第11章·UDP：用户数据报协议

[2] TCP/IP详解 - 第17章·TCP：传输控制协议

[3] 零基础入门：基于开源WebRTC，从0到1实现实时音视频聊天功能

[4] 实时音视频入门学习：开源工程WebRTC的技术原理和使用浅析

[5] 零基础快速入门WebRTC：基本概念、关键技术、与WebSocket的区别等

[6] 学习RFC3550：RTP/RTCP实时传输协议基础知识

[7] 基于RTMP数据传输协议的实时流媒体技术研究（论文全文）

[8] 技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解

[9] 让互联网更快：新一代QUIC协议在腾讯的技术实践分享

[10] 实时音视频面视必备：快速掌握11个视频技术相关的基础概念

[11] 实时音视频开发理论必备：如何省流量？视频高度压缩背后的预测技术

[12] 移动端实时音视频直播技术详解（一）：开篇

[13] 直播系统聊天技术(九)：千万级实时直播弹幕的技术实践

[14] 在线音视频直播室服务端架构最佳实践(视频+PPT) [附件下载]

[15] 视频直播技术干货：一文读懂主流视频直播系统的推拉流架构、传输协议等

（本文已同步发布于：http://www.52im.net/thread-4587-1-1.html）

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第30 期。

​[- 1 -] 全面掌握移动端主流图片格式的特点、性能、调优等

[链接] http://www.52im.net/thread-1802-1-1.html

[摘要] 本文我们一起全面分析学习目前主流和新兴的几种图片格式的特点、性能、调优等，以及相关开源库的选择，希望能为您的移动端应用（包括本社区主要讨论的即时通讯应用）中的图片优化带来一些启发。

[- 2 -] 最火移动端跨平台方案盘点：React Native、weex、Flutter

[链接] http://www.52im.net/thread-1870-1-1.html

[摘要] 本篇主要以react-native、weex、flutter，深入聊聊当前最火的这3种跨平台移动开发方案的实现原理、现状与未来。至于为什么只讲它们，因为对比ionic、phoneGap，它们更于 “naive” (˶ ⁻̫ ˵)。看完本篇，相信你会对于当下跨平台移动开发的现状、实现原理、框架的选择等有更深入的理解。

[- 3 -] 子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践

[链接] http://www.52im.net/thread-1961-1-1.html

[摘要] 本文内容来自对网易云信首席架构师周梁伟的采访，采访内容主要围绕网易云信这种海量用户IM云平台的关键技术难点以及对应的技术实践。

[- 4 -] IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列

[链接] http://www.52im.net/thread-1979-1-1.html

[摘要] 消息是互联网信息的一种表现形式，是人利用计算机进行信息传递的有效载体，比如即时通讯网坛友最熟悉的即时通讯消息就是其具体的表现形式之一。

[- 5 -] 微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）

[链接] http://www.52im.net/thread-1999-1-1.html

[摘要] 本篇将会介绍 seqsvr 分布式容灾架构的演变。

[- 6 -] 阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史

[链接] http://www.52im.net/thread-2050-1-1.html

[摘要] 阿里数据库事业部研究员张瑞，将为你讲述双11数据库技术不为人知的故事。

[- 7 -] 自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)

[链接] http://www.52im.net/thread-2671-1-1.html

[摘要] 本文不是一篇即时通讯理论文章，文章内容全部由实战代码组织而成。

[- 8 -] 融云技术分享：解密融云IM产品的聊天消息ID生成策略

[链接] http://www.52im.net/thread-2747-1-1.html

[摘要] 本文要分享的是融云即时通讯云产品中的聊天消息ID生成算法和策略，一个19字节的ID就能包含：时间戳、消息类型、会话ID、序列号，小ID、大用途，值得借鉴！

[- 9 -]  IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！

[链接] http://www.52im.net/thread-2759-1-1.html

[摘要] 本文将分析传统数据库（即SQL数据库）存在的一些问题，以及盘点目前市面上几大类 NoSQL 特性、优缺点等，希望给大家提供一些在不同业务场景下存储技术选型方面的参考。

[- 10 -] 适合新手：从零开发一个IM服务端（基于Netty，有完整源码）

[链接] http://www.52im.net/thread-2768-1-1.html

[摘要] 本文写的比较浅显但不太易懂，建议结合代码一起来读，文章配套的完整源码请从本文文末 “11、完整源码下载” 处下载！

[- 11 -] 拿起键盘就是干：跟我一起徒手开发一套分布式IM系统

[链接] http://www.52im.net/thread-2775-1-1.html

[摘要] 本文记录了我开发的一款面向IM学习者的 IM系统——CIM（全称：CROSS-IM），同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM。

[- 12 -] 适合新手：手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)

[链接] http://www.52im.net/thread-2988-1-1.html

[摘要] 本文适合有一定网络通信技术基础的IM新手阅读。如果你对网络编程，以及IM的一些理论知识知之甚少，请务必首先阅读：《新手入门一篇就够：从零开发移动端IM》，按需补充相关知识。

[- 13 -] IM里“附近的人”功能实现原理是什么？如何高效率地实现它？

[链接] http://www.52im.net/thread-2827-1-1.html

[摘要] 本文将简要的为你讲解“附近的人”的基本理论原理，并以Redis的GEO系列地理位置操作指令为例，理论联系实际地为你讲解它们是如何被高效实现的。

[- 14 -] IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路

[链接] http://www.52im.net/thread-2863-1-1.html

[摘要] 本文将分享几种典型的移动端账号登陆方式的技术原理，以及设计思路，理解后，完全可以快速实施于你的各种应用系统（并不限于IM系统）中。

[- 15 -] IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现

[链接] http://www.52im.net/thread-2887-1-1.html

[摘要] 本文将详细为你解密微信“扫一扫识物”功能背后的技术秘密。

[- 16 -] IM要做手机扫码登录？先看看微信的扫码登录功能技术原理

[链接] http://www.52im.net/thread-2941-1-1.html

[摘要] 本文将以轻松活泼的语言形式，为你分析和讲解微信手机扫码登录的技术原理，希望在你的IM中开发此功能时有所启发。

👉52im社区本周新文：《视频直播技术干货(十一)：超低延时视频直播技术的演进之路》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第29 期。

[- 1 -] 谈谈移动端 IM 开发中登录请求的优化

[链接] http://www.52im.net/thread-282-1-1.html

[摘要] 到底是“登陆”还是“登录”？这是很多处女坐开发者纠结的问题，不过它不是本文本讨伦的内容。本文将针对移动端IM的登陆功能给出相应的优化建议。

[- 2 -] 移动端IM登录时拉取数据如何作到省流量？

[链接] http://www.52im.net/thread-787-1-1.html

[摘要] 移动网络时代，手机的流量是个很昂贵的资源（至少暂时是这样）。一个典型的移动端IM在登录后，往往要向服务器同步非常多的数据，如果处理的不好是很费流量的，那么从技术上来讲，有没有节省流量的方法呢？这就是本文要讨论的话题。

[- 3 -] 浅谈移动端IM的多点登录和消息漫游原理

[链接] http://www.52im.net/thread-867-1-1.html

[摘要] 本文将展开聊聊移动端IM“多点登陆”与“消息漫游”的原理。

[- 4 -] 完全自已开发的IM该如何设计“失败重试”机制？

[链接] http://www.52im.net/thread-280-1-1.html

[摘要] 如何设计好这个失败重试的机制，使得客户端能做好失败重试，服务器有能够排除这种重复消息，但是排重处理不太复杂？

[- 5 -] 通俗易懂：基于集群的移动端IM接入层负载均衡方案分享

[链接] http://www.52im.net/thread-802-1-1.html

[摘要] 本文将以基于TCP数据传输协议的移动端IM为例，通过循序渐进地方式，分享如何构建一个基于分布式集群的移动端IM接入层的设计和实现。

[- 6 -] 微信对网络影响的技术试验及分析（论文全文）

[链接] http://www.52im.net/thread-195-1-1.html

[摘要] 本文来自论文《微信对网络影响的技术试验及分析》，文中研究了微信对现今移动网络的影响，对于即时通讯开发人员来说，文中的某些数据和研究结果，对于实现类似的技术，有一定的参考和借鉴意义。即时通讯网(52im.net)现全文收录之。

[- 7 -] 即时通讯系统的原理、技术和应用（技术论文）

[链接] http://www.52im.net/thread-218-1-1.html

[摘要] 首先，介绍即时通信的概念、特点和技术原理，较为全面地剖析了实现即时通信系统涉及的关键技术，包括即时通信传输协议、相关安全技术和音/视频编解码技术等；其次，简要概述了即时通信系统在我校的应用情况；最后，说明当前即时通信工具存在的问题及其发展趋势。

[- 8 -] 开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀

[链接] http://www.52im.net/thread-447-1-1.html

[摘要] 本文将简要介绍TeamTalk开源的过去和现在，为打算研究和采用TeamTalk的同行提供一定程度的参考。文中所涉及内容如有不妥，还请各位看官见谅。

[- 9 -]  QQ音乐团队分享：Android中的图片压缩技术详解（上篇）

[链接] http://www.52im.net/thread-1208-1-1.html

[摘要] 实际在生产环境下，群消息的发送都会想尽办法进行压缩，并开展各种改善性能的处理办法，而不是像上述举例里的直接扩散写（即2000人群里，一条消息被简单地复制为2000条一对一的消息投递）。具体有哪些优先策略？本文或许可以带给你一些启发。

[- 10 -] QQ音乐团队分享：Android中的图片压缩技术详解（下篇）

[链接] http://www.52im.net/thread-1212-1-1.html

[摘要] 关于压缩图片在诸如即时通讯应用场景下的好处，我们就不再赘述，不言自明。本篇将承接上篇《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》，继续讨论图片的尺寸压缩和常用的几种尺寸压缩算法。

[- 11 -] 腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率

[链接] http://www.52im.net/thread-675-1-1.html

[摘要] 本文内容是由腾讯TMQ专项测试团队针对手机QQ图片上传速度和成功率问题，在各种复杂移动网络环境下的优化实践总结和整理而成。文章虽是针对手机QQ图片上传这一特定业务功能，但内容中大量涉及复杂移动网络环境下无线网络的特性、特点以及相关第一手测试数据，都是非常珍贵的，尤其值得移动端IM开发、消息推送这种深度依赖移动网络的应用开发者借鉴和参考。

[- 12 -] 腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）

[链接] http://www.52im.net/thread-696-1-1.html

[摘要] 本文将给读者们一个一年多以前为公司的某产品成功优化网络流量的案例。速度、成功率与流量正好是 Apps 网络优化的几大重点，希望本文我们分享的思路能够给诸位正在开展或将来会开展此类工作的读者们一些启发。

[- 13 -] 腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（下篇）

[链接] http://www.52im.net/thread-697-1-1.html

[摘要] 本篇中将详细介绍我们的具体分析方法和实践优化思路，以及在优化过程中总结出来的法则等。

[- 14 -] 如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源

[链接] http://www.52im.net/thread-684-1-1.html

[摘要] 本文正文内容引用了微信开发团队的资料。

[- 15 -] 基于社交网络的Yelp是如何实现海量用户图片的无损压缩的？

[链接] http://www.52im.net/thread-1191-1-1.html

[摘要] 研究Yelp的极致图片压缩技术，或许能给即时通讯开发者同行带来一定的借鉴意义，而这也是此文的意义所在。

[- 16 -] 腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

[链接] http://www.52im.net/thread-1559-1-1.html

[摘要] 本次文章跟大家分享如何在保障质量（指的是图片质量、音视频质量）前提下所做的带宽和网络流量压缩，进而达到运营成本的优化。

[- 17 -] 腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

[链接] http://www.52im.net/thread-1560-1-1.html

[摘要] 本文接上篇《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》，继续腾讯公司分享如何在保障质量（指的是图片质量、音视频质量）前提下所做的带宽和网络流量压缩，进而达到运营成本的优化。

[- 18 -] 为什么说即时通讯社交APP创业就是一个坑？

[链接] http://www.52im.net/thread-1619-1-1.html

[摘要] 所以今天，我将尽量试着以用户的眼光，去描述这样一种现实：什么拳打QQ、脚踩微信，自嗨式的创业就像浮云一样......

👉52im社区本周新文：《IM通讯协议专题学习(十)：初识 Thrift 序列化协议》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由冰河分享，作者博客 binghe.gitcode.host，原题“这套分布式IM即时通讯系统如何写到简历上？我给你整理好了！”，本文有修订和改动。

1、引言

分布式IM即时通讯系统本质上就是对线上聊天和用户的管理。

针对聊天本身来说，最核心的需求就是：发送文字、图片、文件、语音、视频、消息缓存、消息存储、消息未读、已读、撤回，离线消息、历史消息、单聊、群聊，多端同步，以及其他一些需求。

对用户管理来说，存在的需求包含：添加好友、查看好友列表、删除好友、查看好友信息、创建群聊、加入群聊、查看群成员信息、退出群聊、修改群昵称、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注以及其他用户相关的需求等。

为了更好的理解分布式IM即时通讯系统的设计，我站在架构师的角度，在充分了解系统需求、业务流程和技术流程后，从全局视角为系统设定方案目标，对技术方案进行选型，对系统进行总体架构设计和分层架构设计，并梳理清楚发送消息的交互链路、单聊和群聊的交互链路。希望对你有帮助。

 

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4564-1-1.html）

2、方案目标

在进行技术选型与总体架构设计之前，需要明确一个事项，就是系统无论采用哪种方案，采用哪种架构设计都需要明确这种方案的业务目标、技术目标和架构目标，并在研发过程中不断评估系统的总体性能表现，发现系统瓶颈并不断进行优化。

总体上，我们搭建和开发的分布式IM即时通讯系统，需要满足如下方案目标。

具体是：

• 1）业务目标：满足需求设计篇章中的各类需求场景；
• 2）技术目标：支持无限扩容，百万用户同时在线聊天；
• 3）架构目标：高并发、高性能、高可用、可监控、可预警、可伸缩，支持无限扩展。

3、技术选型

在技术选型上，除了采用SpringBoot等基础框架外，也会采用容器化方案。

同时，考虑到为了尽量降低技术门槛，在整个分布式IM即时通讯系统的技术选型中，主要采用市面上比较流行的技术框架和方案。

具体选型如下所示：

• 1）开发框架：SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo；
• 2）缓存：Redis分布式缓存+Guava本地缓存；
• 3）数据库：MySQL、TiDB、HBase；
• 4）流量网关：OpenResty+Lua；
• 5）业务网关：SpringCloud Gateway + Sentinel；
• 6）持久层框架：MyBatis、Mybatis-Plus；
• 7）服务配置、服务注册与发现：Nacos；
• 8）消息中间件：RocketMQ；
• 9）网络通信：Netty；
• 10）文件存储：Minio；
• 11）日志可视化治理：ELK；
• 12）容器化管理：Swarm、Portainer；
• 13）监控：Prometheus、Grafana；
• 14）前端：Vue；
• 15）单元测试：Junit；
• 16）基准测试：JMH；
• 17）压力测试：JMeter。

4、初步架构设计

对于IM即时通讯系统来说，涵盖了即时通讯后端服务、大后端平台、SDK接入服务、OpenAI接入服务、大前端UI，我相信不少小伙伴多多少少能够画出IM即时通讯系统的架构图，大致如下图所示。

 

其实，这种这种架构设计也比较常见，在这种架构设计中，Kong/Openresty/Nginx只做负载均衡和反向代理，研发人员更多的是关注业务层和基础层的开发，流量比较小时，这种架构设计一般不会有什么问题。但是一旦流量比较大，用户调用后端平台的接口发送消息时，即时通讯SDK同步调用即时通讯服务的接口就会出现性能问题。

因为每个终端同时只能与一个IM即时通讯服务实例建立连接，如果大量的用户终端恰好都与一个IM即时通讯服务建立连接，那即时通讯SDK频繁同步调用同一个IM即时通讯服务的接口就会出现性能瓶颈。此时，出现性能瓶颈时，不仅仅会影响到IM即时通讯服务，也会对后端平台接收请求的业务造成一定的影响。

5、架构设计优化

既然上节图中所示的架构设计存在性能瓶颈，那我们如何进行优化呢？

为此我们在前图基础上进行了优化，优化后的架构如下图所示。

对比两图可以看出，在屏蔽掉技术实现细节的前提下，我们将对业务的校验和流量管控进行前置化，放大Kong/OpenResty/Nginx的职责，使得这些软件不仅具备反向代理和负载均衡的功能，还能实现限流、黑白名单、流量管控、业务校验等功能。

也就是说，在这种架构模式下，我们充分发挥了整个分布式IM即时通讯系统的入口职责，充分利用Kong/OpenResty/Nginx的高并发、高吞吐量的能力，尽量将大部分无效请求挡在整个系统之外。例如，用户在没登录系统的前提下，就尝试调用发送消息、添加好友、添加群组等等接口。这样会大大减轻后台平台的业务压力。

除了在Kong/OpenResty/Nginx中实现限流、黑白名单、流量管控、业务校验等功能外，我们还引入了业务网关集群，实现限流、降级、熔断、流控、校验、鉴权等功能，进一步保证下游系统的稳定性和安全。

为了解决大量用户终端恰好连接到同一个IM即时通讯服务实例，IM即时通讯SDK频繁调用同一个IM即时通讯服务实例的接口造成的性能问题。我们在IM即时通讯服务SDK与IM即时通讯服务之间引入了RocketMQ集群。

IM即时通讯服务集群中的每一个IM即时通讯服务实例在集群中都有一个唯一的ID，并且每个IM即时通讯服务实例在启动后，只会监听RocketMQ中与自身ID相关的Topic。这样每个IM即时通讯服务只会收到与自身ID相关的Topic中的消息，不会接收所有的消息。

当用户登录系统后，就会与IM即时通讯服务建立长连接，并且会以用户ID和终端为Key，以IM即时通讯服务的ID为value，将其存储到分布式缓存中。同时，会以用户ID和终端为Key，以用户终端与IM即时通讯服务建立的长连接为value，将其存储到IM即时通讯服务本地内存中。

当用户调用后端平台的接口发消息时，会带上目标用户的ID，并且在IM即时通讯SDK中会指定用户登录的终端设备，最终会通过IM即时通讯SDK向RocketMQ发送消息。

此时IM即时通讯SDK会根据目标用户ID和终端从分布式缓存中获取目标用户连接的IM即时通讯服务的ID，并向此ID相关的Topic发送消息。此时与目标用户建立长连接的IM即时通讯服务就会接收到RocketMQ中的消息，随后根据用户ID和终端从本地缓存中获取到与用户终端建立的长连接，并基于此长连接向用户推送消息。

另外，在实际实现中，为了避免大量用户同时只连接IM即时通讯服务集群中的某一个服务实例，会对用户连接的IP、浏览器指纹、手机设备等做Hash和取模运算，使其尽量均匀分布到集群中的每一个服务实例上。

那么问题来了，这种架构设计还有进一步优化的空间吗？

6、容器化架构设计

为进一步增强分布式IM即时通讯系统的性能、可用性和弹性伸缩能力，我们可以对分布式IM即时通讯系统进行容器化架构设计，如下图所示。

可以看到，我们对分布式IM即时通讯系统的架构设计进行了进一步优化，采用了容器化架构设计。在原有架构的基础上，我们进行了如下改进和优化。

1）基础支撑服务：基础支撑服务会由各种基础中间件、数据存储服务、以及监控服务实现，包含：MySQL数据库、TiDB数据库、HBase、Redis缓存、RocketMQ消息队列、Prometheus监控和Portainer容器管理等基础中间件实现，基础支撑服务会对整个分布式IM即时通讯系统提供最基础的数据、传输、监控和容器管理等服务。

2）容器化：在容器化层面，会通过Docker、Swarm和Portainer实现，其中，会基于Swarm和Portainer对容器化进行管理。

3）其他基础性功能实现：除了上述分层架构外，对于建设分布式IM即时通讯系统来说，还要考虑异常监控、服务注册与发现、可视化、服务降级与兜底数据、服务限流、服务容灾、容量规划与扩缩容和全链路压测等。

7、DDD分层业务架构设计

在分布式IM即时通讯系统中，不管是大后端平台，还是IM即时通讯服务，我们都会对业务层的代码采用分层业务架构。

这里，可以借鉴DDD的分层架构思想，将代码总体上分成展示层、应用层、领域层和基础设施层四个层次。

但是，考虑到分布式IM即时通讯系统的特殊性，又不会严格按照DDD的原则来设计代码分层，具体按照如下图所示。

可以看到，分布式IM即时通讯系统会借鉴DDD的设计思想，但是不会完全按照DDD的方式进行设计。

1）展示层：展示层，也叫做用户UI层，是DDD设计的最上层，对外提供API接口，接收客户端请求，解析参数，返回结果数据，并对异常进行处理。

2）应用层：应用层，也叫做Application层，应用层主要处理容易变化的业务场景，可对相关的事件、调度和其他聚合操作进行相关的处理。

3）领域层：领域层，也叫做Domain层，领域层可以说是DDD设计的精髓所在，它是将业务系统中相对不变的部分抽象出来封装成领域模型。在分布式IM即时通讯系统的设计中，领域层基本不会依赖其他层，也不会依赖基础设施层，这里是与DDD设计存在区别的地方。

4）基础设施层：基础设施层，也叫做Infrastructure层，基础设施层会对其他各层提供通用的基础能力，在分布式IM即时通讯系统中，就包括了缓存、通用工具类、消息、系统的持久化机制等。

8、总体IM消息交互链路

在分布式IM即时通讯系统中，我们忽略掉其他一些细节信息，重点关注下发送消息的交互链路逻辑。不管是单聊还是群聊，最终都需要通过IM即时通讯服务将消息推送给用户的终端。此时发送消息的流程如下图所示。

可以看到：用户在分布式IM即时通讯系统发送消息时，不管是单聊还是群聊，最终的消息都会推送到用户登录的终端设备上。假设此时用户A给用户B发送消息，或者用户A和用户B在同一个群组，用户A向群组发送消息，用户B接收消息的主要流程如下。

具体是：

• 1）用户A调用后端平台的接口向用户B发送消息，并且发送的消息中会带有用户B的ID以及终端信息；
• 2）后端平台将消息缓存起来，并且会将消息异步写入消息库；
• 3）后端平台从Redis中获取用户B连接的IM即时通讯服务的ID；
• 4）后端平台获取到用户B连接的IM即时通讯服务的ID后，会向RocketMQ中用户B连接的IM即时通讯服务ID对应的Topic发送消息；
• 5）IM即时通讯服务会监听自身服务ID对应的RocketMQ中Topic的消息，此时，用户B连接的IM即时通讯服务会接收到消息；
• 6）IM即时通讯服务接收到消息后，会根据用户B的ID以及终端信息从缓存中获取用户B与IM即时通讯服务建立的连接，并且通过这个连接向用户B推送消息。

要实现如上发送消息的流程，前提是要满足如下条件：

• 1）后端平台满足分布式条件，可随时横向扩展；
• 2）IM即时通讯服务满足分布式条件，可随时横向扩展；
• 3）每个启动的IM即时通讯服务实例在集群中都有一个唯一的ID；
• 4）每个IM即时通讯服务，都只监听自身ID对应的RocketMQ中Topic的消息；
• 5）用户登录分布式IM即时通讯系统后，会与IM即时通讯服务建立长连接，并且会根据用户ID和所在的终端缓存长连接，同时会根据用户ID和所在的终端将连接的IM即时通讯服务的ID缓存到Redis；
• 6）用户发送消息时，会根据目标用户的ID和终端从Redis中获取IM即时通讯服务的ID，进而向当前IM即时通讯服务的ID对应的RocketMQ的Topic发送消息；
• 7）对应的IM即时通讯服务监听并接收到RocketMQ消息后，会根据目标用户的ID和终端从缓存中获取到用户的连接信息，向目标用户推送消息。

9、IM单聊交互链路

单聊就是在分布式IM即时通讯系统中，一个用户直接与另外一个用户聊天，也就是一对一的聊天。在这种场景下，很有可能单聊的两个用户中，出现用户不在线的情况。

例如：用户A给用户B发送消息时，用户B可能不在线。

此时，我们就需要将用户A向用户B发送的消息存储起来。

其实，在我们实现的分布式IM即时通讯系统中，无论把用户B是否在线，都会存储消息记录。当用户B登录系统后，将消息同步给用户B，如下图所示。

可以看到，用户A向用户B发送消息时：

• 1）如果用户B在线，就可以按照发送消息的交互链路向用户B发送消息了；
• 2）如果用户B不在线，此时就无法向用户B正常推送消息。当用户B登录分布式IM即时通讯系统后，就会调用后端平台的接口拉取所有未读消息，并通过用户B在线流程向用户B推送消息。

10、IM群聊交互链路

群聊就是在分布式IM即时通讯系统中，多个用户在同一个群组中进行聊天。

此时在发送消息时，我们可以通过群组ID找出群内所有在线的用户，将消息即时发送给在线的用户。

那些未在线的用户就按照单聊未在线的用户进行处理，如下图所示。

可以看到，群聊的交互链路流程如下所示：

• 1）用户调用后端平台的接口向群组发送消息；
• 2）后端平台将消息缓存并异步写入消息库；
• 3）由于是向群组发送消息，群里有多个用户，此时就会从Redis中获取所有用户连接的IM即时通讯服务ID列表；
• 4）对用户按照服务ID分组，将相同服务ID下的用户分在同一个逻辑分组里，方便后续推送消息，并且会记录未在线的用户列表；
• 5）循环向每个服务ID对应的RocketMQ中的Topic发送消息；
• 6）广播处理未在线用户的未读消息ID；
• 7）IM即时通讯服务会监听自身服务ID对应的Topic，会随时接收推送到自身服务的消息；
• 8）当IM即时通讯服务接收到消息后，此时用户掉线，或者用户不在线，向用户推送消息就会失败，或者未查询到用户与IM即时通讯服务建立的连接，就不会向用户推送消息；
• 9）当用户登录分布式IM即时通讯系统后，会从后端平台拉取历史（离线）消息，并通过用户在线的流程，向用户推送消息；

好了，看到这里，你明白如何设计一个高度可扩展的分布式IM即时通讯系统了吗？

11、相关资料

[1] 浅谈IM系统的架构设计

[2] 简述移动端IM开发的那些坑：架构设计、通信协议和客户端

[3] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[4] 一套原创分布式即时通讯(IM)系统理论架构方案

[5] 移动端IM中大规模群消息的推送如何保证效率、实时性？

[6] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[7] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[8] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[9] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[10] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[11] 阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路

[12] 基于实践：一套百万消息量小规模IM系统技术要点总结

[13] 跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）

[14] 一套十万级TPS的IM综合消息系统的架构实践与思考

[15] 得物从0到1自研客服IM系统的技术实践之路

[16] 海量用户IM聊天室的架构设计与实践

[17] 史上最通俗Netty入门长文：基本介绍、环境搭建、动手实战

[18] 新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析

[19] 写给初学者：Java高性能NIO框架Netty的学习方法和进阶策略

[20] 手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制

[21] 史上最强Java NIO入门：担心从入门到放弃的，请读这篇！

（本文已同步发布于：http://www.52im.net/thread-4564-1-1.html）

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第28 期。

[- 1 -] 新手入门一篇就够：从零开发移动端IM

[链接] http://www.52im.net/thread-464-1-1.html

[摘要] 本文将以新手的视角引导你阅读相关文章，便于你从零开发一个移动端IM做好方方面面的知识准备：包括但不限于网络编程基础、通信协议的选型、IM的架构设计等等。文笔有限，如有不妥之处还请批评指正，希望对你有用。

[- 2 -] 移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”

[链接] http://www.52im.net/thread-1587-1-1.html

[摘要] 本文的目的，就是希望以通俗易懂的语言，帮助移动端IM开发者更好地理解移动网络的各种特性，使得开发出的功能能更好地适应移动网络，给用户带来更好的使用体验。

[- 3 -] 移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结

[链接] http://www.52im.net/thread-1588-1-1.html

[摘要] 本文将针对上篇中提到的特性，结合我们的实践经验，总结了四个方法来追求极致的“爽快”：快链路、轻往复、强监控、多异步，从理论讲到实践、从技术讲到产品，理论联系实际，举一反三，希望给您带来启发。

[- 4 -] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[链接] http://www.52im.net/thread-1470-1-1.html

[摘要] 这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制

[- 5 -] 现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障

[链接] http://www.52im.net/thread-1413-1-1.html

[摘要] 本文整理的有关内容，对于移动端即时通讯IM应用来说，同样具有启发意义

[- 6 -] 腾讯技术分享：社交网络图片的带宽压缩技术演进之路

[链接] http://www.52im.net/thread-1391-1-1.html

[摘要] 为了进一步降低运营带宽成本，减小用户访问流量及提升页面加载速度，社交网络 CDN运维紧跟行业图片优化趋势，创新引入WebP、SharpP、自适应分辨率、Guetzli等图像压缩技术到现网，经过三年多的多部门联合攻关，已逐渐形成一套覆盖全图片类型（JPEG、JPG、PNG、WebP、GIF）多场景的图片压缩运营体系，适用于各类型终端，每年节约外网带宽几百G。

[- 7 -] 小白必读：闲话HTTP短连接中的Session和Token

[链接] http://www.52im.net/thread-1686-1-1.html

[摘要] 本文的写作目的是以最白话地方式，通俗易懂的为你讲清HTTP协议中的Session和Token等概念，希望读完全文，您仍能满怀信心，继续义无反顾地跳入程序员这个职业深坑 ^_^。更深入的技术细节，请阅读《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》。

[- 8 -] IM开发基础知识补课：正确理解前置HTTP SSO单点登录接口的原理

[链接] http://www.52im.net/thread-1351-1-1.html

[摘要] 针对上述主流移动IM系统中“长”、“短”连接的分工方式，其中最为重要也是用户最先接触到的——就是基于Http的SSO单点登陆接口（有的系统里可能并不叫SSO接口，本文讨论的是其广义：即实现身份认证功能的http接口），那么这个SSO接口工作原理是什么？可以怎么来实现？有无最佳实践建议？

[- 9 -]  移动端IM中大规模群消息的推送如何保证效率、实时性？

[链接] http://www.52im.net/thread-1221-1-1.html

[摘要] 实际在生产环境下，群消息的发送都会想尽办法进行压缩，并开展各种改善性能的处理办法，而不是像上述举例里的直接扩散写（即2000人群里，一条消息被简单地复制为2000条一对一的消息投递）。具体有哪些优先策略？本文或许可以带给你一些启发。

[- 10 -] 移动端IM开发需要面对的技术问题

[链接] http://www.52im.net/thread-133-1-1.html

[摘要] 这两年多一直从事网易云信 iOS 端 IM SDK的开发，期间不断有兄弟部门的同事和合作伙伴过来问各种技术细节，干脆统一介绍下一个IM APP的方方面面，包括技术选型（包括通讯方式，网络连接方式，协议选择）和常见问题。

[- 11 -] 开发IM是自己设计协议用字节流好还是字符流好？

[链接] http://www.52im.net/thread-150-1-1.html

[摘要] 自己设计协议的话，协议用字节流好还是字符流好？ 各有什么优缺点？

[- 12 -] 请问有人知道语音留言聊天的主流实现方式吗？

[链接] http://www.52im.net/thread-175-1-1.html

[摘要] 请问有人知道语音聊天的主流实现方式吗？就是类似微信那种，按住说话，录一段，发送那种。这语音文件录好之后是直接转成二进制发送。还是说当成一个文件上传到服务器，然后发送一个消息给对方，对方收到后下载？

[- 13 -] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[链接] http://www.52im.net/thread-294-1-1.html

[摘要] 本文将要讨论的是即时IM应用中极其重要但也不被用户感知的消息送达保证机制（即QoS机制），文中将给出目前主流的参考实现思路。

[- 14 -] IM消息送达保证机制实现(二)：保证离线消息的可靠投递

[链接] http://www.52im.net/thread-594-1-1.html

[摘要] 实时在线投递针对的是消息收发双方都在线的情况（如当发送方用户A发送消息给接收方用户B时，用户B是在线的），那如果消息的接收方用户B不在线，系统是如何保证消息的可达性的呢？这就是本文要讨论的问题。

[- 15 -] 如何保证IM实时消息的“时序性”与“一致性”？

[链接] http://www.52im.net/thread-714-1-1.html

[摘要] 实时消息时序和一致性是分布式系统架构设计中非常难的问题（尤其IM应用这种以消息为中心的应用形态），困难在哪？有什么常见优化实践？这就是本文要讨论的内容。

[- 16 -] 一个低成本确保IM消息时序的方法探讨

[链接] http://www.52im.net/thread-866-1-1.html

[摘要] IM类系统中，都需要考虑消息时序问题，如果后发送的消息先显示，可能严重扰乱聊天消息所要表达的意义。

[- 17 -] IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？

[链接] http://www.52im.net/thread-715-1-1.html

[摘要] “用户在线状态的一致性”（单聊好友在线状态、群聊用户在线状态）是IM应用领域比较难解决的一个技术问题，如何精准实时的获得好友、群友的在线状态，是今天将要探讨的话题。

[- 18 -] IM群聊消息如此复杂，如何保证不丢不重？

[链接] http://www.52im.net/thread-753-1-1.html

[摘要] 由于“消息风暴扩散系数”的存在（概念详见《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》），群消息的复杂度要远高于一对一的单聊消息。群消息的实时性、可达性、离线消息是今天将要讨论的核心话题。

👉52im社区本周新文：《一套分布式IM即时通讯系统的技术选型和架构设计》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由NetworkFox分享，来源于华三通信，原题“什么是国密算法？”，本文有修订和改动。

1、引言

最近几年经常能听到IM应用的开发者讨论国产信创方面的技术问题，在某些场景下，国密算法是硬性要求，所以学习一下国密算法还是很有必要的。

国密算法是指由中国国家密码管理局发布的密码算法标准，旨在保障国家信息安全。目前，国家密码管理局已发布了一系列国产商用密码标准算法，包括SM1（SCB2）、SM2、SM3、SM4、SM7、SM9以及祖冲之密码算法（ZUC)等。通过在金融、电子政务及安防等领域广泛应用国密算法，在对敏感数据进行机密性、完整性和可用性保护的同时，减少对外部密码产品的依赖，提升国家信息安全水平。

本文将尽量以通俗易懂的文字，为你分享国密算法的种类、技术原理和应用场景等。

2、系列文章

本文是IM通讯安全知识系列文章中的第12篇，此系列总目录如下：

《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》

《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》

《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》

《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》

《即时通讯安全篇（五）：对称加密技术在Android平台上的应用实践》

《即时通讯安全篇（六）：非对称加密技术的原理与应用实践》

《即时通讯安全篇（七）：用JWT技术解决IM系统Socket长连接的身份认证痛点》

《即时通讯安全篇（八）：如果这样来理解HTTPS原理，一篇就够了》

《即时通讯安全篇（九）：你知道，HTTPS用的是对称加密还是非对称加密？》

《即时通讯安全篇（十）：为什么要用HTTPS？深入浅出，探密短连接的安全性》

《即时通讯安全篇（十一）：IM聊天系统安全手段之通信连接层加密技术》

《即时通讯安全篇（十二）：IM聊天系统安全手段之传输内容端到端加密技术》

《即时通讯安全篇（十三）：信创必学，一文读懂什么是国密算法》（* 本文）

3、为什么需要国密算法？

3.1国密算法的产生背景

在网络信息传输和存储过程中，数据的保密性和安全性是一项重要的需求。

传统的国际标准加密算法虽然安全可靠，但由于无法保证源代码的安全性，因此存在着源代码被外部恶意攻击者渗透或篡改的风险。为了构建安全的行业网络环境并增强国家行业信息系统的“安全可控”能力，中国积极开展了针对信息安全需求的研究和探索。

自2007年开始，中国制定了国密算法标准，并于2010年正式发布。

经过多年的发展、改进和完善，国密算法已成为中国自主研发的密码算法标准，并在各行业得到广泛应用。它的诞生不仅显著提升了中国在密码技术领域的核心竞争力，还为国家信息安全建设作出了重要贡献。

3.2国密算法的特点

国密算法具备如下特点：

1）安全性高：国密算法采用了严密的密码学原理和复杂的运算方式，具有较高的安全性。它在加密、数字签名和哈希等功能上都能提供可靠的保护，抵抗了各种传统和现代密码攻击手段。

2）高效性与灵活性：国密算法在保证安全性的同时，注重算法的效率。它的加密速度和运行效率相对较高，同时也能适应不同的密码长度和密钥长度，以满足不同场景的需求。

3）标准化广泛：国密算法已被国家标准化机构认可和采用。它符合国际密码学标准的基本要求，具备与国际算法相媲美的能力。同时，国密算法也在国内推广和应用广泛，成为中国信息安全领域的基础核心算法之一。

4）自主创新：国密算法是中国自主研发的密码算法，所以对于算法的实现和推广都具有独立的掌控能力。这意味着中国可以更好地保护自己的国家信息安全，减少对外依赖，提高自主抵抗能力。

5）面向多领域应用：国密算法不仅局限于某个特定领域的应用，它适用于金融业、电子商务、通信、物联网、区块链等不同领域的信息安全保护。它的广泛应用范围使得国密算法可以满足不同行业的安全需求。

4、国密算法应用概述

国密算法包括SM1（SCB2）、SM2、SM3、SM4、SM7、SM9以及祖冲之密码算法（ZUC)等。

其中：

• 1）SM1、SM4、SM7、祖冲之密码（ZUC）属于对称算法；
• 2）SM2、SM9属于非对称算法；
• 3）SM3属于杂凑算法。

下文将主要介绍国密算法中的常用算法SM1、SM2、SM3和SM4的实现和应用。

5、SM1算法的原理和应用场景

SM1算法是国密算法中的一种对称加密算法，其特点是加解密使用相同密钥。利用SM1对称加密算法加解密数据的过程。

SM1算法未公开，仅以IP核（Intellectual Property Core，一种预先做好的集成电路功能模块）的形式存在于芯片中。

SM1算法主要用于小数据量的加密保护，因此被广泛用于研制智能IC卡、智能密码钥匙、门禁卡、加密卡等安全产品。

6、SM2算法的实现和应用场景

6.1概述

SM2算法是基于ECC（Elliptic Curve Cryptography）椭圆曲线的非对称加密算法，包括了SM2-1椭圆曲线数字签名算法、SM2-2椭圆曲线密钥交换协议和SM2-3椭圆曲线公钥加密算法，分别用于实现数字签名、密钥协商和数据加密等功能。

SM2算法在许多领域都有广泛的应用。

在电子商务领域：SM2算法被用于保护用户个人信息的安全传输，确保用户在网上交易过程中的隐私和财产的安全。

在互联网金融领域：SM2算法被用于数字支付、电子银行等场景，实现用户身份认证和交易的安全性。

此外，SM2算法还适用于物联网领域，保护物联网设备之间的通信安全，确保数据的可靠传输。

6.2数据加密

在非对称加密算法中，可对外公布的密钥称为“公钥”，只有持有者所知的密钥称为“私钥”。发送者使用接收者的公钥来加密消息，接收者用自己的私钥解密和读取该消息。

利用SM2非对称加密算法加解密数据的过程：

6.3密钥协商

由于椭圆曲线的计算复杂性高，破解难度大，因此SM2算法在密钥协商技术领域也起着关键作用。

利用SM2算法进行密钥协商的过程：

• 1）会话双方生成自己的私钥（随机数）；
• 2）会话双方由私钥、ECC椭圆曲线参数G各自计算出公钥；
• 3）会话双方将自己的公钥传递给对方，传递过程公开。由于椭圆曲线的计算复杂性高，破解难度大，因此攻击者难以通过公钥和椭圆曲线参数G反推出私钥；
• 4） 双方将自己的私钥与对方的公钥进行运算，最终得到相同的会话密钥，该会话密钥可作为共享密钥用于对称加密（例如SM4算法）通信。

6.4数字签名

数字签名是一种用于验证信息完整性、真实性和来源的技术手段。它通常用于确保数据在传输或存储过程中没有被篡改，并且可以追溯到特定的发送方。

发送方使用自己的私钥对消息进行加密，生成数字签名。接收方使用发送方的公钥对签名进行解密和验证，以验证消息的完整性和真实性。

在数字签名应用中，SM2算法通常与SM3摘要算法一起使用。

7、SM3算法的实现和应用场景

SM3杂凑（Hashing）算法是国密算法中的一种摘要算法。

SM3算法通过哈希函数将任意长度的消息压缩成固定长度的摘要。摘要具有唯一性，即不同信息生成的摘要不同，且无法由摘要恢复出原始信息，更无法伪造信息获得相同摘要，因此SM3算法被广泛用于实现数字签名、数据完整性检测及消息验证等功能。

基于SM3算法的特点，在信息安全领域，SM3算法被用于保护密码学协议、数字证书和电子签名等数据的完整性。在区块链领域，SM3算法被用于加密货币的区块生成和链上交易的校验，确保区块链的安全性。

此外，SM3算法还可以应用于密码学随机数的生成和伪随机序列的校验等领域，增加了数据的安全性和可靠性。

利用SM2算法和SM3算法对用户数据进行数字签名认证及完整性校验的过程：

• 1） 用户A发送的数据A经过SM3哈希算法运算生成摘要A。
• 2） 摘要A经过用户A的私钥加密生成数字签名。
• 3） 用户A的明文数据和数字签名经加密算法（SM1/SM2/SM4）加密成密文后发送给用户B。加密算法以非对称加密算法SM2为例，即加解密使用不同密钥。
• 4）密文到达用户B处，经加密算法（SM1/SM2/SM4）解密后，还原成明文数据和数字签名。
• 5）用户B使用用户A的公钥解密数据包中的数字签名：
•      解密成功，数据来源合法，得到摘要A；
•      解密失败，数据来源非用户A，丢弃本次数据。
• 6）收到的数据包中的明文数据经过SM3哈希运算生成摘要A’。对比摘要A和摘要A’：
•      摘要A’＝摘要A，数据完整；
•      摘要A’≠摘要A，数据被篡改，丢弃本次数据。

8、SM4算法的实现和应用

8.1概述

与SM1算法分类相同，SM4算法同样为分组对称加密算法，但SM4算法实现公开。

分组加密算法是将明文数据按固定长度进行分组，用同一密钥逐组加密，密文解密时同样使用相同密钥逐组解密。

SM4算法实现简单，因此加解密速度较快，消耗资源少，主要用于大数据量的加密和解密，例如静态储存或数据信号传输通道中数据的加解密。

在网络安全领域，SM4算法被用于保护网络传输和存储的敏感数据，如银行卡信息、密码等。在物联网领域，SM4算法被用于物联网设备之间的通信和数据加密，确保物联网数据的隐私安全。

此外，SM4算法还可以应用于区块链领域，保护加密货币的交易安全等领域，为相关系统和数据的安全提供了保障。

SM4算法支持ECB、CBC、CFB等多种分组模式，下文将介绍ECB和CBC两种基础模式。

8.2加解密模式：ECB模式

SM4算法基于ECB模式对数据加解密的过程：

• 1）发送端将明文按固定长度分组，对每个明文分组分别使用相同的密钥进行加密生成密文分组。完整的密文由所有密文分组按序排列组合而成；
• 2）接收端将密文按固定长度分组，对每个密文分组分别使用相同的密钥进行解密生成明文分组。所有明文分组按序排列组合而成完整的明文数据。

ECB模式实现简单，各段数据间互不影响，有利于并行运算，但相同的明文块会被加密成相同的密文块，不能提供严格的数据保密性。

8.3加解密模式：CBC模式

SM4算法基于CBC模式对明文加密的过程：

• 1）将明文按固定长度分组；
• 2）明文分组1与初始向量IV进行异或运算，异或运算的结果经密钥加密后得到密文分组1；
• 3）剩余的明文分组依次与前一个密文分组进行异或运算后再加密，得到对应的密文分组；
• 4）完整的密文由所有密文分组按序排列组合而成。

SM4算法基于CBC模式对密文解密的过程：

• 1）将密文按固定长度分组后，对密文分组进行倒序处理；
• 2）对密文分组n先使用密钥进行解密，密文分组n解密后的数据与密文分组n-1进行逻辑逆运算，得到明文分组n；
• 3） 同理，剩余的密文分组解密后再与前一个密文分组进行逻辑逆运算，得到对应的明文分组；
• 4）最后，密文分组1用密钥解密后的数据是与初始向量进行逻辑逆运算，然后得到明文分组1；
• 5）完整的明文由所有明文分组按序排列组合而成。

CBC模式安全性高于ECB，但明文块不能并行计算，且误差会传递下去。

9、国密算法与国际标准算法的对比

国密算法和国际标准算法都是现代密码学中常用的加密算法，但在技术和优劣方面存在一些区别。

常见国密算法与国际标准算法各参数性能的对比如下：

10、国密算法的典型应用场景有哪些？

10.1AD-WAN纵向IP/MPLS组网

国密算法可以与AD-WAN技术结合，应用于IP/MPLS纵向网场景。

通过AD-WAN智能运维平台，实现国密配置一键下发，在网络中构建国密数据加密通道，实现基于国密的端到端的IPsec隧道保护。

国密算法在端到端的IPsec隧道中的工作原理如下：

1）在IKE密钥协商阶段，使用IKE协议进行密钥协商过程中，采用SM2算法生成会话密钥。

2）在身份认证阶段，本端使用SM2和SM3算法生成身份信息的数字签名，并使用SM1或SM4算法和会话密钥对身份信息和数字签名进行加密；对端收到加密的身份信息后，使用相同的会话密钥解密，然后通过SM2和SM3算法进行身份认证。

3）在数据传输阶段，本端使用SM2和SM3算法生成用户数据的数字签名，并使用SM1或SM4算法以及会话密钥对用户数据和数字签名进行加密；对端收到加密的用户数据后，使用相同的会话密钥解密，然后通过SM2和SM3算法进行数据完整性检查。

10.24G/5G VPDN业务组网

4G/5G VPDN（Virtual Private Dialup Network，虚拟专有拨号网络）业务是在4G/5G无线网络中采用拨号方式实现的一种虚拟专有网络业务。它利用L2TP技术为客户构建与互联网隔离的隧道，以满足客户分支和总部内网通信的需求。VPDN组网同时支持将L2TP和IPsec技术结合，通过L2TP完成用户认证确保接入安全，并利用IPsec保障通信数据安全。

1）4G/5G VPDN组网中分支网关由4G/5G路由设备担任，通过拨号接入运营商网络。

2）运营商对4G/5G路由设备的APN（Access Point Name，接入点名称）、账户、SIM/USIM卡信息进行认证。

3）4G/5G路由设备认证通过后被运营商判断是VPDN用户，同时由运营商AAA服务器向LAC（L2TP Access Concentrator，L2TP访问集中器）设备下发L2TP隧道属性，LAC设备将基于下发的L2TP隧道属性信息向该VPDN用户所属总部的LNS（L2TP Network Server，L2TP网络服务器）设备发起隧道建立请求。

4）L2TP隧道建立后，LAC设备会通过此隧道向LNS设备透传用户的认证信息。LNS设备向总部内网的AAA服务器发起对VPDN用户的二次认证，认证通过后为VPDN用户分配一个企业内网IP地址。分支终端用户和总部可以开始通信。

5）分支网关与总部网关设备上均安装有国密板卡，通过IPsec协商建立起端到端的IPsec隧道，使用国密算法对传输的数据报文进行加密保护和数据完整性检查。

6）经IPsec加密后的数据报文在LAC设备处进行L2TP封装后，通过L2TP隧道传输到LNS。

7）LNS收到数据报文后首先对L2TP报文进行解封装，然后经过IPsec解密还原出数据报文，根据报文目的IP地址转发报文。

11、相关文章

[1] 常用加解密算法与通讯安全讲解

[2] 非对称加密技术的原理与应用实践

[3] IM聊天系统安全手段之通信连接层加密技术

[4] IM聊天系统安全手段之传输内容端到端加密技术

[5] 通俗易懂：一篇掌握即时通讯的消息传输安全原理

[6] 基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等

[7] 理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）

[8] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解

[9] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

（本文已同步发布于：http://www.52im.net/thread-4552-1-1.html）

​为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第27 期。

[- 1 -] 专访微信视频技术负责人：微信实时视频聊天技术的演进

[链接] http://www.52im.net/thread-1201-1-1.html

[摘要] 本次专访是对谷沉沉老师在即将到来的 2017ArchSummit 全球架构师峰会上，以《数亿微信视频通话背后的视频技术二三事》为题发表演讲的一次预热。

[- 2 -] 腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天

[链接] http://www.52im.net/thread-1308-1-1.html

[摘要] 腾讯音视频实验室和优图实验室X-lab的戴宇榮老师的团队联合开发的基于神经网络的实时视频超分辨率技术，在极小的神经网络模型大小的条件下，在手机实时视频通话上实现了基于机器学习的超分辨率技术，起到了主观上提升一档分辨率的效果。此技术即将应用在手机QQ 7.3.5的iOS版本上的实时视频聊天。

[- 3 -] 微信团队分享：微信每日亿次实时音视频聊天背后的技术解密

[链接] http://www.52im.net/thread-1311-1-1.html

[摘要] 本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案，同时分享在实时音视频聊天中的视频编码器研发的方法和经验。

[- 4 -]福利贴：最全实时音视频开发要用到的开源工程汇总

[链接] http://www.52im.net/thread-1395-1-1.html

[摘要] 本文汇总了一些能帮助到正在学习或进行实时音视频开发的同行们的开源工程，这些工程分为几类：音视频编解码类、视频前后处理、服务端类等，希望能加速您的学习或研究过程。

[- 5 -] 实时音视频聊天中超低延迟架构的思考与技术实践

[链接] http://www.52im.net/thread-1465-1-1.html

[摘要] 从直播在线上抓娃娃，不断变化的是玩法的创新，始终不变的是对超低延迟的苛求。实时架构是超低延迟的基石，如何在信源编码、信道编码和实时传输整个链条来构建实时架构？在实时架构的基础之上，如果通过优化采集、编码、传输、解码和渲染中的关键环节来降低延迟？本文将会介绍即构在这方面的思考与实践。

[- 6 -] 理解实时音视频聊天中的延时问题一篇就够

[链接] http://www.52im.net/thread-1553-1-1.html

[摘要] 音视频实时通讯的应用场景已经随处可见，从“吃鸡”的语音对讲、直播连麦、直播答题组队开黑，再到银行视频开户等。对于开发者来讲，除了关注如何能快速实现不同应用场景重点额音视频通讯，另一个更需要关注的可能就是“低延时”。但是，到底实时音视频传输延时应该如何“低”，才能满足你的应用场景呢？

[- 7 -] 写给小白的实时音视频技术入门提纲

[链接] http://www.52im.net/thread-1620-1-1.html

[摘要] 本文是由一篇演讲稿整理出来的文章，目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们，对大家有所帮助。

[- 8 -] 微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等

[链接] http://www.52im.net/thread-1746-1-1.html

[摘要] 腾讯多媒体内核中心高级研究员时永方接受了LiveVideoStack的邮件采访，谈及了个人成长中的关键时刻，学习多媒体开发的三点核心，以及在5G和高清时代下，微信多媒体团队面临的挑战。

[- 9 -]  腾讯技术分享：微信小程序音视频技术背后的故事

[链接] http://www.52im.net/thread-1799-1-1.html

[摘要] 本文来自腾讯视频云终端技术总监rexchang（常青）的技术分享，讲述的是微信小程序中音视频技术构思、设计和实现等方方面的内容，希望能为你的音视频技术实践带来启发。

[- 10 -] 微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术

[链接] http://www.52im.net/thread-1828-1-1.html

[摘要] 从华为2012实验室到腾讯，过去十余年梁俊斌一直专注在音频技术。他告诉LiveVideoStack：音频技术还有许多难点需要解决，而作为技术人也延展到应用场景，关注用户需求。本文整理了本次访谈的主要内容，仅供参阅。

[- 11 -] 新浪微博技术分享：微博短视频服务的优化实践之路

[链接] http://www.52im.net/thread-1843-1-1.html

[摘要] 本文的短视频技术跟IM的单聊、群聊、朋友圈里的小视频是类似的东西，文中针对短视频的相关优化实践可以为您的IM小视频开发提供一定的参考和借鉴意义，希望对您有用。

[- 12 -] 以网游服务端的网络接入层设计为例，理解实时通信的技术挑战

[链接] http://www.52im.net/thread-1915-1-1.html

[摘要] 本文将尝试从开发者角度：梳理开发网游服务端的网络接入层的过程中面临的各种技术挑战，并针对性地提供相应的实时通信网络接入层解决思路，希望对于即时通讯应用的开发者来说，可以从中得到些许启发。

[- 13 -] 腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践

[链接] http://www.52im.net/thread-1988-1-1.html

[摘要] 本文来自腾讯视频云终端技术总监rexchang（常青）技术分享，内容分别介绍了微信小程序视音视频和WebRTC的技术特征、差异等，并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。希望能带给你启发。

[- 14 -] 爱奇艺技术分享：轻松诙谐，讲解视频编解码技术的过去、现在和将来

[链接] http://www.52im.net/thread-3028-1-1.html

[摘要] 本文以轻松幽默的语气，讲解了视频编解码的一些基本常识，并以爱奇艺为例，讲述了视频编解码技术在国内的发展以及未来的一些展望。

[- 15 -] 零基础入门：实时音视频技术基础知识全面盘点

[链接] http://www.52im.net/thread-3079-1-1.html

[摘要] 本文是作者自已根据入门实时音视频的亲身经历，对于基础知识点的认知总结。虽然很浅显，但相对小白来说，能稍微系统的了解这些概念就已经是很好的起点了。

[- 16 -] 实时音视频面视必备：快速掌握11个视频技术相关的基础概念

[链接] http://www.52im.net/thread-3194-1-1.html

[摘要] 本文将通过通俗的文字，言简意赅地为你讲解实时音视频技术中跟视频技术在关的11个非常重要的基础知识概念，希望能为你日后从事这方面的工作起到抛砖引玉的作用。

[- 17 -] 实时音视频开发理论必备：如何省流量？视频高度压缩背后的预测技术

[链接] http://www.52im.net/thread-3581-1-1.html

[摘要] 本文将从视频编解码技术的基础知识入手，引出视频编解码技术中非常基础且重要的预测技术，学习帧内预测和帧间预测的技术原理。

👉52im社区本周新文：《即时通讯安全篇（十三）：信创必学，一文读懂什么是国密算法》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统，是RainbowChat的姊妹系统（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统）。

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第26 期。

[- 1 -] 实时语音聊天中的音频处理与编码压缩技术简述

[链接] http://www.52im.net/thread-825-1-1.html

[摘要] 在视频或者音频通话过程中，一方面为了减小原始声音数据的传输码率，需要进行音频压缩，另一方面为了得到更高质量的音质，需要进行音频处理。如何处理好这两方面，保证声音传播的高真性，是个技术活儿！

[- 2 -] 网易视频云技术分享：音频处理与压缩技术快速入门

[链接] http://www.52im.net/thread-678-1-1.html

[摘要] 随着音频处理和压缩技术的不断发展，效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现，不断改善我们的生活。

[- 3 -] 学习RFC3550：RTP/RTCP实时传输协议基础知识

[链接] http://www.52im.net/thread-590-1-1.html

[摘要] 本文对这些协议进行初步归纳总结，在分析RFC3550的基础上，重点分析RTP系列协议，并以报文类型为主线分析RTCP系列协议。

[- 4 -]基于RTMP数据传输协议的实时流媒体技术研究（论文全文）

[链接] http://www.52im.net/thread-273-1-1.html

[摘要] 本文来自论文《基于 RTMP 协议的流媒体技术的原理与应用》，文中研究了基于 Flash 平台的流媒体系统中使用的 RTMP 协议的原理和应用，并对网络上实时流媒体的各种传输方式的优缺点进行了分析。

[- 5 -] 声网架构师谈实时音视频云的实现难点(视频采访)

[链接] http://www.52im.net/thread-399-1-1.html

[摘要] 孙雨润，声网 Agora.io 首席音视频架构师，负责全球音视频传输技术架构。毕业于中国科学技术大学，原 YY 后台架构师，主导 Web YY 整体后台系统架构搭建。曾任职腾讯 QQ 研究员 ，主导 QQ 空间面孔墙等项目；任职微软 Microsoft 期间，参与高性能计算产品项目。

[- 6 -] 还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！

[链接] http://www.52im.net/thread-507-1-1.html

[摘要] 实时语音聊天开发，对于一般的开发者来说比较神秘，很多朋友不太清楚如何全面的评估一个音频引擎。

[- 7 -] 如何用最简单的方法测试你的实时音视频方案

[链接] http://www.52im.net/thread-535-1-1.html

[摘要] 本文总结了一些有关实时音视频方案比较值得自测的要点，旨在没有生产环境反馈和丰富的测试资源情况下，用较低的成本来测试覆盖尽可能多的真实场景中可能遇到的网络和设备问题。

[- 8 -] 简述实时音视频聊天中端到端加密（E2EE）的工作原理

[链接] http://www.52im.net/thread-763-1-1.html

[摘要] 本文着重阐述端到端加密(E2EE)，端到端加密是确保数据传输安全的可行方法之一。读完这篇文章，你可以了解这种加密方式的基本原理.

[- 9 -]  理论联系实际：实现一个简单地基于HTML5的实时视频直播

[链接] http://www.52im.net/thread-875-1-1.html

[摘要] 本次分享就向大家介绍一下分享一下直播的整个流程和一些技术点，并动手实现一个简单的Demo。

[- 10 -] IM实时音视频聊天时的回声消除技术详解

[链接] http://www.52im.net/thread-939-1-1.html

[摘要] 为了不让文章读起来枯燥，本文将尽量通俗易懂地为您讲解实时音视频聊天场景下的回声消除技术原因希望能带给你些许启发。

[- 11 -] 如何优化传输机制来实现实时音视频的超低延迟？

[链接] http://www.52im.net/thread-1008-1-1.html

[摘要] 要在语音视频 SDK 中实现超低延迟，实时的语音视频传输机制是必不可少的，而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石。

[- 12 -] 实时通信RTC技术栈之：视频编解码

[链接] http://www.52im.net/thread-1034-1-1.html

[摘要] 本文是系列文章的第一篇：讲述视频编解码的一些基本知识。

[- 13 -] Android直播入门实践：动手搭建一套简单的直播系统

[链接] http://www.52im.net/thread-1154-1-1.html

[摘要] 实时视频直播是这两年非常火的技术形态，已经渗透到教育、在线互娱等各种业务场景中。但要搭建一套实时视频直播系统，并非易事，当然相关的直播技术理论在论坛的其它文章里已经写的非常详细，本文不再展开。

[- 14 -] 网易云信实时视频直播在TCP数据传输层的一些优化思路

[链接] http://www.52im.net/thread-1254-1-1.html

[摘要] 网易云信的实时视频直播目前使用了TCP进行传输，且基于此，从编码动态适配、发送队列调整、协议优化、socket等做了全流程的优化，确保在限带宽、丢包、时延、抖动，无论单项还是复杂网络，都有非常不错的实际体验。

[- 15 -] 实时音视频聊天技术分享：面向不可靠网络的抗丢包编解码器

[链接] http://www.52im.net/thread-1281-1-1.html

[摘要] 编解码器面向直播和网络通信是不一样的，我今天想说的是面向不可靠传输网络的抗丢包编解码器。

[- 16 -] P2P技术如何将实时视频直播带宽降低75%？

[链接] http://www.52im.net/thread-1289-1-1.html

[摘要] 那整个系统是怎么设计的？使用了哪些技术来达成目标？接下来我来重点分享一下架构设计和技术细节。

👉52im社区本周新文：《抖音技术分享：抖音Android端手机功耗问题的全面分析和详细优化实践》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

​为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第25 期。

[- 1 -] 即时通讯音视频开发（一）：视频编解码之理论概述

[链接] http://www.52im.net/thread-228-1-1.html

[摘要] 本文主要讲解实时音视频技术中视频技术的编解码基础理论。

[- 2 -] 即时通讯音视频开发（二）：视频编解码之数字视频介绍

[链接] http://www.52im.net/thread-229-1-1.html

[摘要] 本文主要讲解实时音视频技术中视频技术的数字视频知识。

[- 3 -] 即时通讯音视频开发（三）：视频编解码之编码基础

[链接] http://www.52im.net/thread-232-1-1.html

[摘要] 本文主要讲解实时音视频技术中视频技术的编码理论知识。

[- 4 -] 即时通讯音视频开发（四）：视频编解码之预测技术介绍

[链接] http://www.52im.net/thread-235-1-1.html

[摘要] 本文主要讲解实时音视频技术中视频技术的预测技术理论知识。

[- 5 -] 即时通讯音视频开发（五）：认识主流视频编码技术H.264

[链接] http://www.52im.net/thread-237-1-1.html

[摘要] 本文主要讲解实时音视频技术中目前主流的视频编码技术H.264相关知识。

[- 6 -] 即时通讯音视频开发（六）：如何开始音频编解码技术的学习

[链接] http://www.52im.net/thread-241-1-1.html

[摘要] 本文是一篇讲述新手如何学习音频编解码知识的文章。

[- 7 -] 即时通讯音视频开发（七）：音频基础及编码原理入门

[链接] http://www.52im.net/thread-242-1-1.html

[摘要] 本文是一篇讲述基础音频知识和编码原理的文章。

[- 8 -]  即时通讯音视频开发（八）：常见的实时语音通讯编码标准

[链接] http://www.52im.net/thread-243-1-1.html

[摘要] 本文是一篇讲述常用的实用音频通讯编码标准的文章。

[- 9 -] 即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述

[链接] http://www.52im.net/thread-247-1-1.html

[摘要] 本文是一篇介绍实时音频通讯过程中的回音问题，以及回音消除技术的介绍文章。

[- 10 -] 即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解

[链接] http://www.52im.net/thread-250-1-1.html

[摘要] 本文是一篇详细介绍实时音频通讯过程中的回音消除技术的文章，主要描述的是回音消除技术理论和算法原理等。

[- 11 -] 即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解

[链接] http://www.52im.net/thread-251-1-1.html

[摘要] 本文是一篇详细介绍实时语音通讯过程中的丢包补偿技术的文章。

[- 12 -] 即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨

[链接] http://www.52im.net/thread-253-1-1.html

[摘要] 虽然都是视频通讯，大部分情况下的单人视频通话可能根本不需要用到流媒体服务，而多人视频，如在线教育这些则必须用到，所以下面主要介绍多人视频中服务端架构模式，以及各自特点。

[- 13 -] 即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势

[链接] http://www.52im.net/thread-266-1-1.html

[摘要] 本文主要讲解实时音视频技术中最流行的视频编码技术H.264的特点和优势，希望能为您的技术选型提供一定的参考。

[- 14 -] 即时通讯音视频开发（十四）：实时音视频数据传输协议介绍

[链接] http://www.52im.net/thread-267-1-1.html

[摘要] 本文将简要介绍这些主流的实时音视频数据传输协议。

[- 15 -] 即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况

[链接] http://www.52im.net/thread-269-1-1.html

[摘要] p2p就是点对点，两个客户端直接进行数据交互，不需要经过服务器转发(relay)，这种方式能大大减轻服务端的负载，所以特别视适合大数据的传输，比如实时音视频聊天、在线视频直播、大文件传输等应用场景。

[- 16 -] 即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议

[链接] http://www.52im.net/thread-270-1-1.html

[摘要] 本文将就几个典型问题给出简要的参考建议。

[- 17 -] 即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生

[链接] http://www.52im.net/thread-274-1-1.html

[摘要] 本文重在为读者从技术角度讲解H.264和VP8的发展渊源以及现时所面临的问题，相信读完此文后，对于即时通讯（IM聊天应用）的实时音视频开发中视频编码的选择会有个直观的了解。

[- 18 -] 即时通讯音视频开发（十八）：详解音频编解码的原理、演进和应用选型

[链接] http://www.52im.net/thread-2230-1-1.html

[摘要] 以下就是本次为大家分享的主要内容，希望通过此次分享可以使大家对音频编解码有一个整体的认识，并在实际应用中有参考的依据。

[- 19 -] 即时通讯音视频开发（十九）：零基础，史上最通俗视频编码技术入门

[链接] http://www.52im.net/thread-2840-1-1.html

[摘要] 视频编码技术涉及的内容太过专业和庞杂，市面上的书籍或博客多数都只是枯燥的技术概念罗列，对于新手来说读完依旧蒙逼是常态，本文将借此机会，专门给大家做一个关于视频编码的零基础科普。

[- 20 -] 即时通讯音视频开发（二十）：一文读懂视频的颜色模型转换和色域转换

[链接] http://www.52im.net/thread-4467-1-1.html

[摘要] 本文将以通俗易懂的文字，引导你理解视频是如何从采集开始，历经各种步骤，最终通过颜色模型转换和不同的色域转换，让你看到赏心悦目的视频结果的。

👉52im社区本周新文：《跟着源码学IM(十二)：基于Netty打造一款高性能的IM即时通讯程序》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第 24 期。

[- 1 -] 开源实时音视频技术WebRTC的现状

[链接] http://www.52im.net/article-126-1.html

[摘要] 作为Google开源的技术，WebRTC并不是一个可以拿来就用并且性能很好的产品，而且正如众多的其它开源技术一样，WebRTC的发展并没有期待中的快。

[- 2 -] 简述开源实时音视频技术WebRTC的优缺点

[链接] http://www.52im.net/thread-225-1-1.html

[摘要] 作为Google开源的技术，WebRTC并不是一个可以拿来就用并且性能很好的产品，需要工程师们对其进行较多的改善。本文主要来谈一谈WebRTC的优缺点。

[- 3 -] 访谈WebRTC标准之父：WebRTC的过去、现在和未来

[链接] http://www.52im.net/thread-227-1-1.html

[摘要] 首届（WebRTC）网络实时通信大会期间，InfoQ 对 WebRTC 之父 Daniel C. Burnett 进行了专访，以下是专访实录。（注：Daniel 在访谈中的观点仅代表他本人及其在 W3C 所做的工作。）

[- 4 -] 良心分享：WebRTC 零基础开发者教程（中文）[附件下载]

[链接] http://www.52im.net/thread-265-1-1.html

[摘要] WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音通话或视频聊天的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。

[- 5 -] WebRTC实时音视频技术的整体架构介绍

[链接] http://www.52im.net/thread-284-1-1.html

[摘要] 虽然WebRTC的目标是实现跨平台的Web端实时音视频通讯，但因为核心层代码的Native、高品质和内聚性，开发者很容易进行除Web平台外的移殖和应用。很长一段时间内WebRTC是业界能免费得到的唯一高品质实时音视频通讯技术。

[- 6 -] 新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？

[链接] http://www.52im.net/thread-356-1-1.html

[摘要] 通过WebRTC的端到端通信通常被人们所误解。WebRTC并不是真正意味着你不需要服务器来协商和联接通话。它只意味着，在多数情况中，你可以直接地在浏览器之间进行通信。

[- 7 -] WebRTC实时音视频技术基础：基本架构和协议栈

[链接] http://www.52im.net/thread-442-1-1.html

[摘要] 本文主要介绍WebRTC的架构和协议栈。

[- 8 -]  浅谈开发实时视频直播平台的技术要点

[链接] http://www.52im.net/thread-475-1-1.html

[摘要] 现在大大小小的公司，甚至个人开发者，都想开发自己的直播网站或App，本文会帮你理清，开发视频直播平台，你需要注意哪些技术要点。

[- 9 -] [观点] WebRTC应该选择H.264视频编码的四大理由

[链接] http://www.52im.net/thread-488-1-1.html

[摘要] 对实时音视频开发者来说，当开发一个基于WebRTC的产品时，我们应该选择什么样的视频编解码器？去年的时候，答案可能是“VP8”。几个月前，答案可能是“看情况”。现在答案是“除非必须用VP8，否则就用H.264”。

[- 10 -] 基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？

[链接] http://www.52im.net/thread-510-1-1.html

[摘要] 利用Google开源的WebRTC来开发自已的实时音视频系统，靠不靠谱这个问题一直被问到，其实很难一两句话说清楚，因为答案不是一个靠谱或不靠谱可以回答好的，既然被反复问到，今天就系统地整理参考答案。

[- 11 -] 开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用

[链接] http://www.52im.net/thread-589-1-1.html

[摘要] 本文在深入研究WebRTC源代码的基础上，以Video数据的发送和接收为例，力求用简洁语言描述RTP/RTCP模块的实现细节，为进一步深入掌握WebRTC打下良好基础。

[- 12 -] 简述实时音视频聊天中端到端加密（E2EE）的工作原理

[链接] http://www.52im.net/thread-763-1-1.html

[摘要] 本文着重阐述端到端加密(E2EE)，端到端加密是确保数据传输安全的可行方法之一。读完这篇文章，你可以了解这种加密方式的基本原理.

[- 13 -] 实时通信RTC技术栈之：视频编解码

[链接] http://www.52im.net/thread-1034-1-1.html

[摘要] 那么 RTC 技术栈究竟包含哪些技术，我们会提供一系列文章，来解读 RTC 技术栈。本文是系列文章的第一篇：讲述视频编解码的一些基本知识。

[- 14 -] 开源实时音视频技术WebRTC在Windows下的简明编译教程

[链接] http://www.52im.net/thread-1125-1-1.html

[摘要] WebRTC是提供了一整套处理实时音视频的开源库。它包括了音视频处理（采集，编解码，前处理，后处理，渲染），数据传输（实时传输，流控）和业务逻辑控制。可以说 WebRTC 的出现大大减少了做音视频开发的难度，所以熟练掌握好这个库对于做音视频相关的同学就显的特别重要了。

[- 15 -] 网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？

[链接] http://www.52im.net/thread-1282-1-1.html

[摘要] 直到2011年，WebRTC技术的出现，并且由谷歌做推广。WebRTC带来的体验是因为免安装才受到了关注。

[- 16 -] 了不起的WebRTC：生态日趋完善，或将实时音视频技术白菜化

[链接] http://www.52im.net/thread-1631-1-1.html

[摘要] 有人说 2017 年是 WebRTC 的转折之年，2018 年将是 WebRTC 的爆发之年，这并非没有根据。就在去年（2017年），WebRTC 1.0 标准草案出炉（实际上WebRTC标准草案的早期版本早在2011年就已经发布，WebRTC并非一夜之间就出现的技术），并将于今年正式发布。与此同时，越来越多的浏览器和厂商都开始对它进行广泛的支持，WebRTC 即将成为互联网的基础设施了，或许门槛如此之高的实时音视频技术终有白菜化的那一天。

[- 17 -] 腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践

[链接] http://www.52im.net/thread-1988-1-1.html

[摘要] 本文来自腾讯视频云终端技术总监rexchang（常青）技术分享，内容分别介绍了微信小程序视音视频和WebRTC的技术特征、差异等，并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。希望能带给你启发。

[- 18 -] 融云技术分享：基于WebRTC的实时音视频首帧显示时间优化实践

[链接] http://www.52im.net/thread-3169-1-1.html

[摘要] 本文主要通过对WebRTC接收端的音视频处理过程分析，来了解和优化视频首帧的显示时间，并进行了总结和分享。

[- 19 -] 零基础入门：基于开源WebRTC，从0到1实现实时音视频聊天功能

[链接] http://www.52im.net/thread-3680-1-1.html

[摘要] 本文将基于笔者公司开发的在线问诊产品中WebRTC技术的实践经验，讲述的如何基于WebRTC从零开发一个实时音视频聊天功能。文章会从WebRTC的基本知识、技术原理开始，基于开源技术为你演示如何搭建一个WebRTC实时音视频聊天功能。

[- 20 -] 实时音视频入门学习：开源工程WebRTC的技术原理和使用浅析

[链接] http://www.52im.net/thread-3804-1-1.html

[摘要] WebRTC（全称 Web Real-Time Communication），即网页即时通信。是一个支持网页浏览器进行实时语音对话或视频对话的技术方案。从前端技术开发的视角来看，是一组可调用的API标准。

👉52im社区本周新文：《哔哩哔哩从0到1自研智能客服IM系统的技术实践之路 http://www.52im.net/thread-4517-1-1.html》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第23 期。

[- 1 -] 理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）

[链接] http://www.52im.net/thread-283-1-1.html

[摘要] 本文将以理论联系实际的方式，详细讲解一套典型IM的通信协议设计的方方面面。

[- 2 -] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解

[链接] http://www.52im.net/thread-310-1-1.html

[摘要] 通信安全是互联网应用首要考虑的问题，有别于传统PC应用，随着移动互联网时代的到来，移动端的通信安全性要同时权衡：安全、性能、体验、数据流量等等方面，要实现一个完整而实用的通信安全解决方案并非易事。本文将详细介绍基于TLS 1.3的微信新一代通信安全协议mmtls。

[- 3 -] 来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享

[链接] http://www.52im.net/thread-215-1-1.html

[摘要] OpenIM是阿里巴巴推出的，集成于阿里百川项目中的移动端IM开放服务。阿里百川是阿里巴巴集团无线开放平台，为移动开发者（涵盖移动创业者）提供快速搭建APP、加速APP商业化、提升用户体验的解决方案。

[- 4 -]简述实时音视频聊天中端到端加密

[链接] http://www.52im.net/thread-763-1-1.html

[摘要] 本文着重阐述端到端加密(E2EE)，端到端加密是确保数据传输安全的可行方法之一。读完这篇文章，你可以了解这种加密方式的基本原理.

[- 5 -] 移动端安全通信的利器——端到端加密（E2EE）技术详解

[链接] http://www.52im.net/thread-764-1-1.html

[摘要] 端到端加密允许数据在从源点到终点的传输过程中始终以密文形式存在。采用端到端加密（又称脱线加密或包加密）时消息在被传输时到达终点之前不进行解密，因为消息在整个传输过程中均受到保护，所以即使有节点被损坏也不会使消息泄露。

[- 6 -] Web端即时通讯安全：跨站点WebSocket劫持漏洞详解(含示例代码)

[链接] http://www.52im.net/thread-793-1-1.html

[摘要] 本文将深入浅出为读者介绍跨站点 WebSocket 漏洞的原理、检测方法和修复方法，希望能帮助广大读者在实际工作中避免这个已知安全漏洞。

[- 7 -] 通俗易懂：一篇掌握即时通讯的消息传输安全原理

[链接] http://www.52im.net/thread-970-1-1.html

[摘要] 本文将通过通俗易懂的文字，引导你一步步理解为何一个即时通讯应用需要加密技术，以及需要何种方式的加密技术等，希望能为您的IM或消息推送服务的设计提供一些参考。

[- 8 -]  IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token

[链接] http://www.52im.net/thread-1525-1-1.html

[摘要] 本文讨论的使用Http短连接的话题可能并不适用于微信这样的IM，因为微信的短连接并非使用Http标准协议实现，而是基于自研的Mars网络层框架再造了一套短连接机制，从而更适用于IM这种场景（更低延迟、更省流量、更好的弱网适应算法等）

[- 9 -] 快速读懂量子通信、量子加密技术

[链接] http://www.52im.net/thread-1604-1-1.html

[摘要] 量子通信技术是个很高端的话题，对于搞IM、推送、网络通信的程序员来说，这到底是个什么鬼？所以我们一起来了解一下！

[- 10 -] 即时通讯安全篇（七）：如果这样来理解HTTPS原理，一篇就够了

[链接] http://www.52im.net/thread-1890-1-1.html

[摘要] 本文将尝试用通俗易懂的语言，一步步还原HTTPS的设计过程，以便您能轻松理解为什么HTTPS最终会是这副模样。

[- 11 -] 一分钟理解 HTTPS 到底解决了什么问题

[链接] http://www.52im.net/thread-2027-1-1.html

[摘要] 本文只做简单的描述，力求简单明了的阐明主要内容，因为HTTPS 体系非常复杂，这么短的文字是无法做到很详细和精准的分析。想要详细了解HTTPS的方方面面，可以阅读此前即时通讯网整理的《即时通讯安全篇（七）：如果这样来理解HTTPS，一篇就够了》一文。

[- 12 -] 一篇读懂HTTPS：加密原理、安全逻辑、数字证书等

[链接] http://www.52im.net/thread-2446-1-1.html

[摘要] HTTPS（全称：Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。本文，就来深入介绍下其原理。

[- 13 -] 基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等

[链接] http://www.52im.net/thread-4104-1-1.html

[摘要] 本文正好借此机会，以Netty编写的IM聊天加密为例，为入门者理清什么是PKI体系、什么是SSL、什么是OpenSSL、以及各类证书和它们间的关系等，并在文末附上简短的Netty代码实示例，希望能助你通俗易懂地快速理解这些知识和概念！

[- 14 -] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

[链接] http://www.52im.net/thread-4142-1-1.html

[摘要] 本文要分享的是如何使用OpenSSL生成在基于Netty的IM中真正可用的SSL/TLS证书，内容包括：证书的创建、创建过程中的注意点，以及在Server端、Android端、iOS端、Java桌面端、H5端使用证书的代码范例。

[- 15 -] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

[链接] http://www.52im.net/thread-4374-1-1.html

[摘要] 本文将介绍微信的安全数据特征仓库的背景起源、技术演进、当前的架构设计和实践，以及数据质量保证系统的实现。希望给中大型IM系统的安全数据特征仓库的设计带来启发。

👉52im社区本周新文：《微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由小红书基础架构存储组空洞和刘备分享，原题“小红书如何应对万亿级社交网络关系挑战？图存储系统 REDtao 来了！”，本文有修订和改动。

1、引言

小红书是一个社区属性为主的产品，它涵盖了各个领域的生活社区，并存储海量的社交网络关系。

为了解决社交场景下超大规模数据的更新与关联读取问题，并减少数据库压力和成本，我们自研了面向超大规模社交网络的图存储系统 REDtao，大大提高了系统稳定性。该系统借鉴了 Facebook 的图存储系统设计，将缓存和底层数据库封装起来，并对外提供统一的图查询 API，实现了访问收敛，同时在缓存中实现了高效的边聚合。

本文将为你分享小红书面向超大规模社交网络的图存储系统REDtao的架构设计与技术实践过程，希望能带给你启发。

2、关于作者

空洞：小红书基础架构存储组，负责图存储系统 REDtao 和分布式缓存的研发。

刘备：小红书基础架构存储组负责人，负责REDkv / REDtao / REDtable / REDgraph 的整体架构和技术演进。

基础架构存储组是给小红书的业务部门提供稳定可靠的存储和数据库服务，满足业务对存储产品的功能、性能、成本和稳定性要求。目前负责自研分布式 KV、分布式缓存、图存储系统、图数据库和表格存储。

已上线的存储产品包括：

• 1）REDkv : 分布式高性能 KV；
• 2）REDtao ：满足一跳查询的高性能图存储数据库；
• 3） REDtable ：提供 Schema 语义和二级索引的表格存储；
• 4） REDgraph ：提供两跳及以上的图语义查询数据库。

3、技术背景

小红书是以年轻人为主的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。

在小红书的社交领域里，我们有用户、笔记、商品等实体，这些实体之间有各种各样的关系。

例如：用户与笔记之间可能存在“拥有”（发布）、“点赞”、“收藏”等三种关系，同时还存在对应的反向关系“被点赞”，“被收藏”等。

小红书的社交图谱数据已经达到了万亿条边的规模，且增长速度非常快。当用户登陆小红书时，每个用户都会看到关注的好友、粉丝、点赞、收藏以及其他为其量身定做的内容。

这些信息高度个性化，需要实时从这些海量社交关系数据中读取用户相关信息。这是一个读为主的过程，读取压力非常大。

过去，我们将这些社交图谱数据都存储在运维成熟的 MySQL 数据库中。

然而，即使我们只有百万请求每秒的规模，MySQL 的 CPU 使用率仍然到达了 55% 。随着用户和 DAU 爆发式的增长，需要不断扩容 MySQL 数据库，这带来了巨大的成本和稳定性压力。

为了解决这些问题且考虑到没有合适的开源方案，2021 年初我们开启了从 0 到 1 自研 REDtao 的历程。

4、方案调研和API设计

4.1方案调研

我们充分调研了业内其他厂商的实现，发现有着强社交属性的公司基本上都有一个自研的图存储系统（如下图所示）。

比如：

• 1）Facebook 实现了一个叫做 “TAO” 专门的分布式社交图谱数据库，并将其作为最核心的存储系统；
• 2）Pinterest 和 Facebook 类似，也实现了类似的图存储系统；
• 3）字节跳动自研了 ByteGraph 并将其用于存储核心的社交图谱数据；
• 4）Linkedln 在 KV 之上构建了社交图谱服务。

考虑到当时我们的社交图谱数据已经存放在 MySQL 数据库上且规模巨大，而社交图谱数据服务是非常重要的服务，对稳定性的要求非常高。回溯 Facebook 当年遇到的问题和我们类似，数据存储在 Memcache 和 MySQL 中。因此，参考 Facebook 的 Tao 图存储系统更贴合我们的实际情况和已有的技术架构，风险更小。

4.2API设计

社交图谱的访问主要是边的关系查询。

我们的图模型将关系表示为一个 <key, value> 对，其中 key 是 ( FromId,  AssocType,  ToId ) 的三元组，value 是属性的  JSON 格式。

比如“用户 A ”关注“用户 B ”，映射到 REDtao 的数据存储结构为：

1<FromId:用户A的ID, AssocType：关注， ToId：用户B的ID>  ->  Value （属性的json字段）

我们对业务方的需求进行分析，封装了 25 个图语义的 API 给业务方使用，满足了其增删改查的需求，并收敛业务方的使用方式。

相比于 Facebook 的 Tao，我们还补充了社交图谱所需要的图语义，为反作弊场景提供了额外的过滤参数。

同时，在缓存层面，我们支持对不同的字段在缓存中配置局部二级索引。

下面给一些典型的使用场景。

1）场景一：获取关注了 A 的所有正常用户（并且剔除作弊用户）：

1getAssocs(“被关注类型”, 用户A的ID, 分页偏移量, 最大返回值, 只返回正常用户，是否按照时间从新到旧)

2）场景二：获取 A 的粉丝个数（并且剔除作弊用户）：

1getAssocCount(“被关注类型”, 用户A的ID, 只返回正常用户)

5、整体架构设计

REDtao 的架构设计考虑了下面这几个关键的要素：

整体架构分为三层：

• 1）接入层；
• 2）缓存层；
• 3）持久层。

业务方通过 REDtao SDK 接入服务。

如下图：

在这个架构中：和 Facebook Tao 不一样的是，我们的缓存层是一个独立的分布式集群，和下面的持久层是解耦的。缓存层和下面的持久层可以独立的扩容缩容，缓存分片和 MySQL 分片不需要一一对应，这样带来了更好的灵活性，MySQL 集群也变成了一个可以插拔替换的持久存储。

1）读流程：客户端将读请求发送给 router，router 接收到 RPC 请求后，根据边类型选择对应的 REDtao 集群，根据三元组 ( FromId,  AssocType,  ToId ) 通过一致性 Hash 计算出分片所在的 Follower 节点，将请求转发到该节点上。Follower 节点接收到该请求，首先查询本地的图缓存，如果命中则直接返回结果。如果没有命中，则将请求转发给 Leader 节点。同样的，Leader 节点如果命中则返回，如果不命中则查询底层 MySQL 数据库。

2）写流程：客户端将写请求发送给 router，和读流程一样，会转发到对应的 Follower 节点上。Follower 节点会转发写请求给 Leader 节点，Leader 节点转发给 MySQL，当 MySQL 返回写入成功后，Leader 会清除本地图缓存对应的 Key，并同步给其他所有 Follower 清除掉该 Key，保证数据的最终一致性。

6、高可用设计

REDtao 分为独立的两层：缓存层和持久层。每一层都保证高可用性。

1）自研的分布式缓存：

我们自研了实现图语义的分布式 cache 集群，支持故障自动检测和恢复、水平扩缩容。

它是一个双层 cache，每个分片都有一个 Leader 和若干个 Follower。所有的请求都先发给外层的 Follower，再由 Follower 转发给 Leader。这样的好处是读压力大的时候只需要水平扩展 Follower，单点 Leader 写入的方式也降低了复杂度，更容易实现数据的一致性。

如果一个副本故障，系统会在秒级别内进行切换。当持久层发生故障时，分布式缓存层仍然可以对外提供读取服务。

2）高可用的MySQL集群：

MySQL 集群通过自研的中间件实现了分库分表方案，并支持 MySQL 的水平扩容。每个 MySQL 数据库有若干从库，并且与公司内部其他的 MySQL 运维方案一致，保证高可用性。

3）限流保护功能：

为防止缓存击穿导致 MySQL 突发大量请求，从而导致 MySQL 宕机，我们通过限制每个主节点最大 MySQL 并发请求数来实现限流保护 MySQL。达到最大并发请求限制之后的请求会被挂起等待，直到已有请求被处理返回，或者达到等待超时请求被拒绝不会被继续请求到 MySQL 。限流阈值在线可调，根据 MySQL 集群规模调整对应限制。

为防止爬虫或者作弊用户频繁刷同一条数据，我们利用 REDtaoQueue 顺序执行对写入或者点查同一条边的请求，队列长度会被限制，控制同一时间大量相同的请求执行。相比于单个全局的队列控制所有请求的方式，基于每个请求的队列可以很好地限制单个同一请求，而不影响其他正常请求。

7、高性能设计

数据结构的设计是 REDtao 高性能的重要保证。

我们采用了三层嵌套 HashTable 的设计, 通过根据某个起点 from_id 从第一级 HashTable 中查找到 REDtaoGraph，记录了所有 type 下对应的所有的出边信息。

接着，在第二级 HashTable 中，根据某个 type_id 查找到 AssocType 对应某个 type 下边所有出边的计数、索引以及其他元数据。

最终在最后一级 HashTable ，通过 AssocType 的某个 to_id 查找到最终边信息。

我们记录了创建时间、更新时间、版本、数据以及 REDtaoQueue，time_index 则对应根据创建时间排序列表。

最后一级 HashTable 以及索引限制存储最新的 1000 个边信息，以限制超级点占据过多内存，同时集中提高最新热数据的查询命中率以及效率。REDtaoQueue 用于排队当前某个关系的读写，只记录了当前最后一个请求的元数据。

每次查询或写入时，首先查询 REDtaoAssoc：

• 1）若缓存不存在，则会首先创建只包含 REDtaoQueue 的对象；
• 2）若缓存已存在，则会更新队列元数据，将自己设置为队列的最后一个请求，并挂起等待被执行。

通过这种多层 hash+ 跳表的设计，我们能高效地组织点、边、索引、时间序链表之间的关系。内存的申请、释放在同一个线程上完成。

在线上环境中，我们的系统可以在一台 16 核的云厂商虚拟机上跑到 150w 查询请求/s，同时 CPU 利用率仅有 22.5% 。下方是线上集群的一个监控图，单机的 QPS 到达 3w ，每个 RPC 请求聚合了 50 个查询。

8、易用性设计

1）丰富的图语义 API ：

我们在 REDtao 中封装了 25 个图语义的 API 给业务方使用，满足了业务方的增删改查的需求。业务方无需自行编写 SQL 语句即可实现相应操作，使用方式更加简单和收敛。

2）统一的访问 URL ：

由于社区后端数据太大，我们按照不同的服务和优先级拆分成了几个 REDtao 集群。

为了让业务方不感知后端的集群拆分逻辑，我们实现了统一的接入层。

不同的业务方只需使用同一个服务 URL ，通过 SDK 将请求发送到接入层。接入层会接收到不同业务方的图语义的请求，并根据边的类型路由到不同的 REDtao 集群。它通过订阅配置中心，能够实时感知到边的路由关系，从而实现统一的访问 URL，方便业务方使用。

9、数据一致性设计

作为社交图谱数据，数据的一致性至关重要。我们需要严格保证数据的最终一致性以及一定场景下的强一致性。为此，我们采取了以下措施：

1）缓存更新冲突的解决：

REDtao 为每个写入请求生成一个全局递增的唯一版本号。在使用 MySQL 数据更新本地缓存时，需要比较版本号，如果版本号比缓存的数据版本低，则会拒绝此更新请求，以避免冲突。

2）写后读的一致性：

Proxy 会将同一个 fromId 的点或边请求路由到同一个读 cache 节点上，以保证读取数据一致性。

3）主节点异常场景：

Leader 节点收到更新请求后，会将更新请求变为 invalidate cache 请求异步的发送给其他 follower，以保证 follower 上的数据最终一致。在异常情况下，如果 Leader 发送的队列已满导致 invalidate cache 请求丢失，那么会将其他的 follower cache 全部清除掉。

如果 Leader 故障，新选举的 Leader 也会通知其他 follower 将 cache 清除。

此外，Leader 会对访问 MySQL 的请求进行限流，从而保证即使个别分片的cache被清除掉也不会将 MySQL 打崩。

4）少量强一致的请求：

由于 MySQL 的从库也提供读服务，对于少量要求强一致的读请求，客户端可以将请求染上特殊标志，REDtao 会透传该标志，数据库 Proxy 层会根据该标志将读请求转发到 MySQL 主库上，从而保证数据的强一致。

10、 跨云多活设计

跨云多活是公司的重要战略，也是 REDtao 支持的一个重要特性。

REDtao 的跨云多活架构整体如下：

这里不同于 Facebook Tao 的跨云多活实现，Facebook Tao 的跨云多活实现如下图所示。

Facebook 的方案依赖于底层的 MySQL 的主从复制都通过 DTS Replication 来做。而 MySQL 原生的主从复制是自身功能，DTS 服务并不包含 MySQL 的主从复制。该方案需要对 MySQL 和 DTS 做一定的改造。前面说到，我们的缓存和持久层是解藕的，在架构上不一样。

因此，REDtao 的跨云多活架构是我们结合自身场景下的设计，它在不改动现有 MySQL 功能的前提下实现了跨云多活功能。

1）持久层我们通过 MySQL 原生的主从 binlog 同步将数据复制到其他云的从库上。其他云上的写请求和少量要求强一致读将被转发到主库上。正常的读请求将读取本区的 MySQL 数据库，满足读请求对时延的要求。

2）缓存层的数据一致性是通过 MySQL DTS 订阅服务实现的，将 binlog 转换为 invalidate cache 请求，以清理掉本区 REDtao cache 层的 stale 数据。由于读请求会随机读取本区的任何一个 MySQL 数据库，因此 DTS 订阅使用了一个延迟订阅的功能，保证从 binlog 同步最慢的节点中读取日志，避免 DTS 的 invalidate cache 请求和本区 read cache miss 的请求发生冲突从而导致数据不一致。

11、云原生实现

REDtao 的云原生特性重点体现在弹性伸缩、支持多 AZ 和 Region 数据分布、产品可以实现在不同的云厂商间迁移等几个方面。REDtao 在设计之初就考虑到支持弹性扩缩容、故障自动检测及恢复。

随着 Kubernetes 云原生技术越来越成熟，我们也在思考如何利用 k8s 的能力将部署和虚拟机解绑，进一步云原生化，方便在不同的云厂商之间部署和迁移。

REDtao 实现了一个运行在 Kubernetes 集群上的 Operator，以实现更快的部署、扩容和坏机替换。

为了让 k8s 能感知集群分片的分配并且控制同一分片下的 Pods 调度在不同宿主机上，集群分组分片分配由 k8s Operator 渲染并控制创建 DuplicateSet （小红书自研 k8s 资源对象）。

REDtao 则会创建主从并根据 Operator 渲染出来的分片信息创建集群，单个 Pod 故障重启会重新加入集群，无需重新创建整个集群。集群升级时，Operator 通过感知主从分配控制先从后主的顺序，按照分片分配的顺序滚动升级以减少升级期间线上影响。

12、老服务的平滑升级实践

但凡变革，皆属不易。实现全新的 REDtao 只是完成了相对容易的那部分工作。

小红书的社交图谱数据服务已经在 MySQL 上运行多年，有很多不同的业务跑在上面，任何小的问题都会影响到小红书的在线用户。因此，如何保证不停服的情况下让现有业务无感知地迁移到 REDtao 上成为一个非常大的挑战。

我们的迁移工作关键有两点：

1）将老的大 MySQL 集群按优先级拆分成了四个 REDtao 集群。这样，我们可以先将优先级最低的服务迁移到一个 REDtao 集群，充分灰度后再迁移高优先级的集群；

2）专门开发了一个 Tao Proxy SDK，支持对原来的 MySQL 集群和 REDtao 集群进行双写双读，数据校验比对。

迁移时：我们首先将低优先级的数据从 MySQL 通过 DTS 服务迁移到了一个 REDtao 集群，并升级好业务方的 SDK 。DTS 服务一直对增量数据进行同步。业务方 SDK 会订阅配置中心的配置变更，我们修改配置让 Tao Proxy SDK 同时读写 MySQL 集群和 REDtao 集群，并关闭 DTS 服务。此时会使用 MySQL 集群的结果返回给用户。

在停止 DTS 服务时：有可能会有新的 MySQL 数据通过 DTS 同步过来，造成了 REDtao 集群新写的数据被同步过来的老数据覆盖。因此，在关闭 DTS 服务后，我们会通过工具读取开双写之后到关闭 DTS 服务这个时间段的 binlog 对数据进行校验和修复。

修复完成之后：Tao Proxy SDK 的双读会展示两边不一致的数据量，并过滤掉因为双写时延不一致导致数据不一致的请求。灰度一段时间后观察到 diff 的数目基本为 0，将 Tao Proxy SDK 的配置改为只读写新的 REDtao 集群。

最终：我们在 22 年初完成小红书所有核心社交图谱万亿边级别数据的迁移和正确性校验，并做到了整个迁移服务无感知，迁移过程没有发生一起故障。

13、新图存储系统带来的结果和收益

我们的社交图谱数据访问中，90% 以上的请求都是读请求，并且社交图谱的数据有非常强的时间局部性（即最近更新的数据最容易被访问）。REDtao 上线后，获得 90% 以上的 cache 命中率， 对MySQL 的 QPS 降低了 70%+ ，大大降低了 MySQL 的 CPU 使用率。在缩容 MySQL 的副本数目后，整体成本降低了21.3%。‍

业务的访问方式都全部收敛到 REDtao 提供的 API 接口上，在迁移过程中，我们还治理了一些老的不合理访问 MySQL 数据库的方式，以及自定义某些字段赋予特殊含义的不合理做法，通过 REDtao 规范了数据访问。

对比 2022 年初和 2023 年初，随着 DAU 的增长，社交图谱的请求增长了 250% 以上，如果是之前 MySQL 的老架构，扩容资源基本上和请求增长速度成正比，至少需要扩容 1 倍的资源成本（数万核）。

而得益于 REDtao 系统的存在，因其 90% 的缓存命中率，实际上整体成本只增加了 14.7%（数千核）就能扛下 2.5 倍的请求增长。在成本和稳定性上有了较大的提升。

14、未来展望

在较短的时间，我们自研了图存储系统 REDtao ，解决了社交图谱关系数据快速增长的问题。

REDtao 借鉴了 FaceBook Tao 的论文，并对整体架构、跨云多活做了较多的改进，全新实现了一个高性能的分布式图缓存，更加贴合我们自身的业务特点和提供了更好的弹性。同时，利用 k8s 能力进一步实现了云原生化。

随着 DAU 的持续增长，万亿的数据规模也在继续增长，我们也面临着更多的技术挑战。

目前公司内部的 OLTP 图场景主要分为三块：

1）社交图谱数据服务：通过自研图存储系统 REDtao 满足了社交场景超大规模数据的更新与关联读取问题。目前已经存储了万亿规模的关系；

2）风控场景：通过自研图数据库 REDgraph，满足多跳的实时在线查询。目前存储了千亿点和边的关系，满足 2 跳以及 2 跳以上的查询；

3）社交推荐：这块主要是两跳的查询。每天通过 Hive 批量地导入全量的数据，通过 DTS 服务近实时的写入更新数据。因为是在线场景，对时延的要求非常高，当前的 REDgraph 还无法满足这么高的要求，因此业务方主要是用 REDkv 来存储。

针对以上场景：为了快速满足业务需求，我们使用了三套不同的自研存储系统：REDtao 、REDgraph 和 REDkv 。

显然相对于 3 套存储系统，用一个统一的架构和系统去解决这几个图相关的场景是更加合适的。

未来：我们会将 REDgraph 和 REDtao 融合成一个统一的数据库产品，打造业内顶尖的图技术，对公司内部更多的场景进行赋能。