内容安全是当前安全风控体系健身中非常重要的一环。一方面，无论是小程序还是APP，在上架过程中面临很多监管的要求，这一环搞不好就要面临下架的风险，另一方面，关键词屏蔽本身就是业务需求的一部分，比如屏蔽某个竞对的外链等。
市面上已经很多大的云厂商和一些专门做风控领域的厂商提供这方面的服务，但主要存在以下的痛点：
- 考虑到各种乙方使用者的通用性，无论是API设计和control platform都存在大量冗余的设计；导致一个原本非常简单的场景在付出很大的接入和维护成本；
- 当面临一些个性化的需求时，三方又不能满足，即便能给技术支持，因为排期过长时效性很差；
- 误判率高；各三方提供方有所差异；一些机器学习的模型，误判率很高，而且出现问题后不好调整，造成很差的用户体验；
- 在量很大的情况下，每个月的成本支出还是不小的一块成本；
在此基础上，能不能设计一个即简单又不失灵活，可以满足基础的监管要求（这块主要是看关键词）又可以满足日常一些关键词屏蔽的业务需求呢？
针对上面的想法，开发一个绿盾的项目, 主要采用以下三种匹配过滤方式；
- 基础的关键词匹配；这块主要是解决词库很大的情况下，匹配效率的问题；现在比较主流的算法是使用DFA算法，来做词匹配；
- 另外为了解决一些关键词匹配不足的问题，提出的组合词策略；比如，在商品描述中，出现象牙是不允许售卖的，所以把象牙加到关键词当中，但是如果出现
象牙白和仿象牙等描述词，就会被替换成**白通过分词可以解决一部分这个问题； - 最后还有极少量的场景，如果1，2都无法解决，那么采用正则表达式的方式来解决；
除了满足基本的匹配功能之外，还有一些定制化的功能；比如可以通过client通过传递的参数来匹配自己的词库；
对于工程化的一些需求：
- 对微服务方式部署的支持； 如果存储到文件中，如果部署多套，那么维护成本是比较高的；这时候尽量采用数据库方式；
词库更新的问题； 词库发生变更后，比如加词后或者删除词后，如何实现热加载。一般有两种方式：
- 通过另外一个服务主动通知的方式；这种通知方式可以是通过调用API接口，也可以是保持长链，推送小时的方式；但不管怎么样，都会增加额外的服务；
- 服务通过定时轮询数据，对比是否发生变动；来实现自动更新；
因为服务本身定位一个轻量级的服务，如果再加入其它服务，本身就有点重了，所以最终还是定期轮询的方式来实现热更新。在一个写的频率非常低，读的频率非常高的情况下，如果每次把所有的词都加载出来，然后diff下，成本还是比较高；最终选择的方案是增加一个words_info的表来记录每个词库的最后更改时间；每次加载的时候，只需要加载words_info表，对比每个词库的最后更改时间，如果时间发生变更，那么再重新加载词库，生成新的tree即可；
