语源科技BlogJava-所有随笔区

IM全文检索技术(五)：vivo敏感词匹配系统的技术实践

Jack Jiang — Wed, 23 Sep 2026 09:59:00 GMT

本文作者vivo互联网服务器团队Liang Kangwu，有修订。

1、引言

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

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

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

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

2、系列文章

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

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 ）

Jack Jiang 2026-09-23 17:59 发表评论

备份maven仓库

有机肥 — Sun, 20 Sep 2026 01:13:00 GMT

https://nexus.dayu.work/repository/bp46571077-releases/nexus3-exporter 是一个轻量的 Python 脚本，适合快速备份
首先要安装python

1. 确认 pip 可用

先运行：python -m pip --version如果能看到 pip 版本号，就继续。
2. 获取 nexus3-exporter 脚本

直接在 GitHub 搜索 `nexus3-exporter`，下载 ZIP 解压，然后进入解压后的目录。
进入目录后，确认里面有：
`nexus3_exporter.py`
`requirements.txt`

3. 安装依赖

在脚本所在目录运行：

python -m pip install -r requirements.txt

4. 运行导出命令
要备份https://nexus.dayu.work/repository/bp46571077-releases/用下面的命令

python nexus3_exporter.py -u your_username -o .\bp46571077-backup -m https://nexus.dayu.work bp46571077-releases

有机肥 2026-09-20 09:13 发表评论

Nginx生产级WebSocket实时长连接负载均衡，一文搞定

Jack Jiang — Tue, 08 Sep 2026 02:59:00 GMT

本文作者银河技术，有修订和改动。

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基础资料可以继续阅读：

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;
    }
}