共计 5290 个字符，预计需要花费 14 分钟才能阅读完成。
导读 ：咱们在实现检测一个字符串是否蕴含另一个字符串时，简略的用一个字符串匹配算法就能够实现，如果要实现检测一个字符串是否蕴含 N 个字符串时，这个 N 有可能上千万，再利用简略的字符串匹配算法就没法满足咱们的需要了，上千万的词须要能够灵便的保护，业务方匹配时可能拿到本人的词进行匹配，千万词的匹配须要保障匹配速度，要在秒级之内出后果。所以，咱们须要一套解决此类问题的计划——词表服务。
全文 5370 字，预计浏览工夫 12 分钟。
一、背景
内容审核平台须要检测作者发的文章中是否含有非凡的敏感词。对于不同的业务线对这些词的要求也不同，有的严格有的宽松；有的须要单词，有的须要多词；有的须要检测出隐含词、变体词；有的在题目失效，有的在注释失效；有的检测出送人审，有的检测出间接回绝；有的须要几千词，有的须要上万、百万、甚至千万词。对于这些词各业务线能够本人保护，不便减少、删除、批改，各业务能够依据本人的需要配置词的失效规定；在检测的时候业务方能够拿到本人保护的词对文章进行检测，而且须要保障检测的时效，可能实时拿到检测后果。
二、架构
上图是词表服务的整体架构：
（1）词表治理 ：各业务线在词表治理平台保护本人的词表，每个业务线能够增加多个词表组，每个词表组中能够保护敏感词以及能够动静增加敏感词的属性；词表治理平台用 ES 实现了对词表及上千万词高效的分词检索能力；词表治理会定时生成各业务线的词表 BOS 文件，上传到 BOS 服务。
（2）服务层 ：业务方调用词表服务对立对外的匹配接口，服务层将匹配工作送到策略算子层，实现词表的匹配性能。词表对外的对立服务相当于一个简略的网关，提供了鉴权性能，验证申请是否非法；提供了流量限度的性能，能够为每个申请方设置流量限度值；提供了后果解决的性能，策略算子返回的敏感词属性只是一部分，依据业务方的需要，能够欠缺策略算子返回的敏感词属性；提供了流量转发的性能，能够依据配置将各业务线的申请打到不同的集群，实现各业务策略算子分集群部署。
（3）策略算子层 ：策略算子实现对文本中敏感词的匹配，匹配的模式有蕴含匹配、强过滤匹配、多模匹配，命中的敏感词会返回给词表服务层。各业务线的词表会被策略的每个算子用全量刷新的形式或者实时同步增量数据的形式加载到内存，反对算子的匹配性能。全量刷新的形式：词表治理平台会定时将词表分业务线生成 BOS 文件，上传到 BOS 服务，策略算子定时从 BOS 文件中同步敏感词到内存；实时同步的形式：策略算子会实时扫描刺词表数据库，将增量的词表加载到内存。
（4）根底服务 ：GDP 框架实现了词表服务开发，Pandora 平台实现了词表服务的部署，mysql 实现了词表数据的存储，ES 实现了词表的分词检索，bdrp 实现了限流及缓存性能，BOS 服务实现了词表文件的的传输。
三、词表治理平台
词表治理平台，实现了各业务线保护本人的词表，每个业务线下能够创立多个词表组，不便业务方分类管理本人的敏感词，每个词表组的含意由业务方赋予，具体体现在当命中的敏感词属于这个词表组的时候，业务方是否依据词表组做不同的处理；每个词表组下能够保护敏感词，敏感词的属性由业务方本人抉择，例如，审核类型这个属性，业务方能够依据命中具体某个敏感词后要送审，就抉择送审词这个属性值，如果要回绝就抉择回绝词这个属性值。
3.1 词表治理
各业务线能够增加、批改的词表，能够对词表进行检索。
（1）新增词表，抉择属于的业务线，增加名字和备注，能够一次将词表创立到多个业务线下，如果其余业务线有词表能够复用，也可间接将其余业务线的词表拷贝到本人新建的词表下，方便快捷，不便管理人员对词表的治理。如图 1：
（1）批改词表，能够批改词表的名字、备注，能够将词表从新指定业务线，如果其余业务线有词表能够复用，也可间接将其余业务线的词表拷贝到本人的词表下，方便快捷，不便管理人员对词表的治理。如图 2：
（2）词表检索，反对通过词表 ID、词表名称、业务线以及创立的工夫检索词表；词表名称的检索，利用了 ES 的个性能够实现对词表名称进行分词检索；在检索到的列表中，能够看到词表的 id、词表名称、业务线、词表的创立工夫、更新工夫、每个词表下的词条数量、词表备注、词表的失效状态操作人等词表属性；能够在列表中状态中点击，将词表改成失效或生效状态；在操作栏能够点击批改，批改词表，点击追加给词表增加词，点击查看查看词表的详情信息。如图 3：
3.2 敏感词保护
在词表中能够高效快捷的保护敏感词。重要的敏感词的属性蕴含:
（1）词条类型：标识敏感词是送审词还是过滤词；
（2）敏感类型：标识词条的敏感分类；
（3）匹配模式：蕴含匹配 - 检测本文中是否蕴含敏感词，强过滤匹配 - 检测文本中汉字、字母、数字、特殊字符互相组合后是否蕴含敏感词，多模匹配 - 检测文本中是否命中 2 个或 3 个词，且多个词间距在无效范畴内。
（4）失效地位：敏感词在文章中的失效地位，如，题目、注释、图片中给的文字等。
（5）豁免词：蕴含匹配中敏感词的属性，如果敏感词是 A，豁免词是 B，文本中有 AB 词，则敏感词 A 不会命中。
（6）延展策略：多模地位置换 - 如果有多模词 AB，文本中有词 BA，则能够命中 AB 敏感词；字母大小写转换 - 疏忽大小写，如果敏感词是 cd，文本中有 cD、Cd、CD 词，则都可命中 cd 词。
（7）生效工夫：提供了长期有效和具体生效工夫两种抉择。
敏感词保护提供了单条增加、批量增加、单条批改、批量批改、词表检索、词条检索等性能：
（1）单条追加，追加的词表名称曾经确定，业务方能够依据本人的业务抉择词的属性，追加中的操作，如果词的匹配模式属性抉择了蕴含词，能够增加这个词的豁免词。如图 4：
（2）批量增加，反对同步最大一次增加 3000 条，能够同时增加到不同业务线的不同的词表中，方便快捷，不便了管理员对敏感词的保护工作，要增加的所有的敏感词属性必须统一才能够应用此性能，二期不反对给蕴含词增加豁免词属性，能够在敏感词输入框中换行输出多条。如图 5：
（3）批量创立，业务方能够依据本人的业务将敏感词及属性保护到 EXCEL 表中，每个文件最大反对 3 万词，提交后，能够生成一个创立工作，后盾运行，同时能够创立多个工作，执行的时候是程序执行，如图 6：
（3）单条批改，能够批改词条的任意属性，如果敏感词是同步批量增加的蕴含词，想要增加敏感词的豁免词能够在这里批改。如图 7：
（3）批量批改，业务方能够依据本人的业务将敏感词及要批改的属性保护到 EXCEL 表中，每个文件最大反对 3 万词，提交后，能够生成一个更新工作，后盾运行，同时能够创立多个更新工作，执行的时候是程序执行。如图 8：：
（4）敏感词检索，能够依据敏感词的审核类型、匹配模式、失效地位、敏感类型、操作人、所属业务线、所属词表、敏感词的创立工夫等属性检索，敏感词的检索应用了 ES 分词检索的个性，能够反对分词检索，也能够实现准确检索；检索的列表中展现了敏感词的名称、所属业务线、所属词表、操作人、操作工夫、备注等字段，能够查看总体数量，能够导出，批量解除，操作栏中，能够点击批改，进入批改页面，能够点击解除，解除此条敏感词。如图 9：
四、词表服务对立入口
词表服务对立入口，提供了规范的 API 接口，业务方调用词表服务对立对外的匹配接口，服务层将匹配工作送到策略算子层，实现词表的匹配性能。词表对外的对立服务相当于一个简略的网关，提供了鉴权性能，验证申请是否非法；提供了流量限度的性能，能够为每个申请方设置流量限度值；提供了后果解决的性能，策略算子返回的敏感词属性只是一部分，依据业务方的需要，能够欠缺策略算子返回的敏感词属性；提供了流量转发的性能，能够依据配置将各业务线的申请打到不同的集群，实现各业务策略算子分集群部署。具体的流程，如图 10。
五、策略加载词表
策略加载词表通过多计划的迭代，计划最终逐步成熟稳固。
第一版词表在策略的失效计划：词表治理平台将所有的业务线的词表生成一个词表文件，上传到 BOS，词表策略 30min 定时扫描加载一次。所有业务线集中到一个词表文件中，一次加载，导致了策略加载词表速度慢。
第二版的计划，30 分钟失效工夫起初不能满足业务方的需要，词表治理平台依照业务线生成多个词表文件，推送到 BOS 零碎，词表策略定时，分业务线开启多线程加载词表，词表失效工夫由 30min 缩小到 5 分钟。
单三版计划，5min 钟工夫对于非凡场景还是不满足，咱们减少了词表实时同步计划，由词表策略 10s 定时去数据库扫描增量的数据加载到内存，然而这种计划不适宜上万的增量数据加载，只适宜万级以内词的加载。
当初词表策略加载词表，第二版和第三版同时存在，优势互补，整个演变过程如图 11：
BOS 文件格式，多列用制表符宰割，多模词用 & 符号连贯，蕴含词增加前缀 + 号辨认，次要的信息有敏感词 id、敏感词名称、敏感词所属词表 id、多模词词间距、生效工夫、审核类型、匹配类型、所属业务线、失效地位、敏感类型、延展策略、豁免词。如图 12：
全量加载和增量实时同步加载流程，全量加载会在启动的时候加载一次，加载的频率半个小时以上，能够依据业务线配置；增量实时同步 10s 中去数据库检测一次是否有增量数据，而后分页加载到内存。如图 13：
策略缓存词表到内存的加载构造，如下：
（1）业务线、失效地位，敏感词，敏感词 id 字典映射。匹配到敏感词，能够依据业务线，失效地位，疾速的找到敏感词的 id，通过敏感词的 id 再获取敏感词的属性规定，用于计算匹配到的敏感词是否无效。如图 14：
（2）敏感词 id 及敏感词属性规定字典映射，BOS 文件每行敏感词解决存储。通过敏感词 ID 可能疾速查到敏感词的属性规定，用于计算匹配到的敏感词是否无效。如图 15：
（3）敏感词挂在到字典树（Trie 树），每个业务线、失效地位生成一个字典树，字典树是词表策略的外围，上千万的敏感词匹配能在 10ms 以内返回配置后果。如图 16：
六、词表策略匹配实现
6.1 词表策略匹配流程
策略配置匹配流程，如图 17：
（1）输出匹配参数，request\_id 申请的惟一标识，用于上下游定位，req\_from 申请起源，用于辨认申请业务方，token 用于权限校验，service\_line 业务线标识，用于辨认匹配用的词表，conent 要匹配的文本，以及文本的配置，用于辨认须要哪个失效地位的敏感词。如图 18：
（2）将文本中的中文、字母、数字、特殊符号抽取组合生成不同组合的文字片段，用于强过滤匹配。如图 19：
（3）依据业务线以及文本的地位将文本送到对应的字典树匹配出单个敏感词，信息蕴含敏感词、敏感词在文本中的地位、敏感词的长度，地位和长度用于多模词，词间距是否无效的计算。匹配出的后果，如图 20：
（4）通过业务线，失效地位、敏感词，从 match\_data（图 13）缓存中获取到敏感词所属的敏感词 ID，再通过敏感词 ID 从 line\_cahe 缓存中获取到敏感词的属性规定；如果匹配到的敏感词是蕴含词或者过滤词，间接命中输入；如果是多模词，则再查找多模词中的其余词是否命中，如果命中切两个词的程序和词间距满足多模词的属性规定，则命中输入。后果返回，如图 21：
6.2 大文本匹配超时解决方案
PGC 图文常常有几十万字的大文本文章过词表，因为字数太多，召回的词量能达到几万，这些词在做匹配规定计算时耗时太长，导致匹配超时。
优化计划如图 21：
（1）优化前，一个大文本文章，题目字数 100，注释 19.9w, 词表匹配时先匹配题目, 耗时 10ms，再匹配注释，因为注释字数多, 耗时 19s，最终匹配的耗时两者累加达到 20s。
（2）优化后，大文本文章过词表，先将字数超过 5000 的注释，拆成多个小于等于 5000 的注释，词表匹配时，多个文字片段并行匹配，最终耗时后果是多个并行计算中耗时最大的一个，我举的例子 50ms。
6.3 字典树（Trie 树）的实现
字典树匹配算法应用了厂内的开源 C ++ 库 dictmatch，dictmatch 实现了最简略的 Trie 树的算法，没有进行穿线改良，因而是须要回朔的。然而其应用 2 个表来示意 Trie 树，并对其占用空间大的问题进行了很大的优化，特点是在建树的时候比较慢，但在查问的时候十分快。
字典树结构，如图 23：
七、倒退 & 思考
词表特殊字符反对：当初的词表词的存储以及字典树的匹配算法对于表情及其他特殊字符不反对，词表服务下一步的优化迭代会次要放在特殊字符的反对上，可能满足更多业务的需要。
词表分业务线部署：当初词表服务 60+ 的业务方，各业务线都是混部，所有业务线的词表都在实例中加载一份，消耗内存特大，而且词表服务出问题会影响所有的业务方；如果每个业务线都分集群部署，会减少保护老本，所以咱们在摸索一种主动分业务线部署的形式。
举荐浏览 ：
|揭秘百度微服务监控：百度游戏服务监控的演进
|如何像百度直播一样优化用户体验（起播篇）
|百度搜寻稳定性问题剖析的故事（下）
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注