如何用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的優勢是：可以統計誇張到無法想象的數量，并且占用小的誇張的記憶體。 缺點是：建立在犧牲準确率的基礎上，而且無法得到每個統計對象的狀态。
另外，關注公衆号Java技術棧，在背景回複：面試，可以擷取我整理的 Redis 系列面試題和答案，非常齊全。 近期熱文推薦：