用最小的空間統計存儲一億用戶的活躍度

1

前段時間，在網上看到一道面試題：

如何用redis存儲統計1億用戶一年的登錄狀況，並快速檢索任意時間窗口內的活躍用戶數量。

以爲頗有意思，就仔細想了下 。並作了一系列實驗，本身模擬了下 。仍是有點收穫的，現整理下來。和你們一塊兒分享。

Redis是一個內存數據庫，採用單線程和事件驅動的機制來處理網絡請求。實際生產的QPS和TPS單臺都能達到3,4W，讀寫性能很是棒。用來存儲一些對核心業務弱影響的用戶狀態信息仍是很是不錯的。

對於這題，有2個重要的點須要考慮：

1.如何用合適的數據類型來存儲1億用戶的數據，用普通的字符串來存儲確定不行。通過查看一個最簡單的kv(key爲aaa，value爲1)的內存佔用，發現爲48byte。

假設每一個用戶天天登錄須要佔據1對KV的話，那一億就是(48*100000000)/1024/1024/1024=4.47G。這仍是一天的量。

2.如何知足搜索，redis是一個鍵值對的內存結構，只能根據key來進行定位value值，沒法作到像elastic search那樣對文檔進行倒排索引快速全文檢索。

redis其實有這種數據結構的，能夠以不多的空間來存儲大量的信息。

2

在redis 2.2.0版本以後，新增了一個位圖數據，其實它不是一種數據結構。實際上它就是一個一個字符串結構，只不過value是一個二進制數據，每一位只能是0或者1。redis單獨對bitmap提供了一套命令。能夠對任意一位進行設置和讀取。

bitmap的核心命令：

SETBIT

語法：SETBIT key offset value

例如：

setbit abc 5 1 ----> 00001

setbit abc 2 1 ----> 00101

GETBIT

語法：GETBIT key offset

例如：

getbit abc 5 ----> 1

getbit abc 1 ----> 0

bitmap的其餘命令還有bitcount，bitcount，bitpos，bitop等命令。都是對位的操做。

由於bitmap的每一位只佔據1bit的空間 ，因此利用這個特性咱們能夠把每一天做爲key，value爲1億用戶的活躍度狀態。假設一個用戶一天內只要登陸了一次就算活躍。活躍咱們就記爲1，不活躍咱們就記爲0。把用戶Id做爲偏移量(offset)。這樣咱們一個key就能夠存儲1億用戶的活躍狀態。

咱們再來算下，這樣一個位圖結構的值對象佔據多少空間。每個位是1bit，一億用戶就是一億bit。8bit=1Byte

100000000/8/1024/1024=11.92M

我用測試工程往一個key裏經過lua塞進了1億個bit，而後用rdb tools對內存進行統計，實測以下：

一天1億用戶也就消耗12M的內存空間。這徹底符合要求。1年的話也就4個G。幾年下來的話，redis能夠集羣部署來進行擴容存儲。咱們也能夠用位圖壓縮算法對bitmap進行壓縮存儲。例如WAH，EWAH，Roaring Bitmaps。這個之後能夠單獨拉出來聊聊。

咱們把每一天1億用戶的登錄狀態都用bitmap的形式存進了redis，那要獲取某一天id爲88000的用戶是否活躍，直接使用getbit命令：

getbit 2020-01-01 88000 [時間複雜度爲O(1)]

若是要統計某一天的全部的活躍用戶數，使用bitcount命令，bitcount能夠統計1的個數，也就是活躍用戶數：

bitcount 2019-01-01 [時間複雜度爲O(N)]

若是要統計某一段時間內的活躍用戶數，須要用到bitop命令。這個命令提供四種位運算，AND(與)，(OR)或，XOR(亦或)，NOT(非)。咱們能夠對某一段時間內的全部key進行OR(或)操做，或操做出來的位圖是0的就表明這段時間內一次都沒有登錄的用戶。那隻要咱們求出1的個數就能夠了。如下例子求出了2019-01-01到2019-01-05這段時間內的活躍用戶數。

bitop or result 2019-01-01 2019-01-02 2019-01-03 2019-01-04 2019-01-05 [時間複雜度爲O(N)]

bitcount result

從時間複雜度上說，不管是統計某一天，仍是統計一段時間。在實際測試時，基本上都是秒出的。符合咱們的預期。

3

bitmap能夠很好的知足一些須要記錄大量而簡單信息的場景。所佔空間十分小。一般來講使用場景分2類：

1.某一業務對象的橫向擴展，key爲某一個業務對象的id，好比記錄某一個終端的功能開關，1表明開，0表明關。基本能夠無限擴展，能夠記錄2^32個位信息。不過這種用法因爲key上帶有了業務對象的id，致使了key的存儲空間大於了value的存儲空間，從空間使用角度上來看有必定的優化空間。

2.某一業務的縱向擴展，key爲某一個業務，把每個業務對象的id做爲偏移量記錄到位上。這道面試題的例子就是用此法來進行解決。十分巧妙的利用了用戶的id做爲偏移量來找到相對應的值。當業務對象數量超過2^32時（約等於42億），還能夠分片存儲。

看起來bitmap完美的解決了存儲和統計的問題。那有沒有比這個更加省空間的存儲嗎？

答案是有的。

4

redis從2.8.9以後增長了HyperLogLog數據結構。這個數據結構，根據redis的官網介紹，這是一個機率數據結構，用來估算數據的基數。能經過犧牲準確率來減小內存空間的消耗。

咱們先來看看HyperLogLog的方法

PFADD 添加一個元素，若是重複，只算做一個

PFCOUNT 返回元素數量的近似值

PFMERGE 將多個 HyperLogLog 合併爲一個 HyperLogLog

這很好理解，是否是。那咱們就來看看一樣是存儲一億用戶的活躍度，HyperLogLog數據結構須要多少空間。是否是比bitmap更加省空間呢。

我經過測試工程往HyperLogLog裏PFADD了一億個元素。經過rdb tools工具統計了這個key的信息：

只須要14392 Bytes！也就是14KB的空間。對，你沒看錯。就是14K。bitmap存儲一億須要12M，而HyperLogLog只須要14K的空間。

這是一個很驚人的結果。我彷佛有點不敢相信使用如此小的空間竟能存儲如此大的數據量。

接下來我又放了1000w數據，統計出來仍是14k。也就是說，不管你放多少數據進去，都是14K。

查了文檔，發現HyperLogLog是一種機率性數據結構，在標準偏差0.81%的前提下，可以統計2^64個數據。因此 HyperLogLog 適合在好比統計日活月活此類的對精度要不不高的場景。

HyperLogLog使用機率算法來統計集合的近似基數。而它算法的最本源則是伯努利過程。

伯努利過程就是一個拋硬幣實驗的過程。拋一枚正常硬幣，落地多是正面，也多是反面，兩者的機率都是 1/2 。伯努利過程就是一直拋硬幣，直到落地時出現正面位置，並記錄下拋擲次數k。好比說，拋一次硬幣就出現正面了，此時 k 爲 1; 第一次拋硬幣是反面，則繼續拋，直到第三次纔出現正面，此時 k 爲 3。

對於 n 次伯努利過程，咱們會獲得 n 個出現正面的投擲次數值 k1, k2 ... kn , 其中這裏的最大值是k_max。

根據一頓數學推導，咱們能夠得出一個結論： 2^{k_ max} 來做爲n的估計值。也就是說你能夠根據最大投擲次數近似的推算出進行了幾回伯努利過程。

5

雖然HyperLogLog數據類型這麼牛逼，但終究不是精確統計。只適用於對精度要求不高的場景。並且這種類型沒法得出每一個用戶的活躍度信息。畢竟只有14K嘛。也不可能存儲下那麼多數量的信息。

總結一下：對於文章開頭所提到的面試題來講，用bitmap和HyperLogLog均可以解決。

bitmap的優點是：很是均衡的特性，精準統計，能夠獲得每一個統計對象的狀態，秒出。缺點是：當你的統計對象數量十分十分巨大時，可能會佔用到一點存儲空間，但也可在接受範圍內。也能夠經過分片，或者壓縮的額外手段去解決。

HyperLogLog的優點是：能夠統計誇張到沒法想象的數量，而且佔用小的誇張的內存。 缺點是：創建在犧牲準確率的基礎上，並且沒法獲得每一個統計對象的狀態。

我作了一個演示工程redis-bit，放在Gitee上，工程包括了初始化大容量的數據。和分別使用bitmap和HyperLogLog進行用戶活躍度的統計。最後經過http的方式進行輸出。

工程採用springboot+redisson客戶端。全部的參數支持配置

聯繫做者