到这，应该大多数人还能跟上吧？在讲具体的代码之前，我们先来简单看看去重功能的代码结构（这会对后面看代码有帮助）

去重的逻辑可以统一抽象为：在X时间段内达到了Y阈值，还记得我曾经说过：「去重」的本质：「业务Key」+「存储」。那么去重实现的步骤可以简单分为（我这边存储就用的Redis）：

为了方便调整去重的参数，我把X时间段和Y阈值都放到了配置里{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}。目前有两种去重的具体实现：

1、5分钟内相同用户如果收到相同的内容，则应该被过滤掉

2、一天内相同的用户如果已经收到某渠道内容5次，则应该被过滤掉

从配置中心拿到配置信息了以后，Builder就是根据这两种类型去构建出DeduplicationParam，就是以下代码：

DeduplicationParamdeduplicationParam=deduplicationHolder.selectBuilder(deduplicationType).build(deduplicationConfig,taskInfo);

Builder和DeduplicationService都用了类似的写法（在子类初始化的时候指定类型，在父类统一接收，放到Map里管理）

而统一管理着这些服务有个中心的地方，我把这取名为DeduplicationHolder

/***@authorhuskey*@date2022/1/18*/@ServicepublicclassDeduplicationHolder{privatefinalMapbuilderHolder=newHashMap<>(4);privatefinalMapserviceHolder=newHashMap<>(4);publicBuilderselectBuilder(Integerkey){returnbuilderHolder.get(key);}publicDeduplicationServiceselectService(Integerkey){returnserviceHolder.get(key);}publicvoidputBuilder(Integerkey,Builderbuilder){builderHolder.put(key,builder);}publicvoidputService(Integerkey,DeduplicationServiceservice){serviceHolder.put(key,service);}}

前面提到的业务Key，是在AbstractDeduplicationService的子类下构建的：

而具体的去重逻辑实现则都在LimitService下，{一天内相同的用户如果已经收到某渠道内容5次}是在SimpleLimitService中处理使用mget和pipelineSetEX就完成了实现。而{5分钟内相同用户如果收到相同的内容}是在SlideWindowLimitService中处理，使用了lua脚本完成了实现。

LimitService的代码都来源于@caolongxiu的pull request，建议大家可以对比commit再学习一番：https://gitee.com/zhongfucheng/austin/pulls/19

1、频次去重采用普通的计数去重方法，限制的是每天发送的条数。

2、内容去重采用的是新开发的基于redis中zset的滑动窗口去重，可以做到严格控制单位时间内的频次。

3、redis使用lua脚本来保证原子性和减少网络io的损耗

4、redis的key增加前缀做到数据隔离（后期可能有动态更换去重方法的需求）

5、把具体限流去重方法从DeduplicationService抽取出来，DeduplicationService只需设置构造器注入时注入的AbstractLimitService（具体限流去重服务）类型即可动态更换去重的方法 6、使用雪花算法生成zset的唯一value,score使用的是当前的时间戳