共计 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）：
- 通过
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
*/
@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 中解决应用 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