关于后端:Java如何实现去重这是在炫技吗

大家好，我3y啊。因为去重逻辑重构了几次，好多股东直呼看不懂，于是我明天再安顿一波对代码的解析吧。austin反对两种去重的类型：N分钟雷同内容达到N次去重和一天内N次雷同渠道频次去重。

Java开源我的项目音讯推送平台推送下发【邮件】【短信】【微信服务号】【微信小程序】【企业微信】【钉钉】等音讯类型。

• https://gitee.com/zhongfucheng/austin/
• https://github.com/ZhongFuCheng3y/austin

在最开始，我的第一版实现是这样的：

public void duplication(TaskInfo taskInfo) {    // 配置示例:{"contentDeduplication":{"num":1,"time":300},"frequencyDeduplication":{"num":5}}    JSONObject property = JSON.parseObject(config.getProperty(DEDUPLICATION_RULE_KEY, AustinConstant.APOLLO_DEFAULT_VALUE_JSON_OBJECT));    JSONObject contentDeduplication = property.getJSONObject(CONTENT_DEDUPLICATION);    JSONObject frequencyDeduplication = property.getJSONObject(FREQUENCY_DEDUPLICATION);    // 文案去重    DeduplicationParam contentParams = DeduplicationParam.builder()        .deduplicationTime(contentDeduplication.getLong(TIME))        .countNum(contentDeduplication.getInteger(NUM)).taskInfo(taskInfo)        .anchorState(AnchorState.CONTENT_DEDUPLICATION)        .build();    contentDeduplicationService.deduplication(contentParams);    // 经营总规定去重(一天内用户收到最多同一个渠道的音讯次数)    Long seconds = (DateUtil.endOfDay(new Date()).getTime() - DateUtil.current()) / 1000;    DeduplicationParam businessParams = DeduplicationParam.builder()        .deduplicationTime(seconds)        .countNum(frequencyDeduplication.getInteger(NUM)).taskInfo(taskInfo)        .anchorState(AnchorState.RULE_DEDUPLICATION)        .build();    frequencyDeduplicationService.deduplication(businessParams);}

那时候很简略，根本主体逻辑都写在这个入口上了，应该都能看得懂。起初，群里滴滴哥示意这种代码不行，不能一眼看进去它干了什么。于是怒提了一波pull request重构了一版，入口是这样的：

public void duplication(TaskInfo taskInfo) {        // 配置样例：{"contentDeduplication":{"num":1,"time":300},"frequencyDeduplication":{"num":5}}    String deduplication = config.getProperty(DeduplicationConstants.DEDUPLICATION_RULE_KEY, AustinConstant.APOLLO_DEFAULT_VALUE_JSON_OBJECT);        //去重    DEDUPLICATION_LIST.forEach(        key -> {            DeduplicationParam deduplicationParam = builderFactory.select(key).build(deduplication, key);            if (deduplicationParam != null) {                deduplicationParam.setTaskInfo(taskInfo);                DeduplicationService deduplicationService = findService(key + SERVICE);                deduplicationService.deduplication(deduplicationParam);            }        }    );}

我猜测他的思路就是把构建去重参数和抉择具体的去重服务给封装起来了，在最外层的代码看起来就很简洁了。起初又跟他聊了下，他的设计思路是这样的：思考到当前会有其余规定的去重就把去重逻辑独自封装起来了，之后用策略模版的设计模式进行了重构，重构后的代码 模版不变，反对各种不同策略的去重，扩展性更高更强更简洁

的确牛逼。

我基于下面的思路微改了下入口，代码最终演变成这样：

public void duplication(TaskInfo taskInfo) {    // 配置样例：{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}    String deduplicationConfig = config.getProperty(DEDUPLICATION_RULE_KEY, CommonConstant.EMPTY_JSON_OBJECT);    // 去重    List<Integer> deduplicationList = DeduplicationType.getDeduplicationList();    for (Integer deduplicationType : deduplicationList) {        DeduplicationParam deduplicationParam = deduplicationHolder.selectBuilder(deduplicationType).build(deduplicationConfig, taskInfo);        if (Objects.nonNull(deduplicationParam)) {            deduplicationHolder.selectService(deduplicationType).deduplication(deduplicationParam);        }    }}

到这，应该大多数人还能跟上吧？在讲具体的代码之前，咱们先来简略看看去重性能的代码构造（这会对前面看代码有帮忙）

去重的逻辑能够对立形象为：在X时间段内达到了Y阈值，还记得我已经说过：「去重」的实质：「业务Key」+「存储」。那么去重实现的步骤能够简略分为（我这边存储就用的Redis）：

• 通过Key从Redis获取记录
• 判断该Key在Redis的记录是否符合条件
• 符合条件的则去重，不符合条件的则从新塞进Redis更新记录

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

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

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

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

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

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

而对立治理着这些服务有个核心的中央，我把这取名为DeduplicationHolder

/** * @author huskey * @date 2022/1/18 */@Servicepublic class DeduplicationHolder {    private final Map<Integer, Builder> builderHolder = new HashMap<>(4);    private final Map<Integer, DeduplicationService> serviceHolder = new HashMap<>(4);    public Builder selectBuilder(Integer key) {        return builderHolder.get(key);    }    public DeduplicationService selectService(Integer key) {        return serviceHolder.get(key);    }    public void putBuilder(Integer key, Builder builder) {        builderHolder.put(key, builder);    }    public void putService(Integer key, DeduplicationService service) {        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应用的是以后的工夫戳

针对滑动窗口去重，有会引申出新的问题：limit.lua的逻辑？为什么要移除工夫窗口的之前的数据？为什么ARGV[4]参数要惟一？为什么要expire？

A: 应用滑动窗口能够保障N分钟达到N次进行去重。滑动窗口能够回顾下TCP的，也能够回顾下刷LeetCode时的一些题，那这为什么要移除，就不生疏了。

为什么ARGV[4]要惟一，具体能够看看zadd这条命令，咱们只须要保障每次add进窗口内的成员是惟一的，那么就不会触发有更新的操作（我认为这样设计会更加简略些），而惟一Key用雪花算法比拟不便。

为什么expire？，如果这个key只被调用一次。那就很有可能在redis内存常驻了，expire能防止这种状况。

如果想学Java我的项目的，强烈推荐我的我的项目音讯推送平台Austin（8K stars），能够用作毕业设计**，能够用作校招，能够看看生产环境是怎么推送音讯的。音讯推送平台推送下发【邮件】【短信】【微信服务号】【微信小程序】【企业微信】【钉钉】等音讯类型**。

• https://gitee.com/zhongfucheng/austin/
• https://github.com/ZhongFuCheng3y/austin