[confilter方案]

[tigbox]

需求：
设计&方案：
难点：

[KleeTaurus]

confilter 的核心功能是匹配，基于底层的匹配规则用户可以构建不同的上层业务形态，如：黑/白名单、敏感词汇等。

数据层面：包括词汇库、用户数据（输入）两个方面。词汇库是提前准备好数据集合（字符串），在拿到用户提交的数据后，通过特定算法实现提交数据与数据集合的匹配，从而判断是否 match。

词汇库的来源，一方面可以是提前由用户录入进去，另外可以通过程序自动补充（接口方式）。添加进来的词汇需要涵盖如下信息：

• who - 谁添加的（人或程序）
• when - 什么时候添加的
• valid thru - 有效期
• tag - 标签

每个词汇库有唯一标识及文字说明，可应用在特定的业务场景中，每个词汇库包含多个词汇的集合。词库之间可以是“与”和“或”的关系。

数据模型：

服务 => 词汇库 x n => 词汇 x n

匹配规则：对于提交数据与词汇库的匹配，支持单模式匹配和多模式匹配，单模式匹配指用户数据数据与词库中某条词汇完全一致，即认为 match。对于多模式匹配由于语义识别的限制，很难做到100%精准，那么对于匹配的结果就不能用是和否来判定，比较好的方式是计算出一个匹配的百分比来0%至100%。

服务示例：

黑白名单服务：
词库：黑名单/白名单
匹配：单模式匹配，匹配结果 0/1

敏感词汇服务：
词库：政治/色情/盗版/代充
匹配：多模式匹配，匹配结果 0/0.1/02./.../0.8/0.9/1.0

[daleione]

需求示例: 短信系统

短信测试环境, 测试人员需要加入白买单, 而生产环境需要黑名单, 防止调用方发送政治敏感词汇, 造成整个短信渠道不可用.

需求列表

• 需要手机号黑白名单
• 短信内容需要敏感词控制
• 单条响应快, 批量接口, 处理可稍慢
• 通知功能, 类似日志告警

需求描述

行业短信

• 每次发送一条短信, 鉴别手机号和内容

批量短信

• 一个批量可能有1万的手机号, 需要提供批量接口调用
• 返回结果中, 需要明确告知未通过手机号数量, 和具体的手机号集合

[daleione]

像批量短信, 和消息中心, 都是大批量的应用场景, 需要针对设计通用接口, 不然, 调用方, 一次调用鉴别一条, 效率肯定无法忍受的.

[KleeTaurus]

像批量短信, 和消息中心, 都是大批量的应用场景, 需要针对设计通用接口, 不然, 调用方, 一次调用鉴别一条, 效率肯定无法忍受的.

短信黑白名单的需求没有疑义，但是对于敏感词汇这个需求，一种是验证码类，一种是营销类。
针对验证码需要逐条进行验证，其实也可以不验证，因为这个地方发生的风险概率极低，也就是说这种场景不需要敏感词汇鉴定，发送的内容是可预知的。对于营销类的文字由于是用户根据业务需求自主定义，所以可以加上敏感词汇，目前看现阶段也不是很强烈，我们可以假设内部人不会做不利于自身的事情。

所以结论是短信当前只引入黑/白名单的服务即可。大雷提的效率问题是个关注点，对于黑白名单的 TPS 是有一定要求的。

[KleeTaurus]

需求示例：支付系统

当前苹果 IAP 充值并未提供交易详单，而其技术实现上的流程也存在弊端，对于凭据的获取是直接发送到了客户端（存在截获的可能），然后再由客户端转发至商户服务器端进行验证。当用户对购买商品不满意时可以直接通过苹果客服进行退款处理，这就导致了我们的实收小于应收，财务方面存在被欺诈的可能。

因此我们需要通过黑白名单服务，将潜在作弊的用户拉入黑名单，不允许充值操作或限制其在一定时间内不允许进行充值操作。

需求列表

虚假充值的行为识别是通过频率控制及用户行为进行识别的，对于识别后的用户，可以通过系统接口自动添加到黑名单中。

• 将用户 uid 或 设备 device_id 加入黑名单
• 加入黑名单的用户或设备可以设置拉黑时间：永久，1周/1个月/1年等
• 提供根据 uid 或 device_id 查询拉黑详情

使用场景

用户支付下单时，先通过查询黑白名单服务，验证当前用户 uid 或设备 device_id 是否被加入黑名单，如果加入，则不再创建订单，提示用户不可进行充值操作，否则按照正常业务流程处理。

[tigbox]

https://github.com/KleeTaurus/foundation-tech/blob/master/confilter/confilter.pptx

这个ppt记录了设计的梗概

• 触发job同步的逻辑（第一期，可以没有UI展现， 但是背后的api还是要有的）
• job表的设计
• 广播组件
• 词典匹配算法 （第一期可以只做单模配配，不用考虑A&B形式的多模匹配）