給你一個億的keys，Redis如何統計？
前言
不知你大規模的用過Redis嗎？還是僅僅作為緩存的工具了？在Redis中使用最多的就是集合了，舉個例子，如下場景：
- 簽到系統中，一天對應一系列的用戶簽到記錄。
- 電商系統中，一個商品對應一系列的評論。
- 交友系統中，某個用戶的一系列的好友。
Redis中集合的特點無非是一個Key對應一系列的數據， 但是數據的作用往往是為了統計的，比如：
- 交友系統中，需要統計每天的新增好友，以及雙方的共同好友。
- 電商系統中，需要統計評論列表中的最新評論。
- 簽到系統中，需要統計連續一個月的簽到的用戶數量。
大型互聯網應用中，數據量是巨大的，少說百萬，千萬，甚至是一個億，比如電商巨頭淘寶，交友巨頭微信、微博；辦公巨頭釘釘等，哪一個的用戶不是上億？
只有針對不同場景，選擇合適的集合，統計才能更方便。
聚合統計
聚合統計指的是多個元素聚合的結果，比如統計多個集合的交集、并集、差集
在你需要對多個集合做聚合統計的時候，Set集合是個不錯的選擇，除了其中無重復的數據外，Redis還提供了對應的API
交集
在上述的例子中交友系統中統計雙方的共同好友正是聚合統計中的交集。
在Redis中可以userid作為key，好友的userid作為value，如下圖：
統計兩個用戶的共同好友只需要兩個Set集合的交集，命令如下；
- SINTERSTORE userid:new userid:20002 userid: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命令，如下：
- SDIFFSTORE user:new userid:20201102 userid:20201101
執行完畢，此時的user:new這集合將是2020/11/2日新增的好友。
這里還有一個更貼切的例子，微博上有個可能認識的人功能，可以使用差集，即是你朋友的好友減去你們共同的好友即是可能認識的人。
并集
還是差集的那個例子，假設需要統計2020/11/01和2020/11/2總共新增的好友，此時只需要對這兩日新增好友的集合做一個并集。命令如下：
- SUNIONSTORE userid:new userid:20201102 userid: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號打卡了，命令如下：
- SETBIT userid:10001:202011 1 1
BitMap是從下標0開始，因此2號則是下標為1，值設置為1則表示成功打卡了。
第二步，檢查該用戶11月2號是否打卡了，命令如下：
- GETBIT userid:10001:202011 1
第三步，統計11月的打卡次數，命令如下：
- GETBIT userid:10001:202011 1
那么問題來了，需要統計你這個簽到系統中連續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中，如下：
- PFADD p1:uv 10001 10002 10003 10004
如果存在重復的元素，將會自動去重。
統計也很簡單，使用PFCOUNT命令，如下：
- PFCOUNT p1:uv
總結
本文介紹了統計的幾種類型以及應該用什么集合存儲，為了方便理解，作者將支持情況和優缺點匯總了一張表格，如下圖：
Set和Sorted Set支持交集、并集的聚合運算，但是Sorted Set不支差集運算。
Bitmap也能對多個Bitmap做與、異或、或的聚合運算。
List和SortedSet都支持排序統計，但是List是根據元素先后插入順序排序，Sorted Set支持權重，相對于List排序來說更加靈活。
對于二值狀態統計，判斷某個元素是否存在等場景，建議使用Bitmap，節省的內存空間。
對于基數統計，在大數據量、不要求精準的情況建議使用HyperLogLog，節省內存空間；對于精準的基數統計，最好還是使用Set集合。
