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

46次阅读

共计 5312 个字符,预计需要花费 14 分钟才能阅读完成。

大家好,我 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):

  • 通过 KeyRedis获取记录
  • 判断该 KeyRedis的记录是否符合条件
  • 符合条件的则去重,不符合条件的则从新塞进 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);

BuilderDeduplicationService 都用了相似的写法(在子类初始化的时候指定类型,在父类对立接管,放到 Map 里治理

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

/**
 * @author huskey
 * @date 2022/1/18
 */
@Service
public 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 中解决应用 mgetpipelineSetEX就实现了实现。而 {5 分钟内雷同用户如果收到雷同的内容} 是在 SlideWindowLimitService 中解决,应用了 lua 脚本实现了实现。

LimitService的代码都来源于 @caolongxiu 的 pull request 倡议大家能够比照 commit 再学习一番:https://gitee.com/zhongfucheng/austin/pulls/19

1、频次去重采纳一般的计数去重办法,限度的是每天发送的条数。2、内容去重采纳的是新开发的基于 rediszset的滑动窗口去重,能够做到严格控制单位工夫内的频次 。3、redis 应用 lua 脚本来保障原子性和缩小网络 io 的损耗 4、rediskey 减少前缀做到数据隔离(前期可能有动静更换去重办法的需要)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

正文完
 0