字符串多模式精确匹配（脏字/敏感词汇搜索算法）之算法前传

最新推荐文章于 2024-11-16 17:37:48 发布

原创

最新推荐文章于 2024-11-16 17:37:48 发布 · 1.4k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#算法 #多线程 #服务器 #任务 #string #工作

本文探讨了在敏感词过滤中，除了算法本身，哪些因素可能影响性能。首先提到了脏字表的重复排重处理，通过简单代码实现降低重复带来的额外成本。接着讨论了是否需要转换为最小脏字集，取决于任务需求。还提到了在读取待检文本时可能存在的CPU等待IO问题，以及利用多线程提高检索性能的注意事项，避免多进程同时处理同一文本。最后，作者指出分布式处理在大多数情况下并非必需，优化服务器硬件和多线程可能更为实际。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前面一篇稍微说了一下我自造的TTMP算法思路，貌似很好很强大——估计不是最强的，不过至少我自己觉得比较满意了，至少算是达到可用级别了。那么还有啥好写的呢？好久没有写这种类型的技术文章了，满脑子的想法：

　　1、除了算法本身，还有什么是效率损耗点？

　　2、TTMP算法本身也只是讲了一个大概，远没有详细到论文级别，抽空可以给大家详细讲一下。

　　3、其实上次说到的TTMP算法，还有至少2种实现方式，分别是前向检索和后向检索两种模式，他们都有什么区别呢？

　　嗯，今天的主题就是第一个：我们先抛开算法本身，看看还有什么会影响我们的性能的。

当我们进行敏感词过滤得时候，必然涉及3个要件：

　　1、脏字表

　　2、待检文本

　　3、检索过程

　　首先说脏字表的问题。通常来说，这个脏字表不是我们发明的，我们没事情搞这个图啥啊？不是自找麻烦么。这个问题通常是有人要求你这么这么干，于是你不得不那么那么干。所以，通常会有人给你一个脏字表。可是通常给你的人不是一个人，又或者说给你的文件格式乱七八糟。那么于是乎就有一个条目重复的问题！对于这个问题，可能有人是自己整理出一个没有重复的表。而我却觉得这个整理通常很费工夫，还不如让程序给整整。这样做有两个好处：

　　1、我们不必担心人家给你的文本就是有重复的。

　　2、当又有新的脏字表文本时，直接粘到原来的文本结尾即可，可以节省整理的人工成本。

　　于是，我们启动脏字过滤的过程时，首先第一个需要做的，就是排除重复。当然了，这个排重的过程也是一个性能损耗点，然而通常这个过程耗时相对来说还算可以接受，而且做一次这种操作，可以检索起码几百上千的文章，平均下来几乎可以认为没有任何的成本。这个过程很简单只要用下面的几句代码就可以完成了（用 HashSet也一样的）：

　　　　　　　　　 Dictionary<string, string> fixKeys = new Dictionary<string, string>(StringComparer.InvariantCul