1、引言

编者注：本文虽不是专门的全文检索技术文章，但文中涉及到的字词匹配算法等等都是一脉相承，所以也同样收录到了“IM全文检索技术”技术专题中，希望能给你启发。

谛听系统是vivo的内容审核平台，保障了vivo各互联网产品持续健康的发展。谛听支持审核多种内容类型，但日常主要审核的内容是文本，下图是一个完整的文本审核流程，包括名单匹配、敏感词匹配、AI机器审核、人工审核四个环节。待审核文本需要顺次通过名单匹配、敏感词匹配、AI机器审核三个流程，若结果为嫌疑则需要人工审核，否则将直接给出确定的结果。

敏感词匹配功能可以迅速地匹配文本中的敏感词汇，算法平均耗时为50ms，因其简单、快速、直接、灵活的特点，成为了审核人员对抗垃圾文本的利器。然而身处信息爆炸时代的网民们非常“优秀”，他们源源不断的发明各种新词、谐音词来绕过敏感词检测。例如某些用户会使用“啋票”、“采漂”等词汇来规避敏感词“彩票”，其中“啋票”不仅是谐音词，还包含多音字，常规的模式匹配算法很难保证完全命中。这不仅给运营规则带来挑战，也对匹配算法的精准度、漏杀率提出了要求。

本文将从算法选型入手，结合两个实际场景来介绍谛听系统的敏感词匹配算法。包括底层算法选型思路和两种实际场景下提升敏感词精准度、降低漏杀率的方案。

2、系列文章

本文是专题系列文章中的第5 篇：

1. 《IM全文检索技术(一)：微信移动端的全文检索优化之路》
2. 《IM全文检索技术(二)：微信移动端的全文检索多音字问题解决方案》
3. 《IM全文检索技术(三)：网易云信Web端IM的聊天消息全文检索技术实践》
4. 《IM全文检索技术(四)：微信iOS端的最新全文检索技术优化实践》
5. 《IM全文检索技术(五)：vivo敏感词匹配系统的技术实践》（* 本文）

3、敏感词匹配算法选型

敏感词匹配功能依托于模式匹配算法。模式匹配的定义是，给定一个子串，在某个字符串中找出与该子串相同的所有子串。其中给定的子串被称为模式串，被匹配的字符串被称为目标串。基于多个模式串进行匹配的算法被称为多模式匹配算法，目前成熟的多模式匹配算法有AC自动机和WM。

3.1 多模式匹配算法对比

谛听的敏感词匹配业务有如下特点：

• 1）词库量大，需要维护和加载百万级别的词库（模式串）；
• 2）敏感词与业务特性、国家政策相关性强，无法统一约定长度、前缀等特征。

WM算法对模式串的长度和前缀存在一定的要求，可能会影响业务的使用。虽然AC自动机加载耗时长，内存占用大，但敏感词加载并不频繁，且服务器内存资源充足，所以我们最终选用AC自动机作为底层算法。

3.2 AC自动机算法介绍

AC自动机算法（Aho–Corasick算法）是一种字符串搜索算法，可以同时将目标串与所有模式串进行匹配，算法均摊情况下具有近似于线性的时间复杂度。

AC自动机的匹配原理有两个核心概念：Trie字典树、Fail指针。下面以模式串集合{“she”, “he”, “shers”, “his”, “era”}为例，来介绍这两个概念。

AC自动机算法启动时，需要将所有的模式串加载到内存中，构建成一个Trie字典树。

例如下图是以模式串集合{“she”, “he”, “shers”, “his”, “era”}构建的字典树，树中每个节点代表一个字符，从根节点到某一个节点的路径，即可表示一个模式串，且红色节点表示一个字符串的终结，例如图中最右边子树上的三个节点，可代表模式串“era”。从字典树的根节点出发，可以快速的查找到某个模式串。

此外，拥有相同前缀的模式串会合并到同一个子树中，例如中间子树表示模式串“he”、 “his”，这两个字符串分别是“h”节点的一个分支。AC自动机在搜索这类字符串时，可以节省匹配的次数。

AC自动机在Trie树的基础上，为每个节点加入了Fail指针，上图使用虚线画出了部分节点的Fail指针，未画出虚线的节点，其Fail指针指向根节点。算法在某个节点匹配失败时，可以通过该指针转移到其他包含相同前缀的分支上继续匹配。例如匹配目标串“shis”时，对于前两个字符“sh”，Trie字典树匹配到左边字数的“h”节点上，由于该节点的子节点是字符“e”，与目标串的下一个字符“i”不匹配，因此算法通过Fail指针转移到中间子树的“h”节点上继续匹配，最终命中字符串“his”。

上述的Trie字典树与Fail指针组成了AC自动机的数据模型。AC自动机匹配目标串时，会按顺序从目标串中取出字符，从Trie字典树的根节点出发，在子结点中寻找与该字符匹配的结点，若能找到，则转移到该节点，若找不到，则转移到Fail指针指向的节点。当状态转移到图中的红色节点时，就是命中了一个模式串。下图展示了AC自动机对目标串“merashisnx”进行匹配的过程。

4、vivo的谛听系统

谛听系统基于AC自动机算法构建了一套敏感词匹配服务，将敏感词作为模式串，文本内容作为目标串，可以实现常用的中、英文敏感词匹配。但是实际的业务有很多细分的场景，普通的AC自动机算法已不能满足业务使用需求，因此我们探索了组合敏感词匹配和拼音敏感词匹配两种匹配方式，下面分别介绍。

5、技术实践1：组合敏感词

常规的敏感词匹配算法通常匹配单个词或者短句，但某些词单独出现时并不违规，只有在与几个特定的词同时出现时，才能判定为违规。

组合敏感词的匹配算法依然基于AC自动机算法。由于AC自动机只能判断单个词的命中情况，因此我们将组合敏感词分割成单个敏感词，并维护各敏感词与组合间的映射关系，在AC自动机算法运行结束后，只有某个组合对应的敏感词全部命中时，才能判断该组合敏感词命中。

为此我们需要给AC自动机添加一些前置和后置的处理步骤，具体步骤如下：

• 1）将组合敏感词分割为单个敏感词，并记录敏感词与组合的映射关系；
• 2）将分割后的组合敏感词添加到AC自动机的Tire树中；
• 3）运行AC自动机，匹配文本；
• 4）遍历匹配结果，将匹配的结果根据映射关系映射到相应的组合上；
• 5）记录组合的命中情况，得到最终匹配结果。

在步骤4中，算法将匹配的词映射到组合中，并标记对应的词命中。步骤5会根据各组合中单词的命中情况，来判断该组合是否命中，由于在步骤4中组合敏感词均被标记为命中，因此可判断该组合命中。

6、技术实践2：拼音敏感词

6.1 概述

在评论、弹幕等创作自由度很高的场景中，某些用户为了规避机器审核，会使用一些多音字、同音字来表达敏感词汇，例如用“啋票”来代表“彩票”等。

由于多音字、同音字变化较多，将一个词的所有谐音词都穷举出来是很困难的。因此我们实现了拼音敏感词的匹配方案，将中文文本转换为拼音再匹配，通过读音匹配敏感词，即可保证命中所有的同音字，运营直接配置敏感词的拼音，例如“CAI PIAO”，即可命中“啋票”、“彩票”、“采漂”等词汇。

6.2 匹配流程

常规的AC自动机算法是逐字符匹配的，因此Trie树上每个节点存储一个字符，但拼音敏感词需要按照音节匹配，因此我们将Trie树的节点数据类型由char改为String。

示例如下：

拼音敏感词的匹配关键在于将汉字准确的转换为拼音，这一点在多音字的场景下尤为重要。由于多音字的读音是受语境影响的，现有的技术条件很难确保能将多音字准确的转换为拼音，而上文提到同音词“啋票”是用户自行造的词，算法无法准确的识别语境，可能转换得到“CAI PIAO”、“XIAO PIAO”两种不同的结果。如果拼音转换不精准，则拼音敏感词也无法准确命中。

因此我们不依赖算法识别多音字的读音，而是将文本内容的所有读音都列出来匹配一遍，就可以避免避免拼音转换不精准的问题。

下图展示了文本内容与拼音的对应关系，由于存在多音字，因此存储拼音的数组从一维扩展到了二维，更像是“图”的数据结构，下文将其称为拼音图。拼音图的起始节点和终止节点之间存在多条路径，这些路径对应了多音字的所有排列组合情况，为了避免漏杀，我们需要使用AC自动机将这些路径都匹配一遍。

从第二节的匹配流程可以看出，目标串是一维数组，因此AC自动机在匹配文本时，通常采用顺序遍历的方式。而在拼音敏感词中，由于目标串采用二维数组存储，是一种类似于“图”的数据结构，不再适合使用顺序遍历的方式，因此需要采用图的遍历算法。

图的遍历算法中，最常用的就是深度优先遍历（DFS）和广度优先遍历（BFS）。由于词语是前后关联的，为了使算法更符合人类思考习惯，我们选择了DFS。DFS算法使用栈存储节点信息，在当前分支遍历完成后，通过栈中的信息回溯到上一个分支处继续遍历。由于Trie树的状态位与拼音图的节点是相关的，在DFS回溯时，Trie树也需要同步回溯，因此需要将Trie树状态位与拼音图的节点信息一起保存到DFS栈中。

下图展示了拼音敏感词的匹配流程：

 

6.3 终止条件与剪枝策略

DFS的终止条件是当所有节点都被遍历过，且算法会确保每个节点只会被遍历一次。但是DFS遍历时会在分支处回溯，所以往往终止的节点并不是待匹配文本的终点，很有可能AC自动机的匹配并未完成。

例如在下图所示的匹配流程中，左图是基于待匹配文本“朱朝阳和朋友”构建的拼音图，右图是基于拼音敏感词“PENG YOU”、“ZHAO YANG”、“NI MA”、“MA DE”构建的Trie树。左图的拼音图采用DFS算法遍历，算法最后访问的节点是蓝色节点“ZHAO”，此时拼音图中所有节点均被遍历了一次，已经达到了DFS的终止条件。但右图中Trie树上的状态位处于蓝色节点“ZHAO”的位置，并没有达到终止状态，若此时停止匹配，则会导致无法命中敏感词“ZHAO YANG”，故算法应继续运行，直到AC自动机匹配失败为止。

因此合适的终止条件是：拼音图所有节点均被遍历 且 AC自动机匹配失败。

由于算法需要结合DFS和AC自动机的状态来判断终止条件，因此会出现拼音图中一个节点和路径被遍历多次的情况，当待匹配文本中多音字数量增多时，DFS遍历的路径数量会以笛卡尔积的形式增加。

而这些路径中会存在一部分重复的情况，因此在遍历的过程中需要采取合适的剪枝策略，避免搜索一些重复的路径。

例如下面左图所示的遍历情况，路径②上“PENG”、“ YOU”两个节点已被路径①遍历过，且对应的AC自动机状态位（参考右图）前缀并不包含当前遍历节点“HU”，所以“PENG”对应的敏感词与路径②无关，不必再搜索一次。

我们可以针对这种场景设计了剪枝策略，需要剪枝的路径需要满足两个条件：

• 1）首先当前节点的下一节点已被遍历过；
• 2）下一节点对应的AC自动机状态与当前节点无关。

我们为拼音图中的每个节点标记一个分支路径长度B，表示当前节点与上一个最近的分支节点间的路径长度，例如节点“PENG”对应的分支路径长度为B = 2（从“HU”到“PENG”），节点“YOU”的分支路径长度为B = 3（“HU”、“PENG”、“YOU”）。

在AC自动机的状态机中，记录Trie树上每个节点的深度D。例如状态机中“PENG”节点的深度D=1，“YOU”节点的深度D=2。从Trie树根节点到某一个节点的路径上经过的字符连接起来，为该节点对应的模式串，因此节点的深度D即为模式串的长度。当D < B时，表明当前正在匹配的模式串长度短于拼音图中当前节点的分支路径长度，所以当前的模式串与当前的路径无关。

总结一下，剪枝所需的条件为：

• 1）拼音图中下一节点已被遍历；
• 2）拼音图的分支路径长度B > Trie树节点的深度D。

7、写在最后

谛听系统基于AC自动机实现了普通敏感词、组合敏感词、拼音敏感词的匹配，其中组合敏感词和拼音敏感词还可以结合成为拼音组合敏感词，覆盖了大部分的文本审核场景，减轻了机审、人审的压力。

另外，在政策风向发生变化时，敏感词匹配功能为运营同事提供了一种快速变更审核策略的手段，使谛听的文本审核能力更加灵活。

目前谛听线上已经配置了数量超过100万的敏感词，极大程度的保障了公司的内容安全。

未来我们将结合业务使用场景继续优化敏感词匹配的能力，提升精准度和命中率：

• 1）一方面我们可以采用某种方式实现“非”的逻辑，这样可以在配置敏感词时排除bad case，提升命中的精准度；
• 2）另一方面，我们可以实现敏感词的模糊命中，提升敏感词的命中率。

8、相关资料

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

[2] 新手入门一篇就够：从零开发移动端IM

[3] IM消息ID技术专题(七)：深度解密vivo的自研分布式ID服务(鲁班)

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

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

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

[7] 得物自研移动端弱网诊断工具的技术实践分享

[8] 如何保障分布式IM聊天系统的消息有序性（即消息不乱）

[9] 社交场景下的统一即时通讯im消息流交互层模块化技术实践

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

[11] 得物从0到1自研客服IM系统的技术实践之路

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

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

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

[15] 来看看某信十年前的IM消息收发架构，你做到了吗

[16] 携程技术分享：亿级流量的办公IM及开放平台技术实践

[17] 转转平台IM系统架构设计与实践(一)：整体架构设计

[18] 支持百万人超大群聊的Web端IM架构设计与实践

[19] 转转客服IM聊天系统背后的技术挑战和实践分享

[20] B站IM消息系统的新架构升级实践

[21] 如何保障分布式IM聊天系统的消息有序性（即消息不乱）

[22] 即时通讯IM离线消息该怎么存？全面盘点主流存储方案

即时通讯技术学习：

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

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

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

1、引言

WebSocket 是基于 HTTP/1.1 Upgrade 机制实现的全双工长连接通信协议，广泛应用于 IM即时通讯、实时通知、协同编辑、行情推送、游戏服务等场景。

由于 WebSocket 是长连接 + 状态敏感的协议，在 Nginx 中做反向代理时，需要特别注意一些细节。

这些细节主要是：

• 1）协议升级（Upgrade）；
• 2）连接保持；
• 3）超时控制；
• 4）负载均衡策略；
• 5）云环境 / K8s 场景下的断连问题。

本文从基础配置、生产配置、Docker / K8s、安全、排障、性能调优，系统性讲清 WebSocket 在 Nginx 中的正确打开方式。

2、WebSocket如何建立长连接

WebSocket 通过 HTTP/1.1 完成握手：

GET /ws HTTP/1.1

Upgrade: websocket

Connection: Upgrade

一旦升级成功，连接将不再遵循 HTTP 请求-响应模型，而是长期保持的双向 TCP 通道。

PS：这也是为什么 WebSocket 对 Nginx 超时 / FD / 内核参数 / LB 极度敏感。

更多WebSocket基础资料可以继续阅读：

1. WebSocket从入门到精通，半小时就够！
2. 刨根问底HTTP与WebSocket的关系(上篇)
3. 刨根问底WebSocket与Socket的关系
4. 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE
5. Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？
6. 理论联系实际：从零理解WebSocket的通信原理、协议格式、安全性

3、基础WebSocket反向代理配置

http {

    # 基础 WebSocket 代理配置

    upstream websocket_backend {

        server 192.168.1.100:8080;

        server 192.168.1.101:8080;

        # 支持长连接

        keepalive 10;

    }

 

    server {

        listen 80;

        server_name ws.example.com;

 

        location /ws/ {

            # 核心 WebSocket 配置

            proxy_pass http://websocket_backend;

            proxy_http_version 1.1;

            proxy_set_header Upgrade $http_upgrade;

            proxy_set_header Connection "upgrade";

 

            # 重要：传递原始主机头和客户端 IP

            proxy_set_header Host $host;

            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            proxy_set_header X-Forwarded-Proto $scheme;

 

            # 长连接超时设置

            proxy_read_timeout 3600s;

            proxy_send_timeout 3600s;

            proxy_connect_timeout 30s;

 

            # 禁用缓冲，确保实时性

            proxy_buffering off;

            proxy_cache off;

        }

    }

}

补充说明：

• 1）proxy_http_version 1.1：WebSocket 必须；
• 2）Upgrade / Connection：完成协议升级；
• 3）proxy_buffering off：防止消息延迟；
• 4）proxy_read_timeout：防止 Nginx 主动断连。

4、生产环境必须补充的 Upgrade 头处理（关键）

注意：这是原始配置中最容易踩坑、但极其重要的一点。

推荐写法：

map $http_upgrade $connection_upgrade {

    default upgrade;

    '' close;

}

然后在 location 中：

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection $connection_upgrade;

为什么这样更安全？

• 1）非 WebSocket 请求 → Connection: close；
• 2）WebSocket 请求 → Connection: upgrade。

PS：避免普通 HTTP 请求被错误升级。

5、完整生产级WebSocket配置

http {

    upstream websocket_cluster {

        ip_hash;

 

        server 10.0.1.10:8080 weight=3;

        server 10.0.1.11:8080 weight=2;

        server 10.0.1.12:8080 backup;

 

        # 以下健康检查依赖 nginx_upstream_check_module（非官方）

        check interval=3000 rise=2 fall=3 timeout=1000 type=http;

        check_http_send "GET /health HTTP/1.0\r\n\r\n";

        check_http_expect_alive http_2xx http_3xx;

    }

 

    server {

        listen 443 ssl http2;

        server_name ws.example.com;

 

        ssl_certificate /etc/nginx/ssl/example.com.crt;

        ssl_certificate_key /etc/nginx/ssl/example.com.key;

        ssl_protocols TLSv1.2 TLSv1.3;

 

        location /chat/ {

            proxy_pass http://websocket_cluster;

 

            # WebSocket 升级

            proxy_http_version 1.1;

            proxy_set_header Upgrade $http_upgrade;

            proxy_set_header Connection $connection_upgrade;

 

            # 原始请求信息

            proxy_set_header Host $host;

            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            proxy_set_header X-Forwarded-Proto $scheme;

 

            # ⚠️ 长连接超时

            proxy_read_timeout 86400s;

            proxy_send_timeout 86400s;

 

            # 实时性

            proxy_buffering off;

 

            # 连接限制

            limit_conn ws_conn 1000;

        }

    }

}

limit_conn_zone $binary_remote_addr zone=ws_conn:10m;

6、HTTP/2 与 WebSocket 的现实情况

基本配置：

listen 443 ssl http2;

重要认知：

• 1）浏览器 WebSocket 仍使用 HTTP/1.1；
• 2）HTTP/2 WebSocket（RFC 8441）：浏览器支持有限、Nginx 支持不完整。

PS：这是正常现象，不是配置错误。

WebSocket location 必须显式：

proxy_http_version 1.1;

7、Docker / K8s 场景

map $http_upgrade $connection_upgrade {

    default upgrade;

    '' close;

}

 

server {

    listen 80;

 

    location /ws/ {

        proxy_pass http://websocket-service:8080;

 

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection $connection_upgrade;

 

        proxy_read_timeout 7d;

        proxy_send_timeout 7d;

 

        proxy_buffering off;

    }

}

K8s / 云环境的隐藏断连点：

PS：Nginx 再怎么配都没用，必须应用层心跳

8、WebSocket心跳保活（生产必做）

推荐 20~30 秒一次：

{ "type": "ping" }

否则云 LB、防火墙、NAT，都会主动断你连接。

9、负载均衡策略的选择

upstream websocket_backend {

    ip_hash;

    server 10.0.1.10:8080;

    server 10.0.1.11:8080;

}

实战建议：

PS：WebSocket 本质上 不适合强依赖 LB 算法做会话保持

10、优雅下线与灰度发布（生产增强）

K8s 必配：

terminationGracePeriodSeconds: 60

后端逻辑：

• 1）收到 SIGTERM；
• 2）停止新 WS；
• 3）通知客户端重连；
• 4）平滑下线。

11、Nginx及Linux内核参数（高并发必调）

Nginx配置如下：

worker_processes auto;

worker_rlimit_nofile 200000;

 

events {

    worker_connections 65535;

    use epoll;

}

Linux操作系统的配置：

net.core.somaxconn = 65535

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_fin_timeout = 15

12、写在最后

指令如下：

wscat -c ws://domain/ws

ss -an | grep ESTAB | wc -l

13、参考资料

[1] RFC6455 协议文档、WebSocket API文档、SSE API文档

[2] 新手入门贴：史上最全Web端即时通讯技术原理详解

[3] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE

[4] 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket

[5] 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket

[6] 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE

[7] WebSocket详解（四）：刨根问底HTTP与WebSocket的关系(上篇)

[8] WebSocket详解（六）：刨根问底WebSocket与Socket的关系

[9] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？

[10] WebSocket从入门到精通，半小时就够！

[11] 理论联系实际：从零理解WebSocket的通信原理、协议格式、安全性

[12] 浅谈网页端IM技术及相关测试方法实践（包括WebSocket性能测试）》

[13] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

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

[15] 转转客服IM系统的WebSocket集群架构设计和部署方案

[16] 基于WebSocket的IM即时通信方案在H5游戏场景下的技术实践

[17] 详解AI大模型实时通信为什么选SSE，而不是WebSocket和WebRTC

[18] 都HTML5了，Web端即时通讯技术到底该用什么？一文即懂！

即时通讯技术学习：

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

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

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

1、v2.2.7 版更新内容

• 1）[升级] 提升targetSdkVersion至36，全面兼容Android 16；
• 2）[优化] 开发工程升级适配AGP 9.1最新版；
• 3）[优化] 升级权限框架以适配最新Android 16系统；
• 4）[优化] 针对全部界面适配系统强制的Edge to Edge全面屏特性；
• 5）[优化] 呼叫和聊天界面的ui优化等；

• 音视频框架RainbowAV 的v2.1版已发布！
• 音视频框架RainbowAV 的v2.2版已发布！
• 音视频框架RainbowAV 的v2.2.1版已发布！
• 音视频框架RainbowAV 的v2.2.3版已发布！
• 音视频框架RainbowAV 的v2.2.5版已发布！
• 音视频框架RainbowAV 的v2.2.6版已发布！

2、关于RainbowAV

🔥 RainbowAV是一套完整移动端实时音视频框架，不依赖第3方服务，使用方便，部署简单，轻量级、模块化设计。

📱 客户端历经多年、在大量最终用户的真机使用下，兼容性和适配能力强，它并不是个Demo；

🌟 服务端轻量级、极少依赖、简单易用、3行指令即可部署；

🌟 底层核心为C++编写，性能优先，CPU占用约17%（作为对比，同机型下手机QQ约为20%、微信约为19%）；

🌟 客户端资源占用极少，持续运行时内存仅占 13MB 左右；

🌟 实时视频聊天时上下行总流量约 30KB/S（作为对比，手机QQ和微信的实时音视频均约 60KB/S）；

🌟 实时语音聊天时上下行总流量约 9KB/S（作为对比，手机QQ约 14KB/S、微信约 6KB/S）；

🌟 可应用于3G、4G等弱网络，在跨洲际高延迟网络下做过大量测试。

3、RainbowAV的设计目标

鉴于实时音视频技术的高门槛，RainbowAV技术从设计开始就希望能简化集成和使用，因而是以独立工程的方式进行迭代和演进，并不会与RainbowChat这样的IM发生代码耦合性，从而方便开发者自行改进甚至2次开发。

具体就是：

• 1）与IM工程的解耦：独立工程，方便迭代和演进，甚至2次开发；
• 2）服务端部署便利：服务端编译成了清爽的可执行程序，3行指令即完成部署；
• 3）单实例拆分部署：共编译成3个程序，均可独立部署，互相无依赖，进一步提升单实例性能；
• 4）多实例分布式部署：鉴于实时音视频聊天的特殊性（只在聊天时才需要连接音视频服务器），多实例分布式部署变的简单；
• 5）服务端的高性能：得益于Linux epoll异步编程模型，服务端拥有极高的并发处理性能。
• 6）手机端高兼容性：受益于大量的兼容性测试，甚至在Android 5.0上仍可很好地工作，代码表现健壮；
• 7）手机低资源占用：Android客户端经过大量优化，资源占用低；
• 8）高压缩低码率：经过编码压缩后的音视频数据，只需很少的流量；
• 9）P2P通信支持：尽可能降低服务端性能和带宽压力；
• 10）弱网络的支持：降低弱网络高延迟环境带来的通信脆弱性，保证应用层的稳定运行。

4、RainbowAV的性能指标

客户端性能指标总结：

• 1）客户端运行稳定后，内存占用约13M左右（以MOTO G XT1077手机为例）；
• 2）实时音视频(视频+语音)时，CPU占用约17%（手机QQ的约为20%、微信的约为19%）；
• 3）实时语音(仅语音)时，CPU占用约11%（手机QQ的约为12%、微信的约为5%）；
• 4）实时音视频(视频+语音)时上下行总流量约30KB/S（手机QQ和微信的均约60KB/S）；
• 5）实时语音(仅语音)时上下行总流量约9KB/S（手机QQ的约14KB/S、微信的约6KB/S）.

服务端性能指标总结：

RainbowAV服务端基于高性能的Linux epoll，理论设计性能是：单机1000到10000人同时使用。鉴于实时音视频的复杂性（P2P、中转等混合发生），想要准确地测试统计非常困难。但鉴于实时音视频技术的高流量特性，通常单机瓶颈会首先出现在带宽上，所以生产部署时需要在单机性能和带宽分流上总体考虑。而也正是得益于实时音视频的特殊性，聊天时可同时部署多个服务端实例，只要引导该对聊天的用户同时连接同一台实例即可进行聊天，从而让分布式部署和负载均衡变的简单。

5、关于RainbowChat

🔥⚡️ 详细介绍・版本日志・运行截图(Android、iOS)・下载体验(Android、iOS) ⚡️🔥

RainbowChat是一套基于 RainbowAV 音视频聊天框架 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题。RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP、WebSocket三种通信协议的IM产品。与姊妹产品 RainbowTalk 和 RainbowChat-Web 技术同源，历经考验。

6、运行演示截图

1）RainbowAV独立体验版运行效果：

2）RainbowAV集成到 RainbowChat 的实时语音运行效果：（RainbowChat介绍、更多RainbowChat截图）

3）RainbowAV集成到RainbowChat 后的实时视频运行效果：（RainbowChat介绍、更多RainbowChat截图）

此版本新增了短信验证码的注册和登录功能，解决了Android 16手机上发送文件失败等问题。

详细更新内容（更多历史更新日志）：

• 1）[新增] 新增了短信验证码的注册和登录功能；
• 2）[bug] 解决了Android 16手机上发送文件失败的问题（系统不允许读取DATE_MODIFIED字段）；
• 3）[bug] 解决了群聊中查看群公告时不显示编辑者头像的问题；
• 4）[优化] ui的细节美化和提升（包括图标黑化、标题栏/tab栏白化净化、列表横线净化等等）；
• 5）[优化] 优化了聊天界面中未读消息数的ui；
• 6）[优化] 个人相册、个人语音、文件查看、视频录制和播放、扫一扫等界面的ui优化；
• 7）[优化] 陌生人聊天界面标题栏小字被点击后弹出的提示框中增加了“加好友”按钮；
• 8）[优化] 解决targetSDKVersion=36时，不支持edge to edge全面屏的老旧手机状态栏跟标题栏颜色不一致的问题；
• 9）[优化] 个人中心增加了手机号的显示；
• 10）[优化] 视频播放界面增加视频转发功能；
• 11）[优化] 优化了查看用户头像的缓存加载逻辑；
• 12）[优化] 其它细节优化和提升；

2、关于MobileIMSDK开源工程

工程同步开源地址：

• ❶ GitHub：https://github.com/JackJiang2011/MobileIMSDK
• ❷ 码云gitee： https://gitee.com/jackjiang/MobileIMSDK
• ❸ Gitcode：https://gitcode.com/hellojackjiang2011/MobileIMSDK

仓库文件目录：

框架详细组成：

3、关于RainbowChat

🔥⚡️ 详细介绍・版本日志・运行截图(Android、iOS)・下载体验(Android、iOS) ⚡️🔥

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题。RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP、WebSocket三种通信协议的IM产品。与姊妹产品 RainbowTalk 和 RainbowChat-Web 技术同源，历经考验。

• ☞ 详细介绍：http://www.52im.net/thread-19-1-1.html
• ☞ 版本日志：http://www.52im.net/thread-2735-1-1.html
• ☞ 运行截图：Android端、iOS端
• ☞ 下载体验：App Store安装地址 （另：Android端下载体验 点此查看）

4、运行截图

主要功能运行截图：（☞ Android端完整截图、iOS端完整截图） 

全部功能拼合大图：（☞ 点此查看清晰原图）

5、运行视频

（☞ 新窗口中查看运行视频）

1、引言

本文将为你详解 IM 群聊消息的写扩散技术原理以及写扩散过程中的服务端详细性能成本，同时对比了市面上IM大厂的技术方案，给出分规模架构选型与以及性能优化策略等。

2、技术背景

某天下午，你在一个 1000 人的项目群里发了一条 7 个字的消息：「今晚九点发版」。对你来说，这是一次点击、一段 7 字符的字符串、一次"已发送"的小对勾。

但服务端为这条消息做了什么？

按写扩散（Fan-out on Write）的实现思路，最直观的版本是这样的：

仅消息副本本身就是 999 次扇出。加上路由查询、未读写入、三方推送触发，一条 7 字消息在服务端产生 3000~5000 次后端操作不是夸张。

这就是"写扩散"这个词背后的真实账单。

▲ 群消息的扇出位置（群服务是「1 → N」的关键）

3、群聊消息为什么要做扇出？

群消息这个功能在工程上有两条出路：

中小 toB 项目大多选写扩散，因为 toB 场景里"已读回执 / 消息撤回 / 离线补全"是硬需求 — 没有每成员维度的"投递记录"，这三个功能都立不住。

4、中小规横IM项目的典型设计目标

中小规模 toB IM 项目里，群消息扇出这一层通常要同时满足：

• 1）实时性：在线成员从发送到收到 P95 < 100ms；
• 2）可靠性：离线成员上线后必须能补到这条消息；
• 3）可观测：每个副本的投递状态可追踪（用于 SRE 排障）；
• 4）业务能力：支撑已读回执、消息撤回、漫游、未读统计；
• 5）规模：单群默认 1000 人，少数业务场景 3000~5000 人。

这些约束串起来，几乎一定走向写扩散。

5、写扩散的消息副本生成时机

候选 3 种：

主流选择：群服务展开。

理由是：责任边界清晰 — 群成员、群属性、群配置全在群服务，扇出本来就应该是它的活。

伪代码大致是这样：

on_group_message_arrive(msg):

    group = group_cache.load(msg.group_id)

    members = group.member_list # 1000 人

    members = filter_out_sender(members, msg.from) # 999 人

    for member in members:

        copy = clone_with_target(msg, member.uid)

        copy.uuid = msg.uuid + "|G" + member.short_id // 副本标识

        publish_to_dispatcher(copy)

注意最后那个 uuid + "|G" + member.short_id — 这是写扩散里的"副本指纹"，下游所有组件（历史库、离线、已读聚合）都靠这个区分"原消息"和"副本"。

6、扇出执行方式

这是最容易踩坑的设计点。3 种执行方式的对比：

中小项目早期常见的姿势是异步 MQ 逐条 — 简单、容易实现、文档好查。

但当群规模到 1000 人级别时，MQ 写入次数会成为系统瓶颈：

单条 MQ 写入耗时 ~1~3ms，999 条串行 ≈ 1~3 秒；并行能压到 100ms 内，但 broker 压力大

如果有 100 个千人群同时活跃，MQ broker 每秒要接收 ~10 万条扇出消息

改进方向：MQ 批量化。

把 999 个目标用户分成 20 批，每批 50 人装在一条 MQ 消息里：

on_group_message_arrive(msg):

    members = filter_out_sender(group.member_list, msg.from)

    for batch in chunk(members, batch_size=50): // 50 人一批

        batch_msg = {

            "origin": msg,

            "targets": [m.uid for m in batch]

        }

        publish_to_dispatcher(batch_msg) // 一次 MQ 写

下游分发服务消费时再"展开"批次，对批内每个目标做路由 + 投递。MQ 写次数从 999 降到 ~20，吞吐能力提升一个数量级。

7、副本指纹与双轨存储

写扩散的一个隐蔽问题是：副本要不要进历史库？

该怎么选？

• 1）进：千人群 1 条消息进历史库 999 条，分表空间爆炸
• 2）不进：那历史消息只存原消息，未读 / 已读怎么对账？

主流做法是双轨：

▲ 写扩散的双轨存储：历史库只有 1 条，离线盒子可能有 N 条

判断规则：

历史库消费者扫一眼 uuid 里有没有 |G 就知道丢弃还是入库。这是工程上极简但关键的判断。

8、写扩散场景下的失败处理

写扩散场景下，"完全成功"是个奢侈品。需要承认部分失败常态，设计要点如下。

1）失败必须可重试：副本本身就是 MQ 消息，失败 = 不 ACK，broker 自动重投。

2）重试要有上限：重试 3~5 次仍失败的进死信队列，由 SRE 人工处理。

3）不让发送方感知：发送方在原消息入库时就 ACK 了（"消息已发送"），扇出失败是后台事故，不回传到发送方。

4）失败可定位：每个副本带原消息 uuid + 目标 uid，死信里能精确知道"哪条消息没投到哪个人"。

伪代码：

on_dispatcher_consume(copy_msg):

    try:

        route_and_deliver(copy_msg)

    except RetryableError as e:

        if copy_msg.retry_count < 5:

            reject_and_requeue(copy_msg) // MQ 重投

        else:

            send_to_dead_letter_queue(copy_msg) // 死信，SRE 处理

            metrics.inc("group.fanout.dead_letter")

    except FatalError as e:

        send_to_dead_letter_queue(copy_msg)

9、按群规模进行分档

写扩散有个无法跨越的物理上限：群越大，扇出代价越接近不可承受。

具体是：

• 1）100 人群：100 次副本，舒服；
• 2）1000 人群：999 次副本，已经要做批量化；
• 3）5000 人群：4999 次副本，需要专门优化策略；
• 4）10000 人群：写扩散根本走不通。

工程上必须明确一条线：超过 N 人的群切换策略。

主流做法：

10、群消息扇出的时序流程

把上面 5 个设计点串起来：

▲ 群消息扇出的完整时序

11、主流大厂的大群消息投递方案

不同体量的 IM 系统在这一层的设计差异极大。写扩散不是唯一解 — 当规模到某个临界点，读扩散反而是更合理的选择。

11.1 某钉IM

钉IM，最早也走写扩散，但在万人群场景下扛不住，演进为读扩散为主 + 推拉结合 + 多级缓存。（相关资料请详读《深度解密钉钉即时消息服务DTIM的技术设计》一文中的“4.3、存储模型设计”章节）

核心思路：

• 1）群消息只存一份（不再为每个成员复制）；
• 2）成员"读群"时按订阅关系拉取；
• 3）实时性靠"近期消息推送 + 历史消息客户端按需拉取"补足；
• 4）多级缓存（万人群成员缓存）让"反查群成员"快到毫秒级。

▲ 最终：他们用智能限流和万人群成员多级缓存来支撑超级大群的运营

11.2 某信IM架构

在群消息"存一份还是存多份"的存储架构权衡上，相关高级研发工程师在技术博客分享中提到，采用写扩散路线（详见《微信直播聊天室单房间1500万在线的消息架构演进之》一文中的“5、消息扩散方案选型：读扩散”章节）。

即每条群消息按成员数复制成多份存储，换取读路径的极致简单（撤回、漫游、未读计数都只需操作单成员的消息流）。

代价是写放大与存储成本随群规模线性上涨。

11.3 企某信的IM架构

企某信和总所周知的微信，是两个系统，企某信的设计目标是支持万人群 + 已读回执。

它的做法是：仍然走写扩散，但投入更多硬件资源 + 各种局部优化（批量、缓存、异步）来支撑万人群的扇出成本。（相关资料可详读《企业微信的IM架构设计揭秘》一文中的“6、整体架构设计3：消息扩散写”章节）

11.4 总结对比

12、性能优化思考

中小规模 toB IM 在群扇出这一层有一条清晰的演进路径 — 但具体怎么走，要从你的产品定位、规模分布、工程团队能力倒推。下面是几个值得反复思考的点。

1）群规模上限：你的产品定位决定了上限的硬约束。如果业务场景就是大企业、需要万人群（如政府客户、大型集团内部沟通），那从 day 1 就应该认真评估读扩散方案 — 等到业务跑起来再切，技术债的复利会让人后悔。但如果只是一个中小企业协作工具，500 人甚至 1000 人上限其实没问题（参考微信群限制 500 人的判断）。先决定群规模的产品上限，再决定架构 — 这个顺序反过来就麻烦。

2）MQ 批量化：观察过的几乎所有中小规模 toB IM 项目都在 MQ broker 上付过血泪学费。Broker 的瓶颈往往不是磁盘 IO，而是连接数和单 partition 的串行化处理。批量化（batch=20~50）能让 MQ 写入次数降一个数量级，是收益明显的优化方向。但要注意批量化引入的复杂性 — 一批 50 个目标，其中 3 个失败该怎么处理？个人在中等规模 IM 项目里观察到的常见做法是"批内失败拆分重投"（把失败的 3 个重新打包成新的小批次发回 MQ）。

3）副本瘦身：副本带不带完整 payload 是个分歧点。带 payload 简单（下游消费者不需要反查原消息）但浪费带宽（千人群 1 条 1KB 消息 = 1MB 流量）；不带 payload 省带宽但下游消费者要做一次 KV 反查。比"完全瘦身"更工程化的做法是分档：消息体 < 1KB 时带 payload；超过就拆 — 副本只带 uid + uuid + 摘要（首 100 字符做消息预览），下游展开时按 uuid 反查全文。这种"内嵌摘要 + 按需反查"的混合方案，既能保留消息列表的预览体验，又能控制带宽峰值。

4）可观测体系：很多中小项目的扇出层处于"出问题时翻日志、平时不看"的状态，这是个隐患 — 当你发现"群消息延迟变高"时，往往已经在客服工单里出现了。

最值得加的三个指标分别是：

• a）单条群消息的扇出 RT P99（衡量端到端时长，是不是有慢扇出）；
• b）副本投递失败率按时间窗口分桶（衡量是否有阶段性故障）；
• c）批内部分失败率（如果做了批量化，衡量批是不是被"少数失败拖累整批"）。

这三个指标加起来，P0 故障定位时间能从"翻半小时日志"压缩到"看一眼大盘"。

5）大群临界点：如果业务真的开始需要 5000 人以上的群，参考某钉从写扩散切到读扩散的演进经验，关键经验是 — 切换不是一蹴而就的。中间过渡期通常是混合模式：千人以下继续写扩散（保留已读 / 撤回的低成本实现），千人以上的群单独走读扩散通道（客户端读消息时按 uuid 范围拉取，已读用 bitmap 聚合）。这种"按规模分流"的混合策略可以让团队渐进切换，不需要一刀切的大重构。关键是分流的判断点要明确（在群创建时就标记类型），而不是在每次消息扇出时动态判断 — 后者会让代码路径越来越复杂。

写扩散不是终点，是某个规模下的最优解。真正的工程能力，是知道什么时候该走，什么时候该停。

13、参考资料

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

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

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

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

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

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

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

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

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

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

[13] IM群聊消息的已读未读功能在存储空间方面的实现思路探讨

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

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

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

[20] 支持百万人超大群聊的Web端IM架构设计与实践

[21] IM千人群聊该不该用消息写扩散？详细算算成本账！

即时通讯技术学习：

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

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

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

1、引言

本文分享的是网易云音乐技术团队基于实时消息总线技术，解决了直播活动系统的模块灵活组合、消息治理与异步履约等问题，希望能给你带来启发。

2、系列文章

本文是系列文章中的第 10 篇：

1. 《直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路》
2. 《直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践》
3. 《直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路》
4. 《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》
5. 《直播系统聊天技术(五)：微信小游戏直播在Android端的跨进程渲染推流实践》
6. 《直播系统聊天技术(六)：百万人在线的直播间实时聊天消息分发技术实践》
7. 《直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践》
8. 《直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践》
9. 《直播系统聊天技术(九)：千万级实时直播弹幕的技术实践》
10. 《直播系统聊天技术(十)：基于实时消息总线的活动系统架构设计》（* 本文）

3、技术背景

所谓组装，就离不开老生常谈的复用，我们可以对大部分认为比较共性的场景做好系统级别的封装，封装成一个个复用度较高的服务，然后通过接口和扩展点的方式进行一部分的能力开放，但是有一种场景是解决不了的，就是当一个功能级别的代码执行结束后，希望触发到另外一个功能，同时希望这个功能是可以通过配置去解决的，并且不需要通过开发的手段去解决这类问题。

例如，用户送了一个礼物给一个主播，直播间的贡献榜上对该用户做了积分 +1，这是一个很典型的「履约」类场景，与我们在直播间内下单购买，履约给仓储系统道理是一样的，但是这都建立在这个流程模式是固化的。

而活动往往不是这样的，活动相比这些固化的流程是更为灵活的。

笔者的团队曾经开发过这样一个场景：

用户通过送礼，去帮助主播完成一个直播间虚拟能量条的冲击，而每充满这个能量条都希望做一件事情，这个事情就彰显出业务侧的脑洞大开，第一次的活动是希望给某个榜单加上分数，第二次的活动希望是给主播掉落一个虚拟的宝箱，第三次的活动是给用户发送一些抽奖券，依次类推，只要是做过的功能，他都希望这个事情可以去用，时间久了，就会面临频繁去修改这个模块的代码，当它「结束」后，if 条件式的去触发各个代码，或者策略模式的去魔改代码，对于长期建设来看这种方式并不友好，就我看来这只是这个模块结束后要做这么多事情，那么下一个模块如果从这么多事情挑两件岂不是还要再写一堆代码？

因此我们想到了一个相对比较原始的解决方案：总线式服务。

4、信鸽服务的组合能力

与其说组合，更倾向于用「履约」这个词形容会比较恰当一点，因为对于活动来说，信鸽只做「履约」这一侧的功能比较重要，他要解决的是异步场景的分发类问题，而不是对一些系统做一些 adapter 组合集成的能力。

这里以一个活动场景来做示例：

音乐人活动的一个简单的页面主要包含了几个模块功能：

• 1）用户通过送礼、观看等行为完成相关任务；
• 2）为喜爱的音乐人加进度条积分；
• 3）当进度条积分完成某个档位后，触发宝箱的掉落、飘屏送礼等。每个档位的类型是不同的；
• 4）幸运锦鲤的模块。

对于这样一个活动，从开发的角度来看，其实它是由几个模块进行组装的，除了 4 是需要独立开发的，1、2、3 都可以通过现有的系统进行组装，这里 1 抽象为任务系统，2 抽象为进度条系统，3 也可以抽象为宝箱系统、送礼系统等。

下图是对场景抽象化模块的概念：

那么难点来了，通过什么手段可以来将这些模块进行组装呢？

通过图中可以看到，当一个模块完成了他的生命周期，可以发送一份数据，路由系统收到了这个数据之后，会帮我们做一层路由的转发，决定数据会路由到下一个系统上去。下一个系统可能是「奖励系统」也可以是「进度条系统」。

同时可以对这个行为进一步细化的抽象，我们希望这个路由系统充当一个「总线」的角色，「信件」代表了每一个系统希望收到的数据，同时对每一个系统都抽象化成一个目的地，如果我们配置了一份路由关系（抽象为信鸽配置），那么这只「信鸽」可以作为将数据信件为我们带到我们想去的任何目的地，那么对于系统的好处是，系统只需要提供自己接入这个路由系统的能力即可，下一次随便是什么活动，可以直接做一些组合关系。

有了信鸽路由这种思路，针对音乐人活动这种场景，我们可以将一个流程的完整链路梳理出来：

图中可以看到，我们对任务、进度条等基础模块，做了一些扩展点（EXT-POINT）来满足业务流程的编排，这在中台里是比较常规的解决问题的手段之一，而在系统模块组组合的场景中，多了一层信鸽服务的概念，在【2】、【3】、【4】的处理流程中，都可以由信鸽来决定数据流向哪个系统，事实证明这个方案是可行也并且有效的。

5、整体架构设计

那么如何设计这样一个组合能力的架构呢？

研发的重心可以分为四个层面：

• 1）履约能力：当代码结束后做到末端的触发。
• 2）SDK 接入能力：Interface 级别的包装，天然的 Autoconfigure 能力。
• 3）全局的标识字典：一份数据如何让所有接入的系统都可以达成共识。
• 4）系统的自动注册能力：接入 SDK 后，自动上报到信鸽服务的统一管理，自动激活，不需要人工的介入开启。

基于这四个层面，架构设计如下图：

从图中可以看到：左侧虚线框代表了一个系统的触发，右边虚线框代表了最终另外一个系统的触达。信鸽系统充当了代理的服务，触发的系统只需要接入信鸽 SDK，当执行完自己的职责之后，对数据做一层组装发送给信鸽系统，信鸽系统会根据发送的信鸽 id，寻找到信鸽的相关配置，信鸽 id 决定了数据会流转到那个接入的子系统上，这个流转可以是同步的也可以是异步的（当然大部分都是异步场景），异步主要依赖「RocketMQ」的投递能力，当转发失败后，会对投递的数据结果集进行备份存储，用于定时步长的重试操作。在以往的实践过程中，大部分场景都是异步的链路，不需要获得下一个子系统提供的返回的结果集，并且「RocketMQ」本身投递消息的出错率也是小概率事件（毕竟4台 broker，出错3台的可能性是极低的），相比 RPC 这类通信级别的接口有绝对的优势。

6、提供的SDK能力

6.1 路由触发

在上图中，我们可以看到对于子系统分成了大概 2 类场景，一种是活动业务域，另外一种是非活动业务域，这本身与业务的场景有关，我们希望所有的子系统都可以按照标准去接入 SDK，但是并不能保证每个子系统提供能力都依靠 SDK，对于一些非活动业务域使用了定制化开发的模式来进行桥接工作，这种桥接工作更像是传统的 adapter 和 ESB 总线思路。

而活动业务域的子系统都可以采取接入 SDK 的模式，这里主要会介绍一下异步的设计思路，当一个子系统接入 SDK 后，会在 Spring 容器创建 bean 的时候，默认创建一个 PushConsumer 的 bean ，添加监听信鸽 「fly」 的 「Listener」 ，这样能做到自动消费到路由的消息，对消息进行解析，假设这个系统可以承担的模块能力分别是 S1 / S2 ..., SN 等功能，那么整体实现图如下图所示。

6.2 自动注册

每一个 Provider 的 Server 都是一个独立的应用服务集群，对于每一个 Provider 来说他提供的能力并不是单一的，正如上文所说，一个领域服务（活动 TOY 服务：主要提供各类积木式玩法领域），他能够提供的模块是非常多样的，诸如宝箱、进度条、留言板等等，「act-toy」 服务他具备了许多功能，当 「act-toy」 服务接入 SDK 后，就需要把自己子域需要发布成 Provider 的功能注册到信鸽上，注册的方案如下图。

当一个 Server 拉取 SDK 的启动后，会定时的拉取定义好的 Interface ，对实现的 Class ，获取自定义注解的 Type 类型，通过顺序消息的方式注册到信鸽服务上，采用了启动 + 定时推送的方式，信鸽服务收到相关的注册信息可以后会将其存储。

7、与ESB消息总线方案的比较

从整个组合的能力上看，整体的设计思路是符合总线式服务，而总线式服务业内比较经典的，就是 ESB 总线。

ESB 总线这个技术用今天互联网的角度来看是比较过时的，因为他本身更适应用于大型 IT 企业内部的一些跨语言类服务架构方案，而他本身承接了系统和系统之间的桥接能力。但是信鸽本身的设计不同于 ESB 总线，他更注重的特点是「哑管道」的概念，忽略集成的适配转换，也不适合做中心化同步的集成。

那么具体的比较如下：

那么可以从2个 ESB 场景来介绍信鸽的优势所在，笔者理解的 ESB 总线技术大致分两类：

1）开源的 ESB 解决方案：这类是提供开源的一种框架技术，部署在同一个 Tomcat 容器中，开发若干个 Bundle 可以运行在容器中，并且能做到热替换的作用，但是每个 bundle 需要通信的模式需要定制私有协议。由于这类开源框架较早，提供的通信协议大部分是 WebService 类的，因此在开发过程中，开发的成本会非常高，例如 Apache 早期开源的 ServiceMix 。关于协议，需要写大量的 「wsdl」 做通信，大多数也是依赖 WebService 发布的接口。

2）自研的 ESB 集成能力：笔者曾经参加过一个企业级的项目，大致是 ESB 的总线集成了各路系统，包括了 Rest 协议接口、C++ 服务发布的 WebService 协议、海外第三方公司发布的 WebService 协议，为了打通公司内部 C++ 服务、Java Web 服务与海外第三方系统，采用的就是做一个集成的总线，这里需要太多的协议转换，包括如何解析 「wsdl」 文件读取节点数据，转换成 Json 等等，这类场景在企业级服务是常见的事情，本身不适用互联网场景，侧重点更偏向于同步接口协议的转换，同时还不知道编排的能力，大部分依靠硬编码来解决。

无论 1 还是 2 与我们信鸽设计思路都是不同的，信鸽本质上强调的是异步去做末端的事件，选用轻量的协议结构，在技术上属于同语言系，因此关于字典的定义也是标准化的，也就是说，userId、anchorId 分别代表了用户id和主播id，并不需要任何一方突发奇想定义 uid、aid 这类的字样，由信鸽来定义统一化的字典，同时编排统一收拢到信鸽服务来确定，是可视化的，不需要编写复杂的 XML 节点文件。

8、与Pipeline流水线方案的比较

从总线这个概念来看，或多或少同「管道」是类似的，Pipeline 的思想被广泛应用在诸多技术领域中。

比如：

• 1）CI/CD 持续集成的场景；
• 2）开源框架中的流水线设计模式，例如 Netty框架中的网络字节流处理等；
• 3）业务自定义的一些工作流流转技术。

第一种场景：更倾向于 DevOps 的解决方案，从持续集成，持续交付，持续部署，为了快速、自动化、可重复的方式的去处理工程，与我们今天要解决的上层业务编排场景是完全不同的两个领域。

第二种场景：本质上是一种代码实现的设计模式，像 Netty 中，采用的是「责任链」的设计模式去实现，网络字节流经过「工厂流水线」后，进行包装，最后得到一个成品，与我们今天要解决的业务同样不是一个领域。

第三种场景：是业务开发过程中经常遇到的问题，尤其是有复杂流程的场景中，这里包含了对流程的编排、服务的编排，每个代码块和服务都可能作为一种处理的「节点」，在整个流水线中进行串排完成业务的实现。与我们的信鸽有什么不同呢？

在我看来，两种技术方案是可以同时存在的，我们对已经稳定的领域场景，做一些灵活自定义的一些流程编排，这些流程可以作为「流水线」的思路去实现，在「流水线」末尾的一个流程节点上可以定位为「信鸽」的节点，这个节点可以再继续自由组合定制化的活动场景。

9、信鸽服务的消息转发能力

9.1 面临的问题

直播的活动与营销活动的不同，大部分触发的场景偏向于平台的下游，因此需要监听许多 topic，去实现自己的业务编码，而活动在非成熟的形式背景下，必然要面临大量的短期代码，短期代码的生命周期往往只局限于活动周期内，这类代码代表了探索，代表了拓荒。直播活动在领域建模上是具备双面性的，一方面要在历史的经验去做经验复制和沉淀，另一方面要具备快速展开短期代码的能力。而随着服务数量的增多，就面临着许多服务要监听 topic，而这些 topic 对于 A 服务可能是监听过的，对于 B 服务可能也是监听过的，面临着这类问题，我们需要把 topic 接入的代码做一次代码的 Copy 或者做一些包来解决，但是这并不是一个友好的解决方案。同时，这也面临着另外一个问题，另外一个问题就是当一个代码块完成他的使命后，再也没有开启的那天，他接入的 topic 会一直进行空转的消费，我们不可能经常的对 「Nydus」（云音乐版 RocketMQ ）管控平台去做一些消费下线，时间久了，消息治理就变得比较棘手起来，就如同我们去分层解决服务循环依赖，没成想有一天异步链路中也出现了一团乱麻。下面这个图代表了 「dev」 过程中遇到的问题：

9.2 解决思路

我们希望信鸽可以继续发挥他的优势，它不仅仅是一个只做业务末端履约的一个总线服务，他更应该帮助我们活动域内的服务做好消息治理这方面的工作，首先需要有一个研发思路的转变，就是开发同学需要为自己 「dev」 的模块去提供他的 topic，这个 topic 与自己 「dev」 的模块是一个技术闭环的，如果每一个 「dev」 的模块都具备这样的能力，信鸽只需要发挥他的优势，对本来需要监听的 topic 变成由信鸽转发给模块的 topic。

按照这个解决思路的前提下，我们希望信鸽需要具备的就是消息转发的能力，而这个转发的场景可以抽象为三种。

具体是：

1）业务自定义的分发场景：这个场景是一定要做一些特定业务处理的，通过原始消息，做一些业务清洗工作，再去转发到一些业务场景中，属于定制化的场景。

2）注册上报自动分发的场景：这个场景只要保证信鸽服务的 receiver 监听的 topic 足够，那么信鸽就可以自动分发到各个业务模块的 topic 上，其中分发的消息结构是具备异样的，可以通过 tag 的不同让 consumer 自住选择性拉取，根据 tag 的区分，同时也能解决某类 topic 消息过多，导致饿死的场景，犹如上图提到的一样。

3）消息存储的场景：并不是所有的消息都需要存储，在活动中我们认为较为重要的消息是需要做备份，方便后期去做回放，例如礼物消息，是任何场景使用率较高的，为了提升写入的能力，可以采用批量消费的消费方式，做batch的写入，在写入这里初步选型是用TiDB，TiDB相对DDB（网易分布式数据库）比较适合去存这类消息，同时，这类消息大部分时候是不需要做读操作。

按照提到的三个场景，整体的架构如下：

我们的 receiver 可以根据配置过的 topic 动态的在 spring 容器里创建 consumer 的 bean，兼容了新接入 topic，需要修改信鸽服务代码的问题，同时在收到了 topic 消息的那一刻，消息转发如图中所描述一样，分成了三条路。

这三条路代表了：自动转发、自定义转发、消息存储，这里选用三个不同的 consumer，保证消费线程池的足够宽，和转发 topic 队列足够可消费，自动转发收到消息后会根据源 topic 的类型再一次做 Tag 区分的转发到配置的 topic 关系上，同时这个转发关系是可以让研发自助管理的，也可以配置他的存活周期，非常适用于活动短期场景，在活动结束后，减少了服务的空转消费的情况。当然毕竟也要考虑到另外一个问题，多了一跳的操作会导致到转发的失败，对于这种场景，我们会对失败的消息做 exception 的存储，进行重试处理。

同时：我们对信鸽的转发能力做了压力测试，队列的长度设置的足够宽，不考虑写表链路的场景下，单纯的转发能力，消耗 io 的点主要还是集中在 broker 通信的场景上，如果考虑消息都采用异步落盘的情况下，系统的吞吐量会更优，选用了 「8U16G」 的服务器配置，在 32 台 docker 云容器的支撑下，receiver 是可以承担到 300w/min 的消息量，并且 cpu 还能保持到 45% 左右。

虽然信鸽的转发能力解决了我们的问题，但并不代表这是个最优解，我希望的最优解是可以让信鸽搭载 FaaS 平台，毕竟 FaaS 可以提供很多关于消息清洗的场景，而且 FaaS 在机器资源调度上会有更好表现。FaaS + BaaS 这样的组合，是未来系统技术转型的趋势。

10、本文小结

花费时间做一个系统到底带来什么样的好处，又遇到什么难点呢？

10.1 开发维护性

这里用一个 case 来描述研发在使用信鸽服务做业务开发后会带来怎样的好处，大勇作为一名业务研发同学，今天他需要开发一个活动，活动涉及到榜单晋级、直播间杀怪、直播间飘屏、主播任务。

这个活动的流程思路是：

• 1）主播完成了 「xx」 任务后在直播间掉落一个「怪物」，并发送飘屏通知。
• 2）主播完成了 「xx」 任务后给榜单加上一些分数。
• 3）榜单跨日晋级 topN，topN 发送飘屏通知。

很幸运的是、以上涉及到的功能，以前都开发过了，这一次只需要完成组合，很不幸的是，大勇需要开发这类组合能力。直到他遇到了信鸽，一切迎刃而解了，每个功能都接入了信鸽，那么大勇只需要通过信鸽后台，配置好任务完成要飞向「杀怪」、「飘屏」等等信鸽，对于大勇可能只需要很短的时间提测了，发布流程也减少了，一次性的胶水组装代码也不需要，毕竟完成任务掉落怪物，这个逻辑写在任务系统好像也不是很合适。

10.2 遇到的困难

在做消息管理这类问题处理的时候，实现业务覆盖的时候遇到了很多难点。

我们要对现有系统已经接入的 topic 做一些改造，在新业务场景中是屡试不爽的，但是在旧系统中（例如任务系统），新提供了一个任务的 topic，收发路由的旧消息，虽然我们也按照 SDK 的方式做了根据 tag（源 topic）做一些不同 service 的区分，但是这里依然避免不了关于数据清洗和数据结构的协议转换问题，这类问题可能与任务系统本身的清洗思路是有问题的，而这类问题最佳的解决方案一般可以选用脚本语言去做消息清洗会更加灵活一点。

同时在做容量评估的时候，初期的压测并不是很顺利，由于写表链路与信鸽服务存在一个服务中进行压测，如果对某些消息进行数据写入 TiDB 的话，即便是批量消费写入整体服务的吞吐量也是难以压上去的，因此对写TiDB链路的服务单独进行独立，单独进行这方面的压测，信鸽原始服务只做转发，而写存储这一块可以单独去做写能力的评估。

去掉了写 TiDB 链路的场景，单独对服务的进行吞吐量压测，起初选用的 「4U8G」 的服务器资源，由于整体的转发性能较为吃 cpu ，当提升了规格之后，整体的吞吐量有了很明显翻倍，而介于线上消息量的评估，100w/min 的消息可能是我们现有业务的极限状况，我们分别按照不同消息量做了压测，最后输出了一个压测结果集，会根据不同的消息量区间做适当的扩容和缩减。

10.3 未来展望

本文就云音乐大直播活动中台技术团队在日常研发过程中遇到关于业务场景组合、消息管理这类问题，提供了一种系统设计的思路，希望可以帮助读者在日常开发提供一些参考的意见。

目前主要还是围绕着解决现有技术侧问题所展开的，后期会考虑对消息回放这一块作为修复数据的一个重要手段和解决方案，站在异常处理的视角上，如何帮助研发同学快速修复线上问题。

同时，面对未来国际化的场景下，对于消息用户地区机房不够敏感的场景下，希望可以通过一些手段来帮助业务侧消息转发到相关机房，协助 「Nydus」国际化后，解决业务侧路由的不清晰之处，而在未来的国际化路由机房的基础上，如果做到模块之间消息可以准确的路由到用户所在机房也是我们需要更加深入思考的问题。

我们希望信鸽可以作为直播相关产品在活动业务域的重要解决手段之一，帮助更多相关同学解决「复用」、「组合」的烦恼，同时希望它可以国际化，适应更多的产品场景之中。

11、参考资料

[0] 移动端实时音视频直播技术详解（一）：开篇》

[1] 海量实时消息的视频直播系统架构演进之路(视频+PPT)

[2] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[3] 阿里电商IM消息平台，在群聊、直播场景下的技术实践

[4] 微信直播聊天室单房间1500万在线的消息架构演进之路

[5] 百度直播的海量用户实时消息系统架构演进实践

[6] 百万人在线的直播间实时聊天消息分发技术实践

[7] 直播间海量聊天消息的架构设计难点实践

[8] vivo直播系统中IM消息模块的架构实践

[9] 万人群聊消息投递方案的思考和实践

[10] 海量实时消息的视频直播系统架构演进之路(视频+PPT)[附件下载]

[11] 社交场景下的统一即时通讯im消息流交互层模块化技术实践

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

[13] B站IM消息系统的新架构升级实践

[14] 视频直播技术干货(九)：千万级直播系统后端架构设计的方方面面

[15] 视频直播技术干货(十)：一文读懂主流视频直播系统的推拉流架构、传输协议等

[16] 视频直播技术干货(十三)：B站实时视频直播技术实践和音视频知识入门

即时通讯技术学习：

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

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

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

MobileIMSDK-Web是一套纯JS编写的Web端IM即时通讯框架(含服务端)：

• 1）超轻量级、极少依赖；
• 2）纯JS编写、高度提炼，简单易用；
• 3）基于著名的socket.io网络库实现，浏览器兼容性好、服务端并发性能好；
• 4）支持运行于iOS、Android等移动端浏览器和各种PC端浏览器；
• 5）能与MobileIMSDK的APP版（原生移动端代码编写）完美互通；
• 6）可应用于手机端/PC端的网页聊天应用、企业OA、Web端消息推送等场景。

☞ 补充说明：MobileIMSDK-Web是 MobileIMSDK 的姊妹工程，MobileIMSDK-Web专注于Web端网页聊天（或推送），而MobileIMSDK用于原生代码编写的移动端IM（或推送）应用，但二者可完美互通——从而实现原生代码编写的移动端与基于html的网页聊天完美互通。

☞ 关于为何使用的是Socket.io而不是Netty作为MobileIMSDK-Web的网络层，详见：《MobileIMSDK-Web的网络层框架为何使用的是Socket.io而不是Netty？》。

二、与MobileIMSDK的区别

☞ 关于MobileIMSDK：

MobileIMSDK主要使用原生代码编写，应用于非Web网页方式的移动端即时通讯场景下（当然最新的MobileIMSDK框架也支持基于HTML5的WebSocket客户端）。

• ❶ GitHub：https://github.com/JackJiang2011/MobileIMSDK
• ❷ 码云gitee：https://gitee.com/jackjiang/MobileIMSDK
• ❸ Gitcode：https://gitcode.com/hellojackjiang2011/MobileIMSDK

☞ 关于MobileIMSDK-Web：
MobileIMSDK-Web完全使用JavaScript编写，主要应用于不支持HTML5的需要兼容旧式浏览器的Web网页方式的即时通讯场景下（包括但不限于手机端、PC端的网页聊天（或消息推送）等）。

☞ MobileIMSDK与MobileIMSDK-Web的互通：

基于MobileIMSDK-Web开发的开发的网页聊天等和基于MobileIMSDK开发的移动端IM等可以无缝地进行消息互通，两个框架之间的通信协议完全兼容，从而实现您的网页聊天（或推送）与手机端原生代码开发的IM（或推送）进行完美协作，实现多端通信。

☞ 我该如何选择？

选择一：如果您的应用是用原生代码编写，如移动端是原生代码编写或者不需要兼容旧式浏览器，那么您可以将 MobileIMSDK 引入到您的项目中从而实现IM（或推送）应用；

选择二：如果您的应用是基于Web网页且需要兼容旧式浏览器，那么您的最佳选择就是使用MobileIMSDK-Web来开发您的网页端聊天（或消息推送）。

三、设计目标 

原生的WebSocket代码或者原始的socket.io代码，使得网络通信代码与大量前端UI界面代码混在一起，使得UI界面的重构、维护、改版都非常困难。而MobileIMSDK-Web工程将让开发者专注于UI应用层的开发，网络通信层专业的代码交由SDK开发人员，从而解偶Web端IM的UI前端和通信层的耦合性，同时大大降低复杂性。

总结一下，MobileIMSDK-Web的设计目标是为您的Web端IM带来以下便利：

• 1）前端UI代码与网络通信代码解耦：UI界面的重构、维护、改版都非常容易和优雅；
• 2）服务端网络通信代码与业务代码解耦：使得服务端的业务逻辑实现起来清晰简单；
• 3）浏览器端的高兼容性：受益于socket.io框架，MobileIMSDK-Web在不支持WebSocket的旧式浏览器上仍可很好地工作；
• 4）服务端的高并发、高性能：得益于Nodejs的异步编程模型和高并发特性，基于MobileIMSDK-Web编写的IM服务端拥有极高的并发处理性能。

四、框架组成 

整套MobileIMSDK-Web框架由以下2部分组成：

• 1）浏览器端SDK：用于开发浏览器端页面，纯JS编写，极少依赖，方便对接基于原生JS、Angular、EmberJS、VUE等各种前端框架；
• 2）服务器端SDK：用于开发Web端IM的服务端，支持高性能和高并发。

五、技术亮点

• ✅️ 轻量易使用：超轻量级——纯JS编写且极少依赖，高度提炼——简单易用；
• ✅️ 兼容性好：基于socket.io网络框架，浏览器兼容性好，在不支持WebSocket的旧式浏览器上仍可很好地工作；
• ✅️ QoS机制：完善的消息送达保证机制（真正ACK应答机制），确保不漏过每一条消息；
• ✅️ 断网恢复能力：拥有网络状况自动检测、断网自动治愈的能力；
• ✅️ 支持多种设备：支持运行于iOS、Android等移动端浏览器和各种PC端浏览器；
• ✅️ 封装的通信协议：实现了一个对上层透明的即时通讯通信协议模型；
• ✅️ 身份认证机制：实现了简单合理的身份认证机制（socket.io官方并未实现之，资料也几乎没有）；
• ✅️ 全消息路径：实现了client to server、server to client、client to client 共3种消息路径（socket.io官方只演示了广播消息，一对一发送无资料）；
• ✅️ 服务端慢io解偶：开发者可通过使用MQ进行DB等慢io的读、写解偶，保证IM实时消息高吞吐和性能；
• ✅️ 服务端代码解偶：实现了上层应用代码与sdk核心代码的解偶，上线、下线、c2s消息、c2c消息、身份认证等的回调通知；
• ✅️ 实现了在线列表：服务端实现了一个高性能的在线用户列表机制；
• ✅️ 完善的log记录：服务端接入了log4js日志框架，确保MobileIMSDK-Web中的每一个关键步骤都有日志输出，让您的运行调试更为便利；
• ✅️ 浏览器端代码解耦：实现了UI前端代码与sdk网络通信代码解偶，防止前端代码跟IM核心代码混在一起，不利于持续升级、重用和维护；
• ✅️ 轻松开启数据加密：一个参数即可开启SSL/TLS通信加密；
• ✅️ 聊天协议兼容：实现了与MobileIMSDK 完全兼容的协议模型。

MobileIMSDK-Web的浏览器兼容性：

（☞ MobileIMSDK-Web的兼容性由socket.io网络框架决定：点此查看兼容性说明）

六、性能负载

得益于socket.io网络框架的高性能和Nodejs的异步编程模型，MobileIMSDK-Web可支持单机数万甚至上十万并发连接。当然，每种应用场景都有各自的特点和差异，请视具体场景具体评估之，性能数据仅供参考。（关于为何使用的是Socket.io而不是Netty作为MobileIMSDK-Web的网络层，详见《MobileIMSDK-Web的网络层框架为何使用的是Socket.io而不是Netty？》）

☞ socket.io性能测试讨论：socket.io 高并发实战、socket.io保持6万+连接测试？、如何实现单服务器300万个长连接的？。

七、开发者手册

八、Demo运行截图

九、产品案例

以下为基于MobileIMSDK-Web的Web端IM产品案例 RainbowChat-Web 的产品情况。

下图为RainbowChat-Web的主界面（更多截图、更多演示视频）：

下图为RainbowChat-Web的主界面[聊天窗全屏时] （更多截图、更多演示视频）：

（本文内容引用自：http://www.52im.net/thread-959-1-1.html）

1、引言

在为大型语言模型（LLM）应用构建实时前后端通信系统时，选择正确的底层技术至关重要。

本章节将深入剖析三种主流技术的核心原理：

• 1）Server-Sent Events (SSE)：它作为服务器主导的单向数据流的黄金标准；
• 2）WebSocket：作为通用的全双工通信解决方案；
• 3）WebRTC：专注于媒体流和点对点数据交换。

理解它们的技术设计哲学和技术细节，是做出明智技术选型的关键基础。

本文将为读者剖析 SSE、WebSocket、WebRTC 的技术原理，并对比三者在性能、安全与架构方面的优劣势，详解了AI大模型（LLM）在实时通信协议方面的综合技术考量以及最终选择。

2、AI大模型实时通信技术专题

技术专题系列文章目录如下，本文是第 5 篇：

• 《全民AI时代，大模型客户端和服务端的实时通信到底用什么协议？》
• 《大模型时代多模型AI网关的架构设计与实现》
• 《通俗易懂：AI大模型基于SSE的实时流式响应技术原理和实践示例》
• 《ChatGPT如何实现聊天一样的实时交互？快速读懂SSE实时“推”技术 》
• 《AI大模型爆火的SSE技术到底是什么？万字长文，一篇读懂SSE！ 》
• 《详解AI大模型实时通信为什么选SSE，而不是WebSocket和WebRTC》（☜ 本文）

3、SSE是什么？

Server-Sent Events (SSE) 是一种基于标准 HTTP 协议的技术，专为服务器向客户端推送单向事件流而设计。

其工作流程始于客户端创建一个 EventSource 对象，该对象会自动发起一个持久的 HTTP GET 请求。服务器接收到请求后，不立即关闭连接，而是保持响应打开，并以特定格式发送数据。

这个格式要求服务器设置 Content-Type 头部为 text/event-stream。

每个事件由一系列字段组成，包括：

• 1）必需的 data: 字段用于承载消息内容；
• 2）可选的 event: 字段用于定义事件类型；
• 3）id: 字段用于标识事件以便在连接中断后恢复；
• 4）以及 retry: 字段用于指定重新连接前的等待时间。

消息之间必须以两个换行符 \n\n 分隔。

这种机制使得服务器能够在一个长连接上持续不断地推送增量数据，非常适合 LLM 流式传输等场景。SSE 的一大优势在于其天然地融入了现有的 HTTP 生态，能够无缝通过反向代理、负载均衡器和防火墙，无需特殊配置。

☞ 进一步学习：

• Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
• SSE技术详解：一种全新的HTML5服务器推送事件技术
• 使用WebSocket和SSE技术实现Web端消息推送
• 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket
• 使用WebSocket和SSE技术实现Web端消息推送
• 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket
• 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE

4、WebSocket是什么？

WebSocket 则提供了一种更为强大和灵活的全双工通信协议。它通过一次性的 HTTP 握手来“升级”一个标准的 TCP 连接。

握手过程涉及客户端发送一个包含 Upgrade: websocket 和 Connection: Upgrade 等特定头部的 HTTP 请求。如果服务器支持 WebSocket，它会返回一个状态码为 101 (Switching Protocols) 的响应，从而完成协议切换。

一旦连接建立，客户端和服务器就可以随时独立地向对方发送消息，而无需像 HTTP 那样每次都发起新的请求。

WebSocket 消息被封装在轻量级的帧中进行传输，支持文本和二进制数据，极大地降低了网络开销。

这种持久且双向的特性使其成为聊天应用、在线游戏和实时协作工具的理想选择。然而，其复杂性也远超 SSE，因为它是一个独立的协议栈，需要专门的服务器库和客户端处理逻辑。

☞ 进一步学习：

• 新手快速入门：WebSocket简明教程
• WebSocket从入门到精通，半小时就够！
• 初步认识WebSocket技术
• 刨根问底HTTP与WebSocket的关系(上篇)
• 刨根问底WebSocket与Socket的关系

5、WebRTC是什么？

WebRTC (Web Real-Time Communication) 是一个更为复杂的生态系统，旨在实现浏览器间的直接音视频通话和任意数据交换。

它的核心思想是尽可能地建立点对点（Peer-to-Peer, P2P）连接，从而绕过中间服务器传输大量媒体数据，以达到最低的延迟。

WebRTC 的整个通信过程分为三个阶段：

• 1）首先是通过信令服务器交换初始信息；
• 2）其次是通过 ICE (Interactive Connectivity Establishment) 框架进行 NAT 和防火墙穿越；
• 3）最后才是建立 P2P 数据通道。

ICE 框架依赖于 STUN (Session Traversal Utilities for NAT) 服务器来帮助设备发现自己的公网 IP 地址，如果直接连接失败，则会降级到 TURN (Traversal Using Relays around NAT) 服务器进行中继。

TURN 服务器虽然能保证连接成功，但会消耗大量带宽，因为所有流量都需要经过它转发。

WebRTC 的另一个关键组件是 RTCDataChannel API，它允许在两个浏览器之间建立一个类似 WebSocket 的 P2P 数据通道，用于传输非媒体数据。

由于其架构的复杂性，WebRTC 通常需要一个额外的信令层（常由 WebSocket 或 SSE 实现）来协调连接的建立。

 

☞ 进一步学习：

1. 访谈WebRTC标准之父：WebRTC的过去、现在和未来
2. WebRTC实时音视频技术的整体架构介绍
3. 新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？
4. WebRTC实时音视频技术基础：基本架构和协议栈
5. 实时音视频入门学习：开源工程WebRTC的技术原理和使用浅析
6. 零基础快速入门WebRTC：基本概念、关键技术、与WebSocket的区别等

6、兼容性、性能与开发复杂度对比

在为 LLM 应用选择实时通信技术时，必须在兼容性、性能和开发复杂度这三个关键维度上进行权衡。本章节将对 Server-Sent Events (SSE)、WebSocket 和 WebRTC 进行全面的横向对比，以揭示它们在不同方面的优劣，从而为技术选型提供数据驱动的依据。

6.1 兼容性与平台支持

首先，在兼容性与平台支持方面，SSE 和 WebSocket 拥有非常广泛的浏览器支持，几乎覆盖了所有现代浏览器，包括 Chrome、Firefox、Safari 和 Edge。Opera Mini 是少数不支持 WebSocket 和 SSE 的例外。IE 浏览器则完全不支持这两种技术。

相比之下，WebRTC 的支持范围稍窄一些，IE 不支持，旧版的 Edge 也不支持，但同样广泛应用于其他现代浏览器及其移动端版本。

对于 LLM 应用而言，这意味着 SSE 和 WebSocket 能够触及更广泛的用户群体。然而，值得注意的是，随着 HTTPS 成为网页标配，HTTP/2 得到了普及，这彻底解决了过去 SSE 在 HTTP/1.1 下因浏览器并发连接数限制（通常是6个）而导致的性能瓶颈，使得 SSE 在现代 Web 架构中表现得更加稳健和高效。

6.2 延迟性能

其次，延迟性能是衡量实时通信技术优劣的核心指标。

理论上，WebSocket 具有最低的延迟，因为它在握手完成后就建立了一个纯粹的、无头开销的数据通道。WebRTC 在 P2P 模式下可以实现极低的延迟，因为它避免了服务器中转。

然而，WebRTC 的延迟受到 NAT/防火墙穿越过程的影响，可能需要 fallback 到较慢的 TURN 中继服务器。

SSE 的延迟取决于底层的 HTTP 版本。在 HTTP/1.1 下，由于队头阻塞（Head-of-Line Blocking），多个 SSE 连接可能会相互阻塞。但在 HTTP/2 下，得益于其强大的多路复用能力，SSE 的性能得到了极大提升，可以与常规 HTTP 请求并行，延迟接近 WebSocket。

一项针对真实世界数据流的测试表明，SSE 和 WebSocket 在 EPS（每秒事件数）方面表现出相当的性能，WebSocket 在高并发下略占优势，但差异在实践中往往可以忽略不计。

因此，对于大多数 LLM 文本流式传输场景，SSE 在 HTTP/2 下已经提供了足够低的延迟。

6.3 开发复杂度

最后，开发复杂度是决定项目成本和上线速度的关键因素。

在这三者中，SSE 的开发复杂度最低。它基于标准的 HTTP，开发者可以利用现有的 Web 服务器和工具链，客户端代码也极为简洁，只需几行 JavaScript 即可启动 EventSource 并监听事件。

WebSocket 的复杂度显著更高。除了协议本身，开发者还需要处理连接管理、状态同步、手动实现心跳包和自动重连逻辑、应对粘性会话（Sticky Sessions）带来的负载均衡挑战，以及在分布式系统中使用 Redis Pub/Sub 等消息队列来广播消息。

WebRTC 的开发复杂度最高，它不仅包含了上述 WebSocket 的所有挑战，还引入了信令、ICE 候选者收集、STUN/TURN 服务器的配置和维护等一系列全新的难题。此外，WebRTC 的安全模型也更为复杂，需要同时保护信令通道和媒体通道。

综上所述：SSE 在兼容性、性能和开发复杂度之间取得了最佳平衡，尤其是在 HTTP/2 得到普及的今天。WebSocket 提供了更高的灵活性和更低的理论延迟，但代价是巨大的开发和运维复杂性。WebRTC 则因其固有的复杂性，仅适用于特定的 P2P 和媒体流场景。

7、安全性考量与风险缓解策略

在 LLM 应用中采用实时通信技术时，安全性是不可忽视的核心要素。本章节将深入探讨 Server-Sent Events (SSE)、WebSocket 和 WebRTC 在安全性方面的关键考量、潜在风险及相应的缓解策略。

7.1 Server-Sent Events

对于 Server-Sent Events (SSE)，其安全性很大程度上继承自标准的 HTTP 安全模型。

首要的安全措施是强制使用 HTTPS，因为 SSE 的长期连接窗口使其更容易受到中间人攻击（Man-in-the-Middle），窃听或篡改流中的数据。

身份验证是另一个关键环节。由于 EventSource API 不支持自定义 HTTP 头部，传统的 JWT 令牌传递变得困难。常见的解决方案是通过 URL 查询参数传递短时效的访问令牌，但这存在安全隐患，因为令牌可能被记录在服务器日志或浏览器历史中。

另一种更安全的方式是利用带有 SameSite=Strict 属性的 Cookie 来进行认证，这种方式能自动随请求发送，但需要注意 CSRF（跨站请求伪造）攻击的风险，可以通过检查 Origin 头部来缓解。

此外，SSE 端点容易受到 DoS（拒绝服务）攻击，攻击者可以通过建立大量连接耗尽服务器资源。对此，应实施严格的速率限制，限制来自同一 IP 或用户的并发连接数。

7.2 WebSocket

WebSocket 的安全性挑战更为复杂。

虽然 WSS (WebSocket Secure) 使用 TLS 加密来保护数据传输，但其状态化的性质带来了新的攻击面。

首先，WebSocket 缺乏标准化的身份验证机制，开发者必须自行实现，例如在握手阶段通过 Cookie 或查询参数传递凭证。如果未正确验证 Origin 头部，应用将面临 Cross-Site WebSocket Hijacking (CSWSH) 攻击，恶意网站可以在未经授权的情况下建立 WebSocket 连接并访问敏感数据。

其次，WebSocket 容易受到 DoS 攻击，特别是通过 Flood 攻击（发送大量小消息或建立海量连接）来耗尽服务器 CPU 或内存。有效的防御措施包括要求连接前进行认证、限制消息大小和频率、以及实施精细的速率控制 [89]。输入数据也可能导致注入攻击，如 SQL 注入或 XSS，因此所有传入的消息都必须经过严格的验证和清理。

最后，由于 WebSocket 连接是持久的，如果令牌在连接期间过期，可能会导致会话劫持，因此需要实现 token 刷新机制。

7.3 WebRTC

WebRTC 的安全性设计更为严格，其核心理念是端到端加密。

所有媒体流都默认使用 SRTP (Secure Real-time Transport Protocol) 加密，而数据通道则使用 DTLS (Datagram Transport Layer Security) 加密，确保只有通信双方可以解密数据。

然而，WebRTC 的安全性并非万无一失，其脆弱性主要集中在基础设施层面。最著名的安全问题是 IP 地址泄露。由于 ICE 协商需要交换候选者的 IP 地址，即使用户使用了 VPN，其真实的本地和公网 IP 仍可能暴露给通信的另一方，这严重损害了隐私。

缓解此问题的方法是在网络拓扑中强制使用 TURN 服务器中继，从而隐藏客户端的真实 IP。信令通道的安全性至关重要，如果信令服务器未使用 WSS (WebSocket Secure) 或 HTTPS，攻击者可以拦截信令消息，从而发起会话劫持或拒绝服务攻击。

此外，TURN 服务器若配置不当，可能被滥用进行 DDoS 攻击或数据窃取。

最后，尽管 WebRTC 协议本身很安全，但其浏览器实现可能存在漏洞，需要及时更新浏览器以修补已知的安全问题。

 

8、架构设计与可扩展性挑战

为 LLM 应用选择实时通信技术不仅关乎功能实现，更深刻地影响着系统的整体架构设计和未来的可扩展性。本章节将深入探讨使用 Server-Sent Events (SSE)、WebSocket 和 WebRTC 时面临的架构挑战，特别是在大规模生产环境下的可扩展性问题。

8.1 Server-Sent Events

使用 Server-Sent Events (SSE) 的架构相对简单且更具弹性。

由于 SSE 基于标准的 HTTP，它可以轻松地与现有的无状态微服务架构集成。服务器可以水平扩展，因为每个 SSE 连接都是独立的，负载均衡器可以将新连接分发到任何可用的服务器实例。

然而，当需要向所有订阅用户广播消息时，简单的无状态架构会遇到挑战。解决这个问题的常见模式是引入一个中央消息代理，如 Redis Pub/Sub 或 Kafka。所有服务器实例都订阅同一个 Redis 频道，当有新消息需要广播时，只需将消息发布到该频道，Redis 会将其高效地分发给所有相关的 SSE 客户端。这种发布/订阅（Pub/Sub）模式极大地简化了广播逻辑，并提高了系统的可扩展性。

此外，SSE 的 stateless nature 使其非常适合在云原生环境中运行，例如 Kubernetes 或 serverless 平台，因为它不需要在节点间共享会话状态。

8.2 WebSocket

相比之下，WebSocket 的架构设计则充满了挑战，其根本原因在于连接的有状态性。

每个 WebSocket 连接都会占用服务器的一个文件描述符，并持续消耗内存和 CPU 资源。当用户数量从数百增加到数万甚至数百万时，这种状态化特性会迅速成为瓶颈。

传统的负载均衡策略（如轮询或最少连接）无法有效分配 WebSocket 连接，因为客户端断线重连后很可能需要回到最初的服务器实例以保持会话状态。

为了解决这个问题，通常需要采用“粘性会话”（Sticky Sessions）或“会话亲缘性”（Session Affinity）的负载均衡策略，但这会导致负载分布不均，并形成单点故障。

更高级的解决方案是构建一个全局状态管理系统，例如将所有连接状态存储在 Redis 等外部数据库中。当服务器 A 接收到需要路由到服务器 B 上某个用户的 WebSocket 消息时，它可以从 Redis 获取目标用户的连接信息并进行转发。这种方法虽然可行，但极大地增加了系统的复杂性和延迟。因此，许多团队最终会选择使用专门的实时通信平台（如 Ably 或 Pusher）来托管这部分基础设施，从而将焦点重新放回业务逻辑上。

8.3 WebRTC

WebRTC 的可扩展性问题则源于其点对点（P2P）的本质。

纯 P2P 架构在小规模群组（例如，最多 4-5 人）内工作良好，因为每个参与者只需要与其他成员建立连接即可。然而，当参与者数量增加时，连接数量会呈二次方增长（N² problem），导致每个客户端的带宽和 CPU 负载急剧上升，很快就会超出个人设备的处理能力。

为了实现 WebRTC 的规模化，必须引入中心化的媒体服务器。

目前主要有两种架构：

• 1）MCU（Multipoint Control Unit，多点控制单元）；
• 2）SFU（Selective Forwarding Unit，选择性转发单元）。

MCU 会接收所有参与者的媒体流，进行解码、混音/拼接，然后重新编码成一个新的流再分发给所有人，这样客户端只需接收一个流，但 MCU 承担了巨大的计算压力。

SFU 则是一种更高效的架构，它只负责将每个参与者发送的媒体流转发给其他所有人，而不进行任何处理，从而将计算负担分散到各个客户端。SFU 是现代大规模 WebRTC 应用（如 Zoom、Google Meet）的首选架构。

然而，无论是 MCUs 还是 SFUs，都需要大量的服务器资源和复杂的网络基础设施来支持，这对于许多团队来说是一笔巨大的投资。

总而言之：

• 1）SSE 在可扩展性方面提供了最大的灵活性和成本效益；
• 2）WebSocket 的扩展性挑战巨大，通常需要借助第三方服务或投入大量内部工程资源；
• 3）WebRTC 的扩展性则最为昂贵和复杂，是专门为媒体流设计的，不适合用于普通的文本数据通信。

9、最终决策与综合建议

在对 Server-Sent Events (SSE)、WebSocket 和 WebRTC 进行了全面的原理、性能、安全性和可扩展性分析之后，本章节将整合所有信息，为 LLM 应用的前后端实时通信提供一个清晰的决策框架，并给出具体的选型建议。

选择何种技术，最终取决于您的 LLM 应用的具体需求、团队的技术栈和预算。我们可以将 LLM 应用的实时通信场景划分为几个典型的层级，每个层级对应不同的技术最优解。

9.1 第一层级：流式文本展示

这是最常见的 LLM 应用场景，用户输入一个问题，然后看到答案逐字或逐词地动态呈现出来。这种模式的核心特征是服务器主导的单向数据流。

在这个场景下，Server-Sent Events (SSE) 是无可争议的最佳选择。

其理由非常充分：

1）首先，SSE 的设计初衷就是为此类单向推送而优化的，它比 WebSocket 更加轻量和简单。

2）其次，得益于现代浏览器对 EventSource API 的原生支持，客户端实现极其简单，且内置了可靠的自动重连机制，极大地提升了用户体验和应用的健壮性。

3）再者，SSE 基于标准 HTTP，在部署和运维上非常友好，可以无缝融入现有的 web 服务生态，无需为实时通信单独搭建一套复杂的基础设施。

Shopify 在其 2022 年黑色星期五活动中的 BFCM Live Map 成功案例，就是一个有力的证明，他们通过 SSE 将毫秒级的数据更新推送给数十万用户，展现了其在生产环境下的强大能力和可扩展性。

9.2 第二层级：双向实时互动

当应用的需求超越了单向展示，进入真正的“对话”或“协作”阶段时，就需要选择能够支持客户端和服务器双向通信的技术。在这种情况下，WebSocket 是唯一的选择。

典型的用例包括：

• 1）语音 I/O：OpenAI 的 Realtime API 就是一个绝佳的例子，它利用 WebSocket 实现了低延迟的语音对话，允许用户在 AI 说话时打断，并即时获得反馈。这种场景需要双向的音频流和命令流，是 WebSocket 的典型应用。
• 2）多智能体系统：当多个 AI Agent 需要在后台协同工作，并需要向前端实时同步各自的思考过程、工具调用结果或状态变化时，WebSocket 提供了必要的双向通道。
• 3）实时协作编辑：当 LLM 作为协作者与用户共同编写代码、文档或进行头脑风暴时，WebSocket 可以确保用户的每一次修改都能被实时同步给 LLM，反之亦然。

选择 WebSocket 的代价是显著增加的开发和运维复杂度。您需要投入资源来构建和维护一个能够处理成千上万个并发长连接的系统，并解决由此带来的一系列可扩展性问题。

9.3 第三层级：点对点媒体流与数据交换

这是 WebRTC 的专属领域。虽然 WebRTC 也能传输数据，但它的核心价值在于绕过服务器直接传输高质量的音视频流。

在 LLM 应用中，WebRTC 的应用场景非常具体且有限：

• 1）高级语音交互：当需要处理原始的、高保真的音频流，而不是经过编码的文本或语音片段时，WebRTC 可能是必要的底层传输协议。
• 2）P2P 文件共享：如果 LLM 应用涉及到用户之间直接通过浏览器共享由 LLM 生成的大文件，WebRTC 的 DataChannel 可以提供一条绕过服务器的高速通道。

除非您的应用明确属于上述范畴，否则不应轻易选择 WebRTC。它的高昂复杂性和成本使其成为一个非常规的选择。

9.4 综合决策框架

 

9.5 最终结论与建议

对于绝大多数 LLM 应用的前后端通信需求，我们强烈建议从 Server-Sent Events (SSE) 开始。

它足够强大，足以满足当前主流的流式文本展示需求，同时又足够简单，能让团队快速迭代产品。不要为了所谓的“先进性”或过度设计而一开始就选择更复杂的 WebSocket。只有当业务发展到确实需要双向、低延迟的实时互动时，才应该评估并投入资源迁移到 WebSocket。

记住，没有一种技术是完美的，最好的技术是那个能够以最低的成本和复杂度解决你当前问题的技术。

10、参考资料

[0] EventSource API Docs
[1] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
[2] SSE技术详解：一种全新的HTML5服务器推送事件技术
[3] 使用WebSocket和SSE技术实现Web端消息推送
[4] 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket
[5] 使用WebSocket和SSE技术实现Web端消息推送
[6] 一文读懂前端技术演进：盘点Web前端20年的技术变迁史
[7] WebSocket从入门到精通，半小时就够！
[8] 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket
[9] 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE
[10] WebRTC实时音视频技术基础：基本架构和协议栈
[11] 零基础入门：基于开源WebRTC，从0到1实现实时音视频聊天功能
[12] 实时音视频入门学习：开源工程WebRTC的技术原理和使用浅析
[13] 零基础快速入门WebRTC：基本概念、关键技术、与WebSocket的区别等
[14] 大模型时代多模型AI网关的架构设计与实现
[15] 全民AI时代，大模型客户端和服务端的实时通信到底用什么协议？
[16] 通俗易懂：AI大模型基于SSE的实时流式响应技术原理和实践示例
[17] Web端实时通信技术SSE在携程机票业务中的实践应用
[18] ChatGPT如何实现聊天一样的实时交互？快速读懂SSE实时“推”技术

即时通讯技术学习：

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

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

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