點選上方IT牧場，選擇置頂或者星標

技術乾貨每日送達

今天來聊一聊拼多多的一道後臺面試真題，是一道簡單的架構類的題目：拼多多有數億的使用者，那麼對於某個網頁，怎麼使用Redis來統計一個網站的使用者訪問數呢？

使用Hash

雜湊是Redis的一種基礎資料結構，Redis底層維護的是一個開雜湊，會把不同的key對映到雜湊表上，如果是遇到關鍵字衝突，那麼就會拉出一個連結串列出來。

當一個使用者訪問的時候，如果使用者登陸過，那麼我們就使用使用者的id，如果使用者沒有登陸過，那麼我們也能夠前端頁面隨機生成一個key用來標識使用者，當用戶訪問的時候，我們可以使用HSET命令，key可以選擇URI與對應的日期進行拼湊，field可以使用使用者的id或者隨機標識，value可以簡單設定為1。

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

優點：簡單，容易實現，查詢也是非常方便，資料準確性非常高。

缺點：佔用記憶體過大，。隨著key的增多，效能也會下降。小網站還行，拼多多這種數億PV的網站肯定受不了

使用Bitset

我們知道，對於一個32位的int，如果我們只用來記錄id，那麼只能夠記錄一個使用者，但如果我們轉成2進位制，每位用來表示一個使用者，那麼我們就能夠一口氣表示32個使用者，空間節省了32倍！對於有大量資料的場景，如果我們使用bitset，那麼，可以節省非常多的記憶體。對於沒有登陸的使用者，我們也可以使用雜湊演算法，把對應的使用者標識雜湊成一個數字id。bitset非常的節省記憶體，假設有1億個使用者，也只需要100000000/8/1024/1024約等於12兆記憶體。

Redis已經為我們提供了SETBIT的方法，使用起來非常的方便，我們可以看看下面的例子，我們在item頁面可以不停地使用SETBIT命令，設定使用者已經訪問了該頁面，也可以使用GETBIT的方法查詢某個使用者是否訪問。最後我們通過BITCOUNT可以統計該網頁每天的訪問數量。

優點佔用記憶體更小，查詢方便，可以指定查詢某個使用者，資料可能略有瑕疵，對於非登陸的使用者，可能不同的key對映到同一個id，否則需要維護一個非登陸使用者的對映，有額外的開銷。

缺點如果使用者非常的稀疏，那麼佔用的記憶體可能比方法一更大。

使用概率演算法

對於拼多多這種多個頁面都可能非常多訪問量的網站，如果所需要的數量不用那麼準確，可以使用概率演算法，事實上，我們對一個網站的UV的統計，1億跟1億零30萬其實是差不多的。在Redis中，已經封裝了HyperLogLog演算法，他是一種基數評估演算法。這種演算法的特徵，一般都是資料不存具體的值，而是存用來計算概率的一些相關資料。

當用戶訪問網站的時候，我們可以使用PFADD命令，設定對應的命令，最後我們只要通過PFCOUNT就能順利計算出最終的結果，因為這個只是一個概率演算法，所以可能存在0.81%的誤差。

優點佔用記憶體極小，對於一個key，只需要12kb。對於拼多多這種超多使用者的特別適用。

缺點查詢指定使用者的時候，可能會出錯，畢竟存的不是具體的資料。總數也存在一定的誤差。

文章來源：https://url.cn/5tQPEQg

乾貨分享

最近將個人學習筆記整理成冊，使用PDF分享。關注我，回覆如下程式碼，即可獲得百度盤地址，無套路領取！

•001：《Java併發與高併發解決方案》學習筆記；•002：《深入JVM核心——原理、診斷與優化》學習筆記；•003：《Java面試寶典》•004：《Docker開源書》•005：《Kubernetes開源書》•006：《DDD速成（領域驅動設計速成）》•007：全部•008：加技術群討論

近期熱文

•LinkedBlockingQueue vs ConcurrentLinkedQueue•解讀Java 8 中為併發而生的 ConcurrentHashMap•Redis效能監控指標彙總•最全的DevOps工具集合，再也不怕選型了！•微服務架構下，解決資料庫跨庫查詢的一些思路•聊聊大廠面試官必問的 MySQL 鎖機制

關注我

喜歡就點個"在看"唄^_^