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

公司要對之前的pv，uv統(tǒng)計進行重構，原先的不準，而且查詢速度很慢。

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

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

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

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

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

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當資源，你知道如何能優(yōu)化成一個redis操作么？

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

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

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

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

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

必須使用同一個微服務網(wǎng)關。

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

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

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

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

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

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

每分鐘將redis的數(shù)據(jù)批量入數(shù)據(jù)庫，而不是每天統(tǒng)計一次，因為千萬級的數(shù)據(jù)統(tǒng)計不僅對oracle數(shù)據(jù)庫，而且對redis都是巨大的壓力，甚至很可能會導致讀redis超時。同時將寫數(shù)據(jù)庫的操作分配到每分鐘，降低數(shù)據(jù)庫的壓力

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

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

mq掛了

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

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

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

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