摘要：瀏覽器指紋是根據(jù)客戶端的一些參數(shù)計(jì)算而成，業(yè)內(nèi)已經(jīng)有成熟解決方案，準(zhǔn)確率能達(dá)到優(yōu)化入統(tǒng)計(jì)時(shí)入的操作，重新設(shè)計(jì)的數(shù)據(jù)格式，將次縮減為次。

公司要對(duì)之前的pv，uv統(tǒng)計(jì)進(jìn)行重構(gòu)，原先的不準(zhǔn)，而且查詢速度很慢。

經(jīng)調(diào)研發(fā)現(xiàn)這絕對(duì)是一個(gè)坑，pv、uv統(tǒng)計(jì)存在的設(shè)計(jì)看起來簡單，但是瞬間流量大，特別是有搶購等功能時(shí)，設(shè)計(jì)不良會(huì)導(dǎo)致數(shù)據(jù)庫訪問壓力大，還存在被用心不良者利用等情況。

系統(tǒng)原先設(shè)計(jì)是將用戶的請求放到redis中去，而后每天晚上一次將數(shù)據(jù)同步到數(shù)據(jù)庫，在redis中并沒有保存每個(gè)用戶的訪問時(shí)間，而只是保存的是每分鐘有多少pv、uv。
這種設(shè)計(jì)存在這樣一些問題：

只統(tǒng)計(jì)到分鐘，并不統(tǒng)計(jì)每個(gè)訪問的具體時(shí)間，數(shù)據(jù)參考價(jià)值有限

對(duì)pv的查詢會(huì)從redis中查一部分，從數(shù)據(jù)庫中再查一部分，合并起來返回前端，開發(fā)實(shí)現(xiàn)上代碼比較復(fù)雜。更別說在數(shù)據(jù)庫中查詢居然是用where min=xx來實(shí)現(xiàn)，1000分鐘時(shí)間段的查詢會(huì)查詢1000次數(shù)據(jù)庫，查詢返回奇慢無比，能寫出這個(gè)sql的簡直是天才。

統(tǒng)計(jì)一次pv的redis操作要操作6次，數(shù)據(jù)結(jié)構(gòu)的使用上存在問題。

redisTemplate.opsForValue().increment(nowMin,1);
int pv = redisTemplate.opsForValue().get(nowMin);
redisTemplate.opsForHash().put(PV_KEY, nowMin, pv);
redisTemplate.opsForSet().put(nowMin,uid);
int uv = redisTemplate.opsForSet().size(nowMin);
redisTemplate.opsForHash().put(UV_KEY, nowMin, pv);

原代碼甚至要8次，這里無力吐槽，完全不把redis當(dāng)資源，你知道如何能優(yōu)化成一個(gè)redis操作么？

而且進(jìn)行pv,uv統(tǒng)計(jì)肯定是要精確到用戶的，這樣才能看出什么用戶進(jìn)行了什么訪問，方便后期的用戶畫像以及訪問數(shù)統(tǒng)計(jì)。但如此一來帶來的問題就是

數(shù)據(jù)庫記錄會(huì)急劇增長，以前只是統(tǒng)計(jì)分鐘，一天也就1000+條數(shù)據(jù)，而如果粒度是細(xì)到用戶的話，如果PV到千萬級(jí)，即使每天同步也受不了

實(shí)時(shí)查詢會(huì)從redis中取數(shù)據(jù)，redis中資源本來就稀缺，如果每天同步一次，意味著要從redis中取百萬、甚至千萬級(jí)數(shù)據(jù)，不僅同步會(huì)非常慢，而且無法滿足實(shí)時(shí)查詢的需求。

系統(tǒng)本身存在如下限制

必須使用oracle數(shù)據(jù)庫，而且pv表與業(yè)務(wù)表就在同一個(gè)實(shí)例，要考慮不能有瞬時(shí)過大的流量影響到業(yè)務(wù)操作。

必須使用同一個(gè)微服務(wù)網(wǎng)關(guān)。

經(jīng)思考實(shí)現(xiàn)了如下方案：

使用瀏覽器指紋來記錄每一個(gè)用戶，來記錄uv，而不是使用用戶id，將pv、uv統(tǒng)計(jì)與業(yè)務(wù)隔離。瀏覽器指紋是根據(jù)客戶端的一些參數(shù)計(jì)算而成，業(yè)內(nèi)已經(jīng)有成熟解決方案，準(zhǔn)確率能達(dá)到94%

優(yōu)化入統(tǒng)計(jì)pv、uv時(shí)入redis的操作，重新設(shè)計(jì)redis的數(shù)據(jù)格式，將6次縮減為1次。

redisTemplate.opsForHash().put(bizKey, devFinger + dateTime);

只需一次redis操作, 落到數(shù)據(jù)庫后用group by查詢就能非常方便的按照分鐘，小時(shí)，天來分組了

請求進(jìn)來后不直接入庫，也不直接入redis，而是放入mq，通過mq再入redis，起到削峰填谷的作用。測試環(huán)境redis存的速度大概能達(dá)到 3w/s， 3w的qps，taobao搶購系統(tǒng)恐怕都支撐起來了。

每分鐘將redis的數(shù)據(jù)批量入數(shù)據(jù)庫，而不是每天統(tǒng)計(jì)一次，因?yàn)榍f級(jí)的數(shù)據(jù)統(tǒng)計(jì)不僅對(duì)oracle數(shù)據(jù)庫，而且對(duì)redis都是巨大的壓力，甚至很可能會(huì)導(dǎo)致讀redis超時(shí)。同時(shí)將寫數(shù)據(jù)庫的操作分配到每分鐘，降低數(shù)據(jù)庫的壓力

查詢只從數(shù)據(jù)庫中查，加上對(duì)應(yīng)的索引，查詢數(shù)據(jù)不會(huì)太慢。同時(shí)也降低了程序的復(fù)雜性，不用到redis中查了。

壓測發(fā)現(xiàn)有兩個(gè)問題

mq掛了

同步到數(shù)據(jù)庫時(shí)數(shù)據(jù)庫也處理不過來。

我們mq是公用的，就是說所有的服務(wù)，而且不止我們的服務(wù)，都用到了mq，而pv,uv操作是一個(gè)超級(jí)大數(shù)量級(jí)別的操作，而且并非核心業(yè)務(wù)，所以不能把主要的資源都放到mq上，所以我們又繼續(xù)進(jìn)行了處理：

后端用了緩存隊(duì)列，當(dāng)pv滿足10個(gè)的時(shí)候才發(fā)送，否則不發(fā)。此處要加synchonize,否則會(huì)出現(xiàn)異常的

數(shù)據(jù)庫同步時(shí)做了柔性處理，當(dāng)pv數(shù)據(jù)量過大的時(shí)候不處理，而是延后再做，等到pv量降下來后再處理