Java實現(xiàn)去重的方法詳解
在最開始,我的第一版實現(xiàn)是這樣的:
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);
?
?
? ?// 運營總規(guī)則去重(一天內(nèi)用戶收到最多同一個渠道的消息次數(shù))
? ?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);
}那時候很簡單,基本主體邏輯都寫在這個入口上了,應(yīng)該都能看得懂。后來,群里滴滴哥表示這種代碼不行,不能一眼看出來它干了什么。于是怒提了一波pull request重構(gòu)了一版,入口是這樣的:
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);
? ? ? ? ? }
? ? ? }
? );
}我猜想他的思路就是把構(gòu)建去重參數(shù)和選擇具體的去重服務(wù)給封裝起來了,在最外層的代碼看起來就很簡潔了。后來又跟他聊了下,他的設(shè)計思路是這樣的:考慮到以后會有其他規(guī)則的去重就把去重邏輯單獨封裝起來了,之后用策略模版的設(shè)計模式進(jìn)行了重構(gòu),重構(gòu)后的代碼 模版不變,支持各種不同策略的去重,擴展性更高更強更簡潔
確實牛逼。
我基于上面的思路微改了下入口,代碼最終演變成這樣:
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);
? ? ? }
? }
}到這,應(yīng)該大多數(shù)人還能跟上吧?在講具體的代碼之前,我們先來簡單看看去重功能的代碼結(jié)構(gòu)(這會對后面看代碼有幫助)

去重的邏輯可以統(tǒng)一抽象為:在X時間段內(nèi)達(dá)到了Y閾值,還記得我曾經(jīng)說過:「去重」的本質(zhì):「業(yè)務(wù)Key」+「存儲」。那么去重實現(xiàn)的步驟可以簡單分為(我這邊存儲就用的Redis):
- 通過
Key從Redis獲取記錄 - 判斷該
Key在Redis的記錄是否符合條件 - 符合條件的則去重,不符合條件的則重新塞進(jìn)
Redis更新記錄
為了方便調(diào)整去重的參數(shù),我把X時間段和Y閾值都放到了配置里{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}。目前有兩種去重的具體實現(xiàn):
1、5分鐘內(nèi)相同用戶如果收到相同的內(nèi)容,則應(yīng)該被過濾掉
2、一天內(nèi)相同的用戶如果已經(jīng)收到某渠道內(nèi)容5次,則應(yīng)該被過濾掉
從配置中心拿到配置信息了以后,Builder就是根據(jù)這兩種類型去構(gòu)建出DeduplicationParam,就是以下代碼:
DeduplicationParam deduplicationParam = deduplicationHolder.selectBuilder(deduplicationType).build(deduplicationConfig, taskInfo);
Builder和DeduplicationService都用了類似的寫法(在子類初始化的時候指定類型,在父類統(tǒng)一接收,放到Map里管理)


而統(tǒng)一管理著這些服務(wù)有個中心的地方,我把這取名為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);
? }
}
前面提到的業(yè)務(wù)Key,是在AbstractDeduplicationService的子類下構(gòu)建的:

而具體的去重邏輯實現(xiàn)則都在LimitService下,{一天內(nèi)相同的用戶如果已經(jīng)收到某渠道內(nèi)容5次}是在SimpleLimitService中處理使用mget和pipelineSetEX就完成了實現(xiàn)。而{5分鐘內(nèi)相同用戶如果收到相同的內(nèi)容}是在SlideWindowLimitService中處理,使用了lua腳本完成了實現(xiàn)。

LimitService的代碼都來源于@caolongxiu的pull request,建議大家可以對比commit再學(xué)習(xí)一番:gitee.com/zhongfucheng/austin/pulls/19
1、頻次去重采用普通的計數(shù)去重方法,限制的是每天發(fā)送的條數(shù)。
2、內(nèi)容去重采用的是新開發(fā)的基于redis中zset的滑動窗口去重,可以做到嚴(yán)格控制單位時間內(nèi)的頻次。
3、redis使用lua腳本來保證原子性和減少網(wǎng)絡(luò)io的損耗
4、redis的key增加前綴做到數(shù)據(jù)隔離(后期可能有動態(tài)更換去重方法的需求)
5、把具體限流去重方法從DeduplicationService抽取出來,DeduplicationService只需設(shè)置構(gòu)造器注入時注入的AbstractLimitService(具體限流去重服務(wù))類型即可動態(tài)更換去重的方法
6、使用雪花算法生成zset的唯一value,score使用的是當(dāng)前的時間戳
針對滑動窗口去重,有會引申出新的問題:limit.lua的邏輯?為什么要移除時間窗口的之前的數(shù)據(jù)?為什么ARGV[4]參數(shù)要唯一?為什么要expire?

A: 使用滑動窗口可以保證N分鐘達(dá)到N次進(jìn)行去重?;瑒哟翱诳梢曰仡櫹?code>TCP的,也可以回顧下刷LeetCode時的一些題,那這為什么要移除,就不陌生了。
為什么ARGV[4]要唯一,具體可以看看zadd這條命令,我們只需要保證每次add進(jìn)窗口內(nèi)的成員是唯一的,那么就不會觸發(fā)有更新的操作(我認(rèn)為這樣設(shè)計會更加簡單些),而唯一Key用雪花算法比較方便。
為什么expire?,如果這個key只被調(diào)用一次。那就很有可能在redis內(nèi)存常駐了,expire能避免這種情況。
以上就是Java實現(xiàn)去重的方法詳解的詳細(xì)內(nèi)容,更多關(guān)于Java去重的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
springboot與vue實現(xiàn)簡單的CURD過程詳析
這篇文章主要介紹了springboot與vue實現(xiàn)簡單的CURD過程詳析,圍繞springboot與vue的相關(guān)資料展開實現(xiàn)CURD過程的過程介紹,需要的小伙伴可以參考一下2022-01-01
spring?IOC容器管理必須知道的一些操作(基于XML方式)
Spring框架的核心是Spring容器,容器創(chuàng)建對象,將它們裝配在一起,配置它們并管理它們的完整生命周期,下面這篇文章主要給大家介紹了關(guān)于spring?IOC容器管理必須知道的一些操作,需要的朋友可以參考下2022-03-03
springboot 默認(rèn)靜態(tài)路徑實例解析
這篇文章主要介紹了springboot 默認(rèn)靜態(tài)路徑實例解析,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下2019-11-11

