Redis 支持的數據類型
Redis 是一個 key-value 的數據結構服務器，key 是字符串。value 支持的數據類型，我們都知道有 String（字符串）、List（列表）、Hash（哈希）、Set（集合）、Sorted Set（有序集合）。除了這些之外，隨着Redis 的版本迭代，還有 BitMap（位圖）、HyperLogLog、Stream 三種數據類型。
Redis 中的 key
Redis中的 key 是二進制安全的（因爲Redis中的SDS是二進制安全的），這意味着您可以使用任何二進制序列作爲key，從“ foo”之類的字符串到JPEG文件的內容。 空字符串也是有效的key。
官方推薦的有關 key 的一些其他規則：
- 太長的 key 不是一個好主意。 例如，一個1024字節的 key 不僅是內存方面是個壞主意，因爲在數據集中查找 key 可能需要進行一些代價高昂的 key 比較。 即使手頭的任務是匹配一個大值的存在，對它進行哈希（例如使用SHA1）也是一個更好的主意，尤其是從內存和帶寬的角度來看。
- 非常短的 key 通常不是一個好主意。 如果您可以改寫“ user：1000：followers”，那麼將“ u1000flw”作爲 key 寫的毫無意義。 與 key 對象本身和值對象使用的空間相比，後者更具可讀性，並且添加的空間較小。 雖然短 key 顯然會消耗較少的內存，但您的工作是找到正確的平衡點。這一點主要是從可讀性上考慮的。
- 嘗試堅持一個模式。 例如，“ object-type：id”是一個好主意，例如“ user：1000”。 點或破折號通常用於多字字段，例如“ comment：1234：reply.to”或“ comment：1234：reply-to”中。這一點是考慮 key 的命名風格。
- 允許的最大 key 的大小爲512 MB。這一點是受限於Redis 中 String 的最大大小爲512 MB。
Redis 中 value 支持的數據類型
Redis 中 value 支持的數據結構：String、List、Hash、Set、Sorted Set、 BitMap、HyperLogLog、Stream 。
String
Redis字符串類型是您可以與Redis鍵關聯的最簡單的值類型。String可以是每種類型的字符串（包括二進制數據），例如，您可以在字符串內存儲jpeg圖像。字符串大小不能大於512 MB。
List
列表是根據插入順序排序的字符串元素集合。 可以認爲是鏈表。
Hash
哈希是由與值相關聯的字段組成的 field-value 映射表。 字段【field】和值【value】都是字符串。
Set
Redis集合是字符串的無序集合。 SADD命令將新元素添加到集合中。 還可以對集合進行許多其他操作，例如測試給定元素是否已存在，執行多個集合之間的交集，並集或差集等。
Sorted Set
有序集合是一種類似於集合和哈希之間的混合數據類型。 像集合一樣，排序集合由唯一的，非重複的字符串元素組成，因此從某種意義上說，有序集合也是一個集合。有序集合中的每個元素都與一個稱爲“分值（score）”的浮點值相關聯（這就是爲什麼該類型也類似於哈希的原因，因爲每個元素都映射到一個值）。
有序集合中的元素排序規則：
- 如果A和B是兩個具有不同分值的元素，那麼如果A.score是> B.score，則A>B。
- 如果A和B的分數完全相同，那麼如果A字符串在字典上大於B字符串，則A>B。 A和B字符串不能相等，因爲排序集僅具有唯一元素。
BitMap
Redis中的位圖不是實際的數據類型，而是在String類型上定義的一組面向位的操作。 由於字符串是二進制安全的Blob，並且最大長度爲512 MB，因此它們適合設置多達 2^32 個不同的 bit 位。
位操作分爲兩類：固定時間的單個位操作（例如將一個位設置爲1或0或獲取其值），以及對位組的操作，例如計算給定位範圍內設置位的數量。
位圖的最大優點之一是，它們在存儲信息時通常可以節省大量空間。 例如，在以增量用戶ID表示不同用戶的系統中，僅使用512 MB內存就可以記住40億用戶的單個 bit 位信息（例如，知道用戶是否要接收新聞通訊，是：bit 位置爲1）。
位圖的常見用例有：
1、各種實時分析。
2、存儲與對象id相關聯的節省空間但高性能的布爾信息。
HyperLogLogs
Redis 在 2.8.9 版本添加了 HyperLogLog 結構。HyperLogLog 是一種概率數據結構，用於對唯一事物進行計數（從技術上講，這是指估計集合的基數）。 通常，對唯一項目進行計數需要使用與要計數的項目數量成比例的內存量，因爲您需要記住過去已經看到的元素，以避免多次對其進行計數。 但是，有一組算法會以內存換取精度：您最終會得到帶有標準誤差的估計量，在Redis實現的情況下，該誤差小於1％。 該算法的神奇之處在於，您不再需要使用與所計數項目數量成比例的內存量，而可以使用恆定數量的內存！ 在最壞的情況下爲12k字節，如果您的HyperLogLog（從現在開始將它們稱爲HLL）看到的元素很少，則少得多。
什麼是基數?
比如數據集 {1, 3, 5, 7, 5, 7, 8}， 那麼這個數據集的基數集爲 {1, 3, 5 ,7, 8}, 基數(不重複元素)爲5。
基數估計就是在誤差可接受的範圍內，快速計算基數。
在 Redis 裏面，每個 HyperLogLog 鍵只需要花費 12 KB 內存，就可以計算接近 2^64 個不同元素的基 數。這和計算基數時，元素越多耗費內存就越多的集合形成鮮明對比。但是，因爲 HyperLogLog 只會根據輸入元素來計算基數，而不會儲存輸入元素本身，所以 HyperLogLog 不能像集合那樣，返回輸入的各個元素。
Redis中的HLL（HyperLogLog）儘管在技術上是不同的數據結構，但被編碼爲Redis字符串，因此您可以調用GET來序列化HLL，然後調用SET來將其反序列化回服務器。
用途：用來做基數統計，比如每天計算用戶在搜索表單中執行的唯一查詢集合的基數。
Stream
Stream是Redis 5.0引入的一種新數據類型，它以更抽象的方式對日誌數據結構進行建模，但是日誌的本質仍然完好無損：就像日誌文件一樣，通常實現爲僅在追加模式下打開的文件， Redis流主要是僅追加數據結構。 至少從概念上講，因爲Redis是流式傳輸在內存中表示的抽象數據類型，所以它們實現了更強大的操作，以克服日誌文件本身的限制。
儘管數據結構本身非常簡單，Redis流卻成爲最複雜的Redis類型，原因是它實現了附加的、非強制性的特性：一組阻塞操作允許消費者等待生產者添加到流中的新數據，此外還有一個稱爲消費者組的概念。
Redis Stream 官方文檔地址：https://redis.io/topics/streams-intro