redis中怎么統(tǒng)計獨立用戶訪問量，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

10年積累的網(wǎng)站建設(shè)、成都做網(wǎng)站經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先網(wǎng)站設(shè)計后付款的網(wǎng)站建設(shè)流程，更有奉節(jié)免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

使用Hash

哈希是Redis的一種基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，Redis底層維護的是一個開散列，會把不同的key映射到哈希表上，如果是遇到關(guān)鍵字沖突，那么就會拉出一個鏈表出來。

當一個用戶訪問的時候，如果用戶登陸過，那么我們就使用用戶的id，如果用戶沒有登陸過，那么我們也能夠前端頁面隨機生成一個key用來標識用戶。

當用戶訪問的時候，我們可以使用HSET命令，key可以選擇URI與對應(yīng)的日期進行拼湊，field可以使用用戶的id或者隨機標識，value可以簡單設(shè)置為1。

當我們要統(tǒng)計某一個網(wǎng)站某一天的訪問量的時候，就可以直接使用HLEN來得到最終的結(jié)果了。

優(yōu)點：簡單，容易實現(xiàn)，查詢也是非常方便，數(shù)據(jù)準確性非常高。

缺點：占用內(nèi)存過大，。隨著key的增多，性能也會下降。小網(wǎng)站還行，拼多多這種數(shù)億PV的網(wǎng)站肯定受不了。

使用Bitset

我們知道，對于一個32位的int，如果我們只用來記錄id，那么只能夠記錄一個用戶，但如果我們轉(zhuǎn)成2進制，每位用來表示一個用戶，那么我們就能夠一口氣表示32個用戶，空間節(jié)省了32倍!

對于有大量數(shù)據(jù)的場景，如果我們使用bitset，那么可以節(jié)省非常多的內(nèi)存。

對于沒有登陸的用戶，我們也可以使用哈希算法，把對應(yīng)的用戶標識哈希成一個數(shù)字id。bitset非常的節(jié)省內(nèi)存，假設(shè)有1億個用戶，也只需要100000000/8/1024/1024約等于12兆內(nèi)存。

Redis已經(jīng)為我們提供了SETBIT的方法，使用起來非常的方便，我們可以看看下面的例子。

我們在item頁面可以不停地使用SETBIT命令，設(shè)置用戶已經(jīng)訪問了該頁面，也可以使用GETBIT的方法查詢某個用戶是否訪問。最后我們通過BITCOUNT可以統(tǒng)計該網(wǎng)頁每天的訪問數(shù)量。

優(yōu)點：占用內(nèi)存更小，查詢方便，可以指定查詢某個用戶，數(shù)據(jù)可能略有瑕疵，對于非登陸的用戶，可能不同的key映射到同一個id，否則需要維護一個非登陸用戶的映射，有額外的開銷。

缺點：如果用戶非常的稀疏，那么占用的內(nèi)存可能比方法一更大。

使用概率算法

對于拼多多這種多個頁面都可能非常多訪問量的網(wǎng)站，如果所需要的數(shù)量不用那么準確，可以使用概率算法。

事實上，我們對一個網(wǎng)站的UV的統(tǒng)計，1億跟1億零30萬其實是差不多的。

在Redis中，已經(jīng)封裝了HyperLogLog算法，他是一種基數(shù)評估算法。這種算法的特征，一般都是數(shù)據(jù)不存具體的值，而是存用來計算概率的一些相關(guān)數(shù)據(jù)。

當用戶訪問網(wǎng)站的時候，我們可以使用PFADD命令，設(shè)置對應(yīng)的命令，最后我們只要通過PFCOUNT就能順利計算出最終的結(jié)果，因為這個只是一個概率算法，所以可能存在0.81%的誤差。

優(yōu)點：占用內(nèi)存極小，對于一個key，只需要12kb。對于拼多多這種超多用戶的特別適用。

缺點：查詢指定用戶的時候，可能會出錯，畢竟存的不是具體的數(shù)據(jù)。總數(shù)也存在一定的誤差。

關(guān)于Redis中怎么統(tǒng)計獨立用戶訪問量問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。