給你一個億的keys，Redis如何統計？
前言
不知你大規模的用過Redis嗎？還是僅僅作為快取的工具了？在Redis中使用最多的就是集合了，舉個例子，如下場景：
簽到系統中，一天對應一系列的使用者簽到記錄。 電商系統中，一個商品對應一系列的評論。 交友系統中，某個使用者的一系列的好友。
Redis中集合的特點無非是一個Key對應一系列的資料， 但是資料的作用往往是為了統計的，比如：
交友系統中，需要統計每天的新增好友，以及雙方的共同好友。 電商系統中，需要統計評論列表中的最新評論。 簽到系統中，需要統計連續一個月的簽到的使用者數量。
大型網際網路應用中，資料量是巨大的，少說百萬，千萬，甚至是一個億，比如電商巨頭淘寶，交友巨頭微信、微博；辦公巨頭釘釘等，哪一個的使用者不是上億？
只有針對不同場景，選擇合適的集合，統計才能更方便。
聚合統計
聚合統計指的是多個元素聚合的結果，比如統計多個集合的交集、並集、差集
在你需要對多個集合做聚合統計的時候，Set集合是個不錯的選擇，除了其中無重複的資料外，Redis還提供了對應的API
交集
在上述的例子中交友系統中統計雙方的共同好友正是聚合統計中的交集。
在Redis中可以userid作為key，好友的userid作為value，如下圖：
統計兩個使用者的共同好友只需要兩個Set集合的交集，命令如下；
SINTERSTOREuserid:newuserid:20002userid:20003
上述命令執行完成後，userid:new這個key中儲存的將是userid:20002
userid:20003兩個集合的交集。
差集
舉個例子：假設交友系統中需要統計每日新增的好友，此時就需要對臨近兩天的好友集合取差集了，比如2020/11/1日的好友是set1，2020/11/2日的好友是set2，此時只需要對set1和set2做差集。
此時的結構應該如何設計呢？如下圖：
userid:20201101這個key記錄了userid使用者的2020/11/1日的好友集合。
差集很簡單，只需要執行SDIFFSTORE命令，如下：
SDIFFSTOREuser:newuserid:20201102userid:20201101
執行完畢，此時的user:new這集合將是2020/11/2日新增的好友。
這裡還有一個更貼切的例子，微博上有個可能認識的人功能，可以使用差集，即是你朋友的好友減去你們共同的好友即是可能認識的人。
並集
還是差集的那個例子，假設需要統計2020/11/01和2020/11/2總共新增的好友，此時只需要對這兩日新增好友的集合做一個並集。命令如下：
SUNIONSTOREuserid:newuserid:20201102userid:20201101
此時新的集合userid:new則是兩日新增的好友。
總結
Set集合的交差並的計算複雜度很高，如果資料量很大的情況下，可能會造成Redis的阻塞。
那麼如何規避阻塞呢？建議如下：
在 Redis叢集中選一個從庫專門負責聚合統計，這樣就不會阻塞主庫和其他的從庫了將資料交給客戶端，由客戶端進行聚合統計。
排序統計
在一些電商網站中可以看到商品的評論總是最新的在上面，這個是怎麼做的呢？
最新評論列表包含了所有的評論，這就要集合對元素進行保序儲存了。也就是說集合中的元素必須按序儲存，稱之為有序集合。
Redis中的四種集合中List和Sorted Set屬於有序集合。
但是List和Sorted Set有何區別呢？到底使用哪一種呢？
List是按照元素進入順序進行排序，而Sorted Set可以根據元素權重來排序。 比如可以根據元素插入集合的時間確定權值，先插入的元素權重小，後插入的元素權重大。
針對這一例子中，顯然這兩種都是能夠滿足要求的，List中分頁查詢命令LRANGE和Sorted Set分頁查詢命令ZRANGEBYSCORE。
但是就靈活性來說，List肯定不適合，List只能根據先後插入的順序排序，但是大多數的場景中可能並不只是按照時間先後排序，可能還會按照一些特定的條件，此時Sorted Set就很合適了，只需要根據獨有的演算法生成相應的權重即可。
二值狀態統計
二值狀態指的是取值0或者1兩種；在簽到打卡的場景中，只需要記錄簽到（1）和未簽到（0）兩種狀態，這就是典型的二值狀態統計。
二值狀態的統計可以使用Redis的擴充套件資料型別Bitmap，底層使用String型別實現，可以把它看成是一個bit陣列。關於詳細內容後續介紹.........
在簽到統計中，0和1只佔了一個bit，即使一年的簽到資料才365個bit位。大大減少了儲存空間。
Bitmap 提供了GETBIT/SETBIT 操作，使用一個偏移值 offset 對 bit 陣列的某一個 bit 位進行讀和寫。不過，需要注意的是，Bitmap 的偏移量是從 0 開始算的，也就是說 offset 的最小值是 0。當使用 SETBIT 對一個 bit 位進行寫操作時，這個 bit 位會被設定為 1。Bitmap 還提供了 BITCOUNT 操作，用來統計這個 bit 陣列中所有1的個數。
鍵值如何設計呢？key可以是userid:yyyyMM，即是唯一id加上月份。假設員工id為10001，需要統計2020/11月份的簽到打卡記錄。
第一步，執行命令設定值，假設11月2號打卡了，命令如下：
SETBITuserid:10001:20201111
BitMap是從下標0開始，因此2號則是下標為1，值設定為1則表示成功打卡了。
第二步，檢查該使用者11月2號是否打卡了，命令如下：
GETBITuserid:10001:2020111
第三步，統計11月的打卡次數，命令如下：
BITCOUNTuserid:10001:202011
那麼問題來了，需要統計你這個簽到系統中連續20天的簽到打卡的使用者的總數，如何處理呢？假設使用者一個億。
比如需要統計2020/11/01到2020/11/20天中連續打卡的人數，如何統計呢？
Bitmap中還支援同時對多個BitMap按位做與、或、異或操作，命令如下圖：
思路來了，我們可以將每天的日期作為一個key，對應的BitMap儲存一億個使用者當天的打卡情況。如下圖：
此時我們只需要對2020/11/1到2020/11/20號的Bitmap做按位與操作，最終得到的一個Bitmap中每個bit位置對應的值則代表連續20天打卡的情況，只有連續20天全部打卡，所在的bit位的值才為1。如下圖：
最終可以使用BITCOUNT命令進行統計。
可以嘗試計算下記憶體開銷，每天使用 1 個 1 億位的 Bitmap，大約佔 12MB 的記憶體（10^8/8/1024/1024），20 天的 Bitmap 的記憶體開銷約為 240MB，記憶體壓力不算太大。不過，在實際應用時，最好對 Bitmap 設定過期時間，讓 Redis 自動刪除不再需要的簽到記錄，以節省記憶體開銷。
如果涉及到二值狀態，比如使用者是否存在，簽到打卡，商品是否存在等情況可以使用Bitmap，可以有效的節省記憶體空間。
基數統計
基數統計指統計一個集合中不重複元素的個數。
舉個栗子：電商網站中通常需要統計每個網頁的UV來確定權重，網頁的UV肯定是需要去重的，在Redis型別中Set支援去重，第一時間肯定想到的是Set。
但是這裡有一個問題，Set底層使用的是雜湊表和整數陣列，如果一個網頁的UV達到千萬級別的話（一個電商網站中何止一個頁面），那麼對於記憶體的消耗極大。
Redis提供了一個擴充套件型別HyperLogLog用於基數統計，計算2^64個元素大概只需要12KB的記憶體空間
是不是很心動？但是HyperLogLog是存在誤差的，大概是在0.81%，如果需要精準的統計，還是需要使用Set。對於這種網頁的UV來說，足夠了。
在統計網頁UV的時候，只需要將使用者的唯一id存入HyperLogLog中，如下：
PFADDp1:uv10001100021000310004
如果存在重複的元素，將會自動去重。
統計也很簡單，使用PFCOUNT命令，如下：
PFCOUNTp1:uv
總結
本文介紹了統計的幾種型別以及應該用什麼集合儲存，為了方便理解，作者將支援情況和優缺點彙總了一張表格，如下圖：
Set和Sorted Set支援交集、並集的聚合運算，但是Sorted Set不支差集運算。
Bitmap也能對多個Bitmap做與、異或、或的聚合運算。
List和SortedSet都支援排序統計，但是List是根據元素先後插入順序排序，Sorted Set支援權重，相對於List排序來說更加靈活。
對於二值狀態統計，判斷某個元素是否存在等場景，建議使用Bitmap，節省的記憶體空間。
對於基數統計，在大資料量、不要求精準的情況建議使用HyperLogLog，節省記憶體空間；對於精準的基數統計，最好還是使用Set集合。
另外，作者已經完成了兩個專欄的文章Mybatis進階、Spring Boot 進階 ，已經將專欄文章整理成書，有需要的公號回覆關鍵詞Mybatis 進階、Spring Boot 進階免費獲取。