解剖屎山，尋覓黃金之第二彈
大家好，我3y啊。由于去重邏輯重構(gòu)了幾次，好多股東直呼看不懂，于是我今天再安排一波對(duì)代碼的解析吧。austin支持兩種去重的類型：N分鐘相同內(nèi)容達(dá)到N次去重和一天內(nèi)N次相同渠道頻次去重。
在最開始，我的第一版實(shí)現(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);
// 運(yùn)營(yíng)總規(guī)則去重(一天內(nèi)用戶收到最多同一個(gè)渠道的消息次數(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);
}
那時(shí)候很簡(jiǎn)單，基本主體邏輯都寫在這個(gè)入口上了，應(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ù)給封裝起來了，在最外層的代碼看起來就很簡(jiǎn)潔了。后來又跟他聊了下，他的設(shè)計(jì)思路是這樣的：考慮到以后會(huì)有其他規(guī)則的去重就把去重邏輯單獨(dú)封裝起來了，之后用策略模版的設(shè)計(jì)模式進(jìn)行了重構(gòu)，重構(gòu)后的代碼 模版不變，支持各種不同策略的去重，擴(kuò)展性更高更強(qiáng)更簡(jiǎn)潔
確實(shí)牛逼。
我基于上面的思路微改了下入口，代碼最終演變成這樣：
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ǎn)單看看去重功能的代碼結(jié)構(gòu)（這會(huì)對(duì)后面看代碼有幫助）
去重的邏輯可以統(tǒng)一抽象為：在X時(shí)間段內(nèi)達(dá)到了Y閾值，還記得我曾經(jīng)說過：「去重」的本質(zhì)：「業(yè)務(wù)Key」+「存儲(chǔ)」。那么去重實(shí)現(xiàn)的步驟可以簡(jiǎn)單分為（我這邊存儲(chǔ)就用的Redis）：
通過 Key從Redis獲取記錄判斷該 Key在Redis的記錄是否符合條件符合條件的則去重，不符合條件的則重新塞進(jìn) Redis更新記錄
為了方便調(diào)整去重的參數(shù)，我把X時(shí)間段和Y閾值都放到了配置里{"deduplication_10":{"num":1,"time":300},"deduplication_20":{"num":5}}。目前有兩種去重的具體實(shí)現(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都用了類似的寫法（在子類初始化的時(shí)候指定類型，在父類統(tǒng)一接收，放到Map里管理）
而統(tǒng)一管理著這些服務(wù)有個(gè)中心的地方，我把這取名為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)建的：
而具體的去重邏輯實(shí)現(xiàn)則都在LimitService下，{一天內(nèi)相同的用戶如果已經(jīng)收到某渠道內(nèi)容5次}是在SimpleLimitService中處理使用mget和pipelineSetEX就完成了實(shí)現(xiàn)。而{5分鐘內(nèi)相同用戶如果收到相同的內(nèi)容}是在SlideWindowLimitService中處理，使用了lua腳本完成了實(shí)現(xiàn)。
LimitService的代碼都來源于@caolongxiu的pull request，建議大家可以對(duì)比commit再學(xué)習(xí)一番：https://gitee.com/zhongfucheng/austin/pulls/19
1、頻次去重采用普通的計(jì)數(shù)去重方法，限制的是每天發(fā)送的條數(shù)。
2、內(nèi)容去重采用的是新開發(fā)的基于
redis中zset的滑動(dòng)窗口去重，可以做到嚴(yán)格控制單位時(shí)間內(nèi)的頻次。3、
redis使用lua腳本來保證原子性和減少網(wǎng)絡(luò)io的損耗4、
redis的key增加前綴做到數(shù)據(jù)隔離（后期可能有動(dòng)態(tài)更換去重方法的需求）5、把具體限流去重方法從
DeduplicationService抽取出來，DeduplicationService只需設(shè)置構(gòu)造器注入時(shí)注入的AbstractLimitService（具體限流去重服務(wù)）類型即可動(dòng)態(tài)更換去重的方法 6、使用雪花算法生成zset的唯一value,score使用的是當(dāng)前的時(shí)間戳
針對(duì)滑動(dòng)窗口去重，有會(huì)引申出新的問題：limit.lua的邏輯？為什么要移除時(shí)間窗口的之前的數(shù)據(jù)？為什么ARGV[4]參數(shù)要唯一？為什么要expire？
A: 使用滑動(dòng)窗口可以保證N分鐘達(dá)到N次進(jìn)行去重?；瑒?dòng)窗口可以回顧下TCP的，也可以回顧下刷LeetCode時(shí)的一些題，那這為什么要移除，就不陌生了。
為什么ARGV[4]要唯一，具體可以看看zadd這條命令，我們只需要保證每次add進(jìn)窗口內(nèi)的成員是唯一的，那么就不會(huì)觸發(fā)有更新的操作（我認(rèn)為這樣設(shè)計(jì)會(huì)更加簡(jiǎn)單些），而唯一Key用雪花算法比較方便。
為什么expire？，如果這個(gè)key只被調(diào)用一次。那就很有可能在redis內(nèi)存常駐了，expire能避免這種情況。
推薦項(xiàng)目
最后再叨叨吧，很多人可能會(huì)發(fā)一段截圖，跑來問我為什么要這樣寫，為什么要以這種方式實(shí)現(xiàn)，能不能以這種方式實(shí)現(xiàn)。這時(shí)候，我更想看到的是：你已經(jīng)實(shí)現(xiàn)了第二種方式了，然后探討你寫的這種方案好不好，現(xiàn)有的代碼差在哪里。
畢竟問問題很簡(jiǎn)單，我又不是客服，總不能沒誠(chéng)意的問題我都得一一回答吧。
如果想學(xué)Java項(xiàng)目的，我還是強(qiáng)烈推薦我的開源項(xiàng)目消息推送平臺(tái)Austin，可以用作畢業(yè)設(shè)計(jì)，可以用作校招，可以看看生產(chǎn)環(huán)境是怎么推送消息的。
倉(cāng)庫(kù)地址（可點(diǎn)擊閱讀原文跳轉(zhuǎn)）：https://gitee.com/zhongfucheng/austin
我開通了股東服務(wù)內(nèi)容，感興趣可以點(diǎn)擊下方看看，主要針對(duì)的是項(xiàng)目喲