共计 1145 个字符，预计需要花费 3 分钟才能阅读完成。
以后的我的项目曾经开源，点击这里
内容平安是以后平安风控体系健身中十分重要的一环。一方面，无论是小程序还是 APP，在上架过程中面临很多监管的要求，这一环搞不好就要面临下架的危险，另一方面，关键词屏蔽自身就是业务需要的一部分，比方屏蔽某个竞对的外链等。
市面上曾经很多大的云厂商和一些专门做风控畛域的厂商提供这方面的服务，但次要存在以下的痛点：
- 思考到各种乙方使用者的通用性，无论是 API 设计和 control platform 都存在大量冗余的设计；导致一个本来非常简单的场景在付出很大的接入和保护老本；
- 当面临一些个性化的需要时，三方又不能满足，即使能给技术支持，因为排期过长时效性很差；
- 误判率高；各三方提供方有所差别；一些机器学习的模型，误判率很高，而且呈现问题后不好调整，造成很差的用户体验；
- 在量很大的状况下，每个月的老本收入还是不小的一块老本；
在此基础上，能不能设计一个即简略又不失灵便，能够满足根底的监管要求（这块次要是看关键词）又能够满足日常一些关键词屏蔽的业务需要呢？
针对下面的想法，开发一个绿盾的我的项目, 次要采纳以下三种匹配过滤形式；
- 根底的关键词匹配；这块次要是解决词库很大的状况下，匹配效率的问题；当初比拟支流的算法是应用 DFA 算法，来做词匹配；
- 另外为了解决一些关键词匹配有余的问题，提出的组合词策略；比方，在商品形容中，呈现象牙是不容许售卖的，所以把象牙加到关键词当中，然而如果呈现
象牙白和仿象牙等形容词，就会被替换成** 白通过分词能够解决一部分这个问题； - 最初还有极少量的场景，如果 1，2 都无奈解决，那么采纳正则表达式的形式来解决；
除了满足根本的匹配性能之外，还有一些定制化的性能；比方能够通过 client 通过传递的参数来匹配本人的词库；
对于工程化的一些需要：
- 对微服务形式部署的反对；如果存储到文件中，如果部署多套，那么保护老本是比拟高的；这时候尽量采纳数据库形式；
词库更新的问题；词库产生变更后，比方加词后或者删除词后，如何实现热加载。个别有两种形式：
- 通过另外一个服务被动告诉的形式；这种告诉形式能够是通过调用 API 接口，也能够是放弃长链，推送小时的形式；但不论怎么样，都会减少额定的服务；
- 服务通过定时轮询数据，比照是否产生变动；来实现自动更新；
因为服务自身定位一个轻量级的服务，如果再退出其它服务，自身就有点重了，所以最终还是定期轮询的形式来实现热更新。在一个写的频率非常低，读的频率十分高的状况下，如果每次把所有的词都加载进去，而后 diff 下，老本还是比拟高；最终抉择的计划是减少一个 words_info 的表来记录每个词库的最初更改工夫；每次加载的时候，只须要加载 words_info 表，比照每个词库的最初更改工夫，如果工夫产生变更，那么再从新加载词库，生成新的 tree 即可；
正文完
