如何设计一个敏感词过滤系统？

Corey2026/6/9大约 8 分钟面试题面试题

来源：如何设计一个敏感词过滤系统？

在当今的互联网环境下，内容安全（Content Security）已经成为各大平台不可忽视的生命线。无论是社交媒体、直播弹幕，还是电商评论，海量的用户生成内容（UGC）中往往夹杂着违规信息。

设计一个生产级的敏感词过滤系统，我们面临着三个核心挑战：

高效匹配：在亿级流量冲击下，如何保证毫秒级的低延迟响应？
动态更新：如何在不重启服务、不中断业务的情况下，实时生效最新的违规词库？
对抗变种：面对“火星文”、拼音拆解等恶意规避手段，系统如何保持健壮性？

本文将围绕这三个目标，从最基础的算法选型开始，一步步演进到支撑亿级流量的分布式智能架构。

一、算法选型：从 O(N*M) 到 O(K) 的性能跃迁

在系统初期，很多开发者会习惯性地使用数据库模糊查询（LIKE %keyword%）或者正则表达式（Regex）来解决问题。在数据量极少时，这确实有效。但在生产环境中，这种方案是致命的。

假设我们有一个包含 10,000 个敏感词的词库，需要检测一段 5,000 字的文章。如果使用简单的字符串包含匹配（String.contains），系统需要进行 10,000 × 5,000 次扫描。随着词库的膨胀，计算量呈线性甚至指数级增长，CPU 会瞬间被耗尽。

我们需要的是一种时间复杂度与词库大小无关的算法。

如上图所示，引入 Trie 树（字典树） 或 AC 自动机（Aho-Corasick Automaton） 后，性能发生了质的飞跃。无论词库里有 1 万个词还是 100 万个词，检测耗时只与被检测文本的长度（K）有关。这种“空间换时间”的策略，将响应时间从秒级压缩到了毫秒级。

二、核心数据结构：基于 Trie 树的状态机实现

Trie 树的核心思想是利用字符串的公共前缀来减少查询时间。我们将所有的敏感词构建成一棵树状结构，根节点为空，每个节点代表一个字符。

当文本流进入系统时，我们像查字典一样逐字匹配：

指针游走：读取文本中的字符，在树上寻找对应的子节点。
状态判定：如果路径断开，说明不匹配；如果路径走到了标记为“结束”的节点，说明命中了敏感词。
白名单溯源：为了防止误杀（例如“杀毒软件”包含“杀毒”），我们可以在树的特定路径上标记“白名单”属性，实现更细粒度的控制。

三、动态配置：基于双缓冲（Double Buffering）的热加载机制

算法解决了匹配效率问题，但工程落地时会遇到一个棘手的痛点：词库更新。运营人员在后台新增了一个突发敏感词，技术部门不可能为此重启所有服务。我们需要实现热加载（Hot Reload）。

在多线程高并发环境下，直接修改正在使用的 Trie 树是非常危险的，极易导致并发冲突或服务崩溃。这里我们引入了并发编程中常用的Copy-On-Write 思想与 双 Buffer 机制。

设计方案如下：

版本控制：运营在后台修改词库后，数据存入 MySQL，并更新版本号。
事件广播：通过 Redis 的 Pub/Sub（发布订阅）机制，向所有业务节点发送“词库变更”信号。
异步构建：业务节点收到信号后，不影响当前服务，而是在内存中开辟一块新区域，构建一棵全新的 Trie 树（New Buffer）。
原子切换：新树构建完毕后，利用 Java 的 AtomicReference 或 volatile 关键字，将全局指针瞬间指向新树。
GC 回收：旧树失去引用，由垃圾回收器（GC）自然清理。

这种设计实现了全程无锁（Lock-free），无论词库多大，更新过程对业务流量完全透明，真正做到了“毫秒级生效，零业务感知”。

四、存储架构：多级缓存（Multi-Level Caching）策略

在亿级流量的场景下，仅仅依赖 Redis 也是不够的。每一次网络 I/O 都是成本。为了追求极致性能，我们采用了三级存储架构。

L1 (In-Process Cache)：这是性能的关键。我们将构建好的 Trie 树对象直接驻留在应用服务的堆内存（Heap）中。命中 L1 意味着零网络开销，检测耗时通常在微秒级别。
L2 (Distributed Cache)：使用 Redis 存储全量的词库数据、黑名单配置以及版本信息，作为各个服务节点之间的数据同步源。
L3 (Persistent Storage)：MySQL 作为数据的最终来源（Source of Truth），负责归档、审计和管理后台的增删改查。

这种架构确保了 99.9% 的请求都在本地内存中完成，只有在服务启动或缓存失效时才会访问远程存储。