Redis基础——数据类型详解
命令參考：http://doc.redisfans.com/
簡介
Redis 是完全開源的，遵守 BSD 協(xié)議，是一個高性能的 key-value 數(shù)據(jù)庫。
Redis 與其他 key - value 緩存產(chǎn)品有以下三個特點：
- Redis支持數(shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保存在磁盤中，重啟的時候可以再次加載進行使用。
- Redis不僅僅支持簡單的key-value類型的數(shù)據(jù)，同時還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。
- Redis支持數(shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。
優(yōu)勢
- 性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s 。
- 豐富的數(shù)據(jù)類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數(shù)據(jù)類型操作。
- 原子 – Redis的所有操作都是原子性的，意思就是要么成功執(zhí)行要么失敗完全不執(zhí)行。單個操作是原子性的。多個操作也支持事務(wù)，即原子性，通過MULTI和EXEC指令包起來。
- 豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
Redis與其他key-value存儲有什么不同？
- Redis有著更為復(fù)雜的數(shù)據(jù)結(jié)構(gòu)并且提供對他們的原子性操作，這是一個不同于其他數(shù)據(jù)庫的進化路徑。Redis的數(shù)據(jù)類型都是基于基本數(shù)據(jù)結(jié)構(gòu)的同時對程序員透明，無需進行額外的抽象。
- Redis運行在內(nèi)存中但是可以持久化到磁盤，所以在對不同數(shù)據(jù)集進行高速讀寫時需要權(quán)衡內(nèi)存，因為數(shù)據(jù)量不能大于硬件內(nèi)存。在內(nèi)存數(shù)據(jù)庫方面的另一個優(yōu)點是，相比在磁盤上相同的復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，在內(nèi)存中操作起來非常簡單，這樣Redis可以做很多內(nèi)部復(fù)雜性很強的事情。同時，在磁盤格式方面他們是緊湊的以追加的方式產(chǎn)生的，因為他們并不需要進行隨機訪問。
數(shù)據(jù)類型
如圖所示，Redis中提供了9種不同的數(shù)據(jù)操作類型，他們分別代表了不同的數(shù)據(jù)存儲結(jié)構(gòu)。
String
String類型是Redis用的較多的一個基本類型，也是最簡單的一種類型，一個key對應(yīng)一個value；它和我們在Java中使用的字符類型什么太大區(qū)別。
string 類型是二進制安全的。意思是 redis 的 string 可以包含任何數(shù)據(jù)。比如jpg圖片或者序列化的對象。
string 類型是 Redis 最基本的數(shù)據(jù)類型，string 類型的值最大能存儲 512MB。
他的結(jié)構(gòu)如圖所示：
實例
我們可以通過 set 方法創(chuàng)建一個key為name，value為chen的鍵值對；然后通過get方法獲取name的值。
常用指令
存儲結(jié)構(gòu)
學(xué)過 C++ 的應(yīng)該知道，C++ 中是沒有 String 類型，但是 Redis 又是基于 C++ 來實現(xiàn)的，那么它是如何存儲 String 類型的呢？
Redis 并沒有采用 C 語言的傳統(tǒng)字符串表示方式（char* 或者 char[]），在 Redis 內(nèi)部，String 類型以 int/SDS(simple dynamic string) 作為結(jié)構(gòu)存儲，int 用來存放整型數(shù)據(jù)，sds 存放字節(jié) / 字符串和浮點型數(shù)據(jù)。
在 C 的標(biāo)準(zhǔn)字符串結(jié)構(gòu)下進行了封裝，用來提升基本操作的性能，同時充分利用以后的 C 的標(biāo)準(zhǔn)庫，簡化實現(xiàn)。我們可以在 redis 的源碼中【sds.h】中看到 sds 的結(jié)構(gòu)如下；
struct __attribute__ ((__packed__)) sdshdr8 {uint8_t len;//表示當(dāng)前sds的長度(單位是字節(jié))uint8_t alloc; //表示已為sds分配的內(nèi)存大小(單位是字節(jié))unsigned char flags; //用一個字節(jié)表示當(dāng)前sdshdr的類型，因為有sdshdr有五種類型，所以至少需要3位來表示000:sdshdr5，001:sdshdr8，010:sdshdr16，011:sdshdr32，100:sdshdr64。高5位用不到所以都為0。char buf[];//sds實際存放的位置 };也就是說實際上 sds 類型就是 char* 類型，那 sds 和 char* 有什么區(qū)別呢？
主要區(qū)別就是：sds 一定有一個所屬的結(jié)構(gòu) (sdshdr)，這個 header 結(jié)構(gòu)在每次創(chuàng)建 sds 時被創(chuàng)建，用來存儲 sds 以及 sds 的相關(guān)信息
對 sds 結(jié)構(gòu)有一個簡單認識以后，我們?nèi)绻ㄟ^ set 創(chuàng)建一個字符串，那么也就是會創(chuàng)建一個 sds 來存儲這個字符串信息，那么這個過程是怎么樣的呢？
- 首先第一個要判斷選擇一個什么類型的 sdshdr 來存放信息？這就得根據(jù)要存儲的 sds 的長度決定了，redis 在創(chuàng)建一個 sds 之前會調(diào)用【sds.c 文件】sdsReqType (size_t string_size) 來判斷用哪個 sdshdr。該函數(shù)傳遞一個 sds 的長度作為參數(shù)，返回應(yīng)該選用的 sdshdr 類型。
- 然后把數(shù)據(jù)保存到對應(yīng)的 sdshdr 中。
Redis 采用類似 C 的做法存儲字符串，也就是以’\0’結(jié)尾，’\0’只作為字符串的定界符，不計入 alloc 或者 len
命名規(guī)范
- redis 并沒有規(guī)定我們對 key 應(yīng)該怎么命名，但是最好的實踐是 “對象類型：對象 id: 對象屬性: 子屬性”
- key 不要設(shè)置得太長，太長的 key 不僅僅消耗內(nèi)存，而且在數(shù)據(jù)中查找這類鍵值計算成本很高
- key 不要設(shè)置得太短，比如 u:1000:pwd 來代替 user:1000:password, 雖然沒什么問題，但是后者的可讀性更好
- 為了更好的管理你的 key，對 key 進行業(yè)務(wù)上的分類；同時建議有一個 wiki 統(tǒng)一管理所有的 key，通過查詢這個文檔知道 redis 中的 key 的作用
應(yīng)用場景
String 類型使用比較多，一般來說，不太了解 Redis 的人，幾乎所有場景都是用 String 類型來存儲數(shù)據(jù)。
分布式緩存
首先最基本的就是用來做業(yè)務(wù)數(shù)據(jù)的緩存，Redis 中會緩存一些常用的熱點數(shù)據(jù)，可以提升數(shù)據(jù)查詢的性能。
分布式全局ID
使用 String 類型的 incr 命令，實現(xiàn)原子遞增。
分布式 session
基于登錄場景中，保存 token 信息。
限流
計數(shù)器限流
List
列表類型 (list) 可以存儲一個有序且可重復(fù)的字符串列表，常用的操作是向列表兩端添加元素或者獲得列表的某一個片段，List 的存儲結(jié)構(gòu)如下圖所示：
列表最多可存儲 232 - 1 元素 (4294967295, 每個列表可存儲40多億)。
實例
該操作就是簡單的通過LPUSH方法從隊列的左邊入隊元素，然后通過LRANGE方法遍歷指定區(qū)間內(nèi)的元素。
常用命令
存儲結(jié)構(gòu)
在 redis6.0 中，List 采用了 QuickList 這樣一種結(jié)構(gòu)來存儲數(shù)據(jù)，QuickList 是一個雙向鏈表，鏈表的每個節(jié)點保存一個 ziplist，所有的數(shù)據(jù)實際上是存儲在 ziplist 中，ziplist 是一個壓縮列表，它可以節(jié)省內(nèi)存空間。
ziplist 詳細說明：https://www.cnblogs.com/hunternet/p/11306690.html
聽到 “壓縮” 兩個字，直觀的反應(yīng)就是節(jié)省內(nèi)存。之所以說這種存儲結(jié)構(gòu)節(jié)省內(nèi)存，是相較于數(shù)組的存儲思路而言的。我們知道，數(shù)組要求每個元素的大小相同，如果我們要存儲不同長度的字符串，那我們就需要用最大長度的字符串大小作為元素的大小 (假設(shè)是 5 個字節(jié))。存儲小于 5 個字節(jié)長度的字符串的時候，便會浪費部分存儲空間，比如下面這個圖所示。
所以，ziplist 就是根據(jù)每個節(jié)點的長度來決定占用內(nèi)存大小，然后每個元素保存時同步記錄當(dāng)前數(shù)據(jù)的長度，這樣每次添加元素是就可以計算下一個節(jié)點在內(nèi)存中的存儲位置，從而形成一個壓縮列表。
另外，這種方式存儲數(shù)據(jù)有一個很好的優(yōu)勢，就是它存儲的是在一個連續(xù)的內(nèi)存空間，它可以很好的利用 CPU 的緩存來訪問數(shù)據(jù)，從而提升訪問性能。
其中，QuickList 中的每個節(jié)點稱為 QuickListNode，具體的定義在 quicklist.h 文件中。
typedef struct quicklistNode {struct quicklistNode *prev; //鏈表的上一個node節(jié)點struct quicklistNode *next; //鏈表的下一個node節(jié)點unsigned char *zl; //數(shù)據(jù)指針，如果當(dāng)前節(jié)點數(shù)據(jù)沒有壓縮，它指向一個ziplist，否則，指向一個quicklistLZFunsigned int sz; /* 指向的ziplist的總大小 */unsigned int count : 16; /* ziplist中的元素個數(shù) */unsigned int encoding : 2; /* 表示ziplist是否壓縮了，1表示沒壓縮，2表示壓縮 */unsigned int container : 2; /* 預(yù)留字段 */unsigned int recompress : 1; /* 當(dāng)使用類似lindex命令查看某一個本壓縮的數(shù)據(jù)時，需要先解壓，這個用來存儲標(biāo)記，等有機會再把數(shù)據(jù)重新壓縮 */unsigned int attempted_compress : 1; /* node can't compress; too small */unsigned int extra : 10; /* more bits to steal for future usage */ } quicklistNode;quickList 是 list 類型的存儲結(jié)構(gòu)，其定義如下。
typedef struct quicklist {quicklistNode *head; //指向quicklistNode頭節(jié)點quicklistNode *tail; //指向quicklistNode的尾節(jié)點unsigned long count; /* 所有ziplist數(shù)據(jù)項的個數(shù)綜合 */unsigned long len; /* quicklist節(jié)點個數(shù)*/int fill : QL_FILL_BITS; /* ziplist大小設(shè)置 */unsigned int compress : QL_COMP_BITS; /* 節(jié)點壓縮深度設(shè)置 */unsigned int bookmark_count: QL_BM_BITS;quicklistBookmark bookmarks[]; } quicklist;當(dāng)向 list 中添加元素時，會直接保存到某個 QuickListNode 中的 ziplist 中，不過不管是從頭部插入數(shù)據(jù)，還是從尾部插入數(shù)據(jù)，都包含兩種情況:
- 如果頭節(jié)點（尾部節(jié)點）上的 ziplist 大小沒有超過限制，新數(shù)據(jù)會直接插入到 ziplist 中
- 如果頭節(jié)點上的 ziplist 達到閾值，則創(chuàng)建一個新的 quicklistNode 節(jié)點，該節(jié)點中會創(chuàng)建一個 ziplist，然后把這個新創(chuàng)建的節(jié)點插入到 quicklist 雙向鏈表中。
應(yīng)用場景
消息隊列
list類型可以使用 rpush 實現(xiàn)先進先出的功能，同時又可以使用 lpop 輕松的彈出（查詢并刪除）第一個元素，所以list類型可以用來實現(xiàn)消息隊列。
發(fā)紅包場景
在發(fā)紅包的場景中，假設(shè)發(fā)一個 10 元，10 個紅包，需要保證搶紅包的人不會多搶到，也不會少搶到，這種情況下，我們可以按照如下步驟進行操作。
Hash
Redis hash 是一個鍵值(key=>value)對集合。
Redis hash 是一個 string 類型的 field 和 value 的映射表，但是 value 是一個鍵值對（key-value），類比于 Java 里面的 Map<String,Map<String,Object>> 集合。
所以這種特性使得hash 特別適合用于存儲對象。
實例
常用命令
存儲結(jié)構(gòu)
哈希類型的內(nèi)部編碼有兩種：ziplist 壓縮列表 , hashtable 哈希表。只有當(dāng)存儲的數(shù)據(jù)量比較小的情況下，Redis 才使用壓縮列表來實現(xiàn)字典類型。具體需要滿足兩個條件：
- 當(dāng)哈希類型元素個數(shù)小于 hash-max-ziplist-entries 配置（默認 512 個）
- 所有值都小于 hash-max-ziplist-value 配置（默認 64 字節(jié)）
ziplist 使用更加緊湊的結(jié)構(gòu)實現(xiàn)多個元素的連續(xù)存儲，所以在節(jié)省內(nèi)存方面比 hashtable 更加優(yōu)秀。當(dāng)哈希類型無法滿足 ziplist 的條件時，Redis 會使用 hashtable 作為哈希的內(nèi)部實現(xiàn)，因為此時 ziplist 的讀寫效率會下降，而 hashtable 的讀寫時間復(fù)雜度為 O（1）。
應(yīng)用場景
Hash 表使用用來存儲對象數(shù)據(jù)，比如用戶信息，相對于通過將對象轉(zhuǎn)化為 json 存儲到 String 類型中，Hash 結(jié)構(gòu)的靈活性更大，它可以任何添加和刪除對象中的某些字段。
購物車功能
- 以用戶 ID 作為 key
- 以商品 id 作為 field
- 以商品的數(shù)量作為 value
對象類型數(shù)據(jù)
比如優(yōu)化之后的用戶信息存儲，減少數(shù)據(jù)庫的關(guān)聯(lián)查詢導(dǎo)致的性能慢的問題。
- 用戶信息
- 商品信息
- 計數(shù)器
Set
集合類型 (Set) 是一個無序并唯一的鍵值集合。它的存儲順序不會按照插入的先后順序進行存儲。
集合是通過哈希表實現(xiàn)的，所以添加，刪除，查找的復(fù)雜度都是 O(1)。
集合類型和列表類型的區(qū)別如下：
- 列表可以存儲重復(fù)元素，集合只能存儲非重復(fù)元素；
- 列表是按照元素的先后順序存儲元素的，而集合則是無序方式存儲元素的。
實例
常用命令
| SADD key member [member …] | 添加一個或者多個元素到集合 (set) 里 | O(N) |
| SCARD key | 獲取集合里面的元素數(shù)量 | O(1) |
| SDIFF key [key …] | 獲得隊列不存在的元素 | O(N) |
| SDIFFSTORE destination key [key …]] | 獲得隊列不存在的元素，并存儲在一個關(guān)鍵的結(jié)果集 | O(N) |
| SINTER key [key …] | 獲得兩個集合的交集 | O(N*M) |
| SINTERSTORE destination key [key …] | 獲得兩個集合的交集，并存儲在一個關(guān)鍵的結(jié)果集 | O(N*M) |
| SISMEMBER key member | 確定一個給定的值是一個集合的成員 | O(1) |
| SMEMBERS key | 獲取集合里面的所有元素 | O(N) |
| SMOVE source destination member | 移動集合里面的一個元素到另一個集合 | O(1) |
| SPOP key [count] | 刪除并獲取一個集合里面的元素 | O(1) |
| SRANDMEMBER key [count] | 從集合里面隨機獲取一個元素 | |
| SREM key member [member …]] | 從集合里刪除一個或多個元素 | O(N) |
| SUNION key [key …]] | 添加多個 set 元素 | O(N) |
| SUNIONSTORE destination key [key …] | 合并 set 元素，并將結(jié)果存入新的 set 里面 | O(N) |
存儲結(jié)構(gòu)
Set 在的底層數(shù)據(jù)結(jié)構(gòu)以 intset 或者 hashtable 來存儲。當(dāng) set 中只包含整數(shù)型的元素時，采用 intset 來存儲，否則，采用 hashtable 存儲，但是對于 set 來說，該 hashtable 的 value 值用于為 NULL，通過 key 來存儲元素。
typedef struct intset {uint32_t encoding;uint32_t length;int8_t contents[]; } intset;intset 將整數(shù)元素按順序存儲在數(shù)組里，并通過二分法降低查找元素的時間復(fù)雜度。數(shù)據(jù)量大時，依賴于 “查找” 的命令（如 SISMEMBER）就會由于 O (logn) 的時間復(fù)雜度而遇到一定的瓶頸，所以數(shù)據(jù)量大時會用 dict 來代替 intset。
但是 intset 的優(yōu)勢就在于比 dict 更省內(nèi)存，而且數(shù)據(jù)量小的時候 O (logn) 未必會慢于 O (1) 的 hash function，這也是 intset 存在的原因。
應(yīng)用場景
標(biāo)簽
-
首先給用戶添加相關(guān)標(biāo)簽
-
使用 sinter 命令，可以來計算用戶共同感興趣的標(biāo)簽
這種標(biāo)簽系統(tǒng)在電商系統(tǒng)、社交系統(tǒng)、視頻網(wǎng)站，圖書網(wǎng)站，旅游網(wǎng)站等都有著廣泛的應(yīng)用。例如一個用戶可能對娛樂、體育比較感興趣，另一個用戶可能對歷史、新聞比較感興趣，
這些興趣點就是標(biāo)簽。有了這些數(shù)據(jù)就可以得到喜歡同一個標(biāo)簽的人，以及用戶的共同喜好的標(biāo)簽，這些數(shù)據(jù)對于用戶體驗以及增強用戶黏度比較重要。
例如一個社交系統(tǒng)可以根據(jù)用戶的標(biāo)簽進行好友的推薦，已經(jīng)用戶感興趣的新聞的推薦等，一個電子商務(wù)的網(wǎng)站會對不同標(biāo)簽的用戶做不同類型的推薦，比如對數(shù)碼產(chǎn)品比較感興趣的人，在各個頁面或者通過郵件的形式給他們推薦最新的數(shù)碼產(chǎn)品，通常會為網(wǎng)站帶來更多的利益。
商品推薦
當(dāng)用戶查看某個商品時，可以推薦和這個商品標(biāo)簽有關(guān)的商品信息。
ZSet
Redis zset 和 set 一樣也是string類型元素的集合,且不允許重復(fù)的成員。
不同的是每個元素都會關(guān)聯(lián)一個double類型的分數(shù)。redis正是通過分數(shù)來為集合中的成員進行從小到大的排序。
zset的成員是唯一的,但分數(shù)(score)卻可以重復(fù)。
實例
常用命令
數(shù)據(jù)結(jié)構(gòu)
ZSet 的底層數(shù)據(jù)結(jié)構(gòu)采用了 zipList（壓縮表）和 skiplist（跳躍表）組成，當(dāng)同時滿足以下兩個條件時，有序集合采用的是 ziplist 存儲。
- 有序集合保存的元素個數(shù)要小于 128 個
- 有序集合保存的所有元素成員的長度必須小于 64 個字節(jié)
如果不能滿足以上任意一個條件，有序集合會采用 skiplist（跳躍表）結(jié)構(gòu)進行存儲，如下圖所示，zSet 不只是用 skiplist，實際上，它使用了 dict（字典表）和 zskiplist（跳躍表）同時進行數(shù)據(jù)存儲。
- dict，字典類型， 其中 key 表示 zset 的成員數(shù)據(jù)，value 表示 zset 的分值，用來支持 O (1) 復(fù)雜度的按照成員取分值的操作
- zskiplist，跳躍表，按分值排序成員，用來支持平均復(fù)雜度為 O~~(logn)~~ 的按照分值定位成員的操作，以及范圍查找操作。
其中 zskiplistNode 中 *obj 和 Dic 中 *key 指向同一個具體元素，所以不會存在多余的內(nèi)存消耗問題。另外，backward 表示后退指針，方便進行回溯。
關(guān)于跳躍表
跳表 (skip list) 對標(biāo)的是平衡樹 (AVL Tree)，是一種 插入 / 刪除 / 搜索 都是 O(log n) 的數(shù)據(jù)結(jié)構(gòu)。它最大的優(yōu)勢是原理簡單、容易實現(xiàn)、方便擴展、效率更高。因此在一些熱門的項目里用來替代平衡樹，如 redis, leveldb 等。
基本思想
首先，跳表處理的是有序的鏈表（一般是雙向鏈表，下圖未表示雙向），如下：
這個鏈表中，如果要搜索一個數(shù)，需要從頭到尾比較每個元素是否匹配，直到找到匹配的數(shù)為止，即時間復(fù)雜度是 O (n) O (n)。同理，插入一個數(shù)并保持鏈表有序，需要先找到合適的插入位置，再執(zhí)行插入，總計也是 O (n) O (n) 的時間。
那么如何提高搜索的速度呢？很簡單，做個索引：
如上圖，我們新創(chuàng)建一個鏈表，它包含的元素為前一個鏈表的偶數(shù)個元素。這樣在搜索一個元素時，我們先在上層鏈表進行搜索，當(dāng)元素未找到時再到下層鏈表中搜索。例如搜索數(shù)字 19 時的路徑如下圖：
先在上層中搜索，到達節(jié)點 17 時發(fā)現(xiàn)下一個節(jié)點為 21，已經(jīng)大于 19，于是轉(zhuǎn)到下一層搜索，找到的目標(biāo)數(shù)字 19。
我們知道上層的節(jié)點數(shù)目為 n/2n/2，因此，有了這層索引，我們搜索的時間復(fù)雜度降為了：O (n/2) O (n/2)。同理，我們可以不斷地增加層數(shù)，來減少搜索的時間：
在上面的 4 層鏈表中搜索 25，在最上層搜索時就可以直接跳過 21 之前的所有節(jié)點，因此十分高效。
更一般地，如果有 kk 層，我們需要的搜索次數(shù)會小于 ?n2k?+k?n2k?+k ，這樣當(dāng)層數(shù) kk 增加到 ?log2n??log2?n? 時，搜索的時間復(fù)雜度就變成了 lognlog?n。其實這背后的原理和二叉搜索樹或二分查找很類似，通過索引來跳過大量的節(jié)點，從而提高搜索效率。
動態(tài)跳表
上節(jié)的結(jié)構(gòu)是 “靜態(tài)” 的，即我們先擁有了一個鏈表，再在之上建了多層的索引。但是在實際使用中，我們的鏈表是通過多次插入 / 刪除形成的，換句話說是 “動態(tài)” 的。上節(jié)的結(jié)構(gòu)要求上層相鄰節(jié)點與對應(yīng)下層節(jié)點間的個數(shù)比是 1:2，隨意插入 / 刪除一個節(jié)點，這個要求就被被破壞了。
因此跳表（skip list）表示，我們就不強制要求 1:2 了，一個節(jié)點要不要被索引，建幾層的索引，都在節(jié)點插入時由拋硬幣決定。當(dāng)然，雖然索引的節(jié)點、索引的層數(shù)是隨機的，為了保證搜索的效率，要大致保證每層的節(jié)點數(shù)目與上節(jié)的結(jié)構(gòu)相當(dāng)。下面是一個隨機生成的跳表：
可以看到它每層的節(jié)點數(shù)還和上節(jié)的結(jié)構(gòu)差不多，但是上下層的節(jié)點的對應(yīng)關(guān)系已經(jīng)完全被打破了。
現(xiàn)在假設(shè)節(jié)點 17 是最后插入的，在插入之前，我們需要搜索得到插入的位置：
接著，拋硬幣決定要建立幾層的索引，偽代碼如下：
randomLevel()lvl := 1-- random() that returns a random value in [0...1)while random() < p and lvl < MaxLevel dolvl := lvl + 1return lvl上面的偽代碼相當(dāng)于拋硬幣，如果是正面（random() < p）則層數(shù)加一，直到拋出反面為止。其中的 MaxLevel 是防止如果運氣太好，層數(shù)就會太高，而太高的層數(shù)往往并不會提供額外的性能，
一般 MaxLevel=log1/pnMaxLevel=log1/p?n。現(xiàn)在假設(shè) randomLevel 返回的結(jié)果是 2，那么就得到下面的結(jié)果。
如果要刪除節(jié)點，則把節(jié)點和對應(yīng)的所有索引節(jié)點全部刪除即可。當(dāng)然，要刪除節(jié)點時需要先搜索得到該節(jié)點，搜索過程中可以把路徑記錄下來，這樣刪除索引層節(jié)點的時候就不需要多次搜索了。
使用場景
排行榜系統(tǒng)
有序集合比較典型的使用場景就是排行榜系統(tǒng)。例如學(xué)生成績的排名。某視頻 (博客等) 網(wǎng)站的用戶點贊、播放排名、電商系統(tǒng)中商品的銷量排名等。我們以博客點贊為例。
-
添加用戶贊數(shù)
例如小編 Tom 發(fā)表了一篇博文，并且獲得了 10 個贊。
zadd user:ranking 10 article1 -
取消用戶贊數(shù)
這個時候有一個讀者又覺得 Tom 寫的不好，又取消了贊，此時需要將文章的贊數(shù)從榜單中減去 1，可以使用 zincrby。
zincrby user:ranking -1 article1 -
查看某篇文章的贊數(shù)
ZSCORE user:ranking arcticle1 -
展示獲取贊數(shù)最多的十篇文章
此功能使用 zrevrange 命令實現(xiàn)：
zrevrange user:ranking 0 10 #0 到 10表示元素個數(shù)索引 zrevrangebyscore user:ranking 99 0 # 按照分數(shù)從高到低排名，99，0表示score
熱點話題排行
比如微博的熱搜，就可以使用 ZSet 來實現(xiàn)。
其他數(shù)據(jù)類型介紹
在 Redis 中，還有一些使用得非常少的數(shù)據(jù)類型。
Geospatial
Geo 是 Redis3.2 推出的一個類型，它提供了地理位置的計算功能，也就是可以計算出兩個地理位置的距離。
文檔：https://www.redis.net.cn/order/3687.html
下面演示一下 Geo 的基本使用，其中需要用到經(jīng)緯度信息，可以從 http://www.jsons.cn/lngcode/ 查詢。
-
添加模擬數(shù)據(jù)
geoadd china:city 116.40 39.90 beijing geoadd china:city 121.47 31.23 shanghai geoadd china:city 114.05 22.52 shengzhen geoadd china:city 113.28 23.12 guangzhou -
獲取當(dāng)前位置的坐標(biāo)值
geopos china:city beijing geopos china:city shanghai -
獲取兩個位置之間的距離：m-表示米/km-表示千米/mi-表示英里/ft表示英尺
# 查看北京到上海的直線距離 geodist china:city beijing shanghai km # 查看北京到深圳的直線距離 geodist china:city beijing shenzhen km -
給定一個經(jīng)緯度，找出該經(jīng)緯度某一半徑內(nèi)的元素
# 以110 30這個點為中心，尋找方圓1000km的城市 georadius china:city 110 30 1000 km -
找出指定位置周圍的其他元素
georadiusbymember china:city shanghai 1000 km
比如現(xiàn)在比較火的直播業(yè)務(wù)，我們需要檢索附近的主播，那么 GEO 就可以很好的實現(xiàn)這個功能。
- 首先主播開播的時候?qū)懭胫鞑?Id 的經(jīng)緯度，
- 然后主播關(guān)播的時候刪除主播 Id 元素，這樣就維護了一個具有位置信息的在線主播集合提供給線上檢索。
HyperLogLog
HyperLogLog 是 Redis2.8.9 提供的一種數(shù)據(jù)結(jié)構(gòu)，他提供了一種基數(shù)統(tǒng)計方法。什么是基數(shù)統(tǒng)計呢？簡單來說就是一個集合中不重復(fù)元素的個數(shù)，比如有一個集合 {1,2,3,1,2}，那么它的基數(shù)就是 3。
HyperLogLog 提供了三種指令。
- pfadd ，Redis Pfadd 命令將所有元素參數(shù)添加到 HyperLogLog 數(shù)據(jù)結(jié)構(gòu)中。
- pfcount，Redis Pfcount 命令返回給定 HyperLogLog 的基數(shù)估算值。
- pgmerge，Redis Pgmerge 命令將多個 HyperLogLog 合并為一個 HyperLogLog ，合并后的 HyperLogLog 的基數(shù)估算值是通過對所有 給定 HyperLogLog 進行并集計算得出的。
使用方法如下。
pfadd uv a b c a c d e f # 創(chuàng)建一組元素 pfcount uv # 統(tǒng)計基數(shù)這個功能，我用 String 類型、或者 Set 類型都可以實現(xiàn)，為什么要用 HyperLogLog 呢？
最大的特性就是： HyperLogLog 在數(shù)據(jù)量非常大的情況下，占用的存儲空間非常小，每個 HyperLogLog 鍵只需要花費 12 KB 內(nèi)存，就可以計算接近 2^64（2 的 64 次方） 個不同元素的基數(shù)，這個是一個非常龐大的數(shù)字，為什么能夠用這么小的空間來存儲這么大的數(shù)據(jù)呢？
不知道大家是否注意到，HyperLogLog 并沒有提供數(shù)據(jù)查詢的命令，只提供了數(shù)據(jù)添加和數(shù)據(jù)統(tǒng)計。這是因為 HyperLogLog 并沒有存儲每個元素的值，它使用的是概率算法，通過存儲元素的 hash 值的第一個 1 的位置，來計算元素數(shù)量，這塊在這里就不做過多展開。
應(yīng)用場景
-
HyperLogLog 更適合做一些統(tǒng)計類的工作，比如統(tǒng)計一個網(wǎng)站的 UV。
-
計算日活、7 日活、月活數(shù)據(jù).
如果我們通過解析日志，把 ip 信息（或用戶 id）放到集合中，例如：HashSet。如果數(shù)量不多則還好，但是假如每天訪問的用戶有幾百萬。無疑會占用大量的存儲空間。且計算月活時，還需要將一個整月的數(shù)據(jù)放到一個 Set 中，這隨時可能導(dǎo)致我們的程序 OOM。
有了 HyperLogLog，這件事就變得很簡單了。因為存儲日活數(shù)據(jù)所需要的內(nèi)存只有 12K，例如。
# 使用日來存儲每天的ip地址 pfadd ip_20190301 192.168.8.1 pfadd ip_20190302 xxx pfadd ip_20190303 xxx ... pfadd ip_20190331 xxx計算某一天的日活，只需要執(zhí)行 PFCOUNT ip_201903XX 就可以了。每個月的第一天，執(zhí)行 PFMERGE 將上一個月的所有數(shù)據(jù)合并成一個 HyperLogLog，例如：ip_201903。再去執(zhí)行 PFCOUNT ip_201903，就得到了 3 月的月活。
Bit
Bit，其實是 String 類型中提供的一個功能，他可以設(shè)置 key 對應(yīng)存儲的值指定偏移量上的 bit 位的值，可能大家理解起來比較抽象，舉個例子:
-
使用 string 類型保存一個 key
set key m -
通過 getbit 命令獲取 key 的 bit 位的值
getbit key 0 getbit key 1 getbit key 2 getbit key 3 getbit key 4 getbit key 5 getbit key 6 getbit key 7 getbit key 8打印上面的所有輸出，會發(fā)現(xiàn)得到一個 0 1 1 0 1 1 0 1 的二進制數(shù)據(jù)，這個二進制拼接得到的結(jié)果。 m 的 ascII 碼對應(yīng)的是 109， 109 的二進制正好是 0 1 1 0 1 1 0 1。
所以從這里可以看出來，bit 其實就是針對一個 String 類型的 value 值的 bit 位進行操作。
-
對 key 進行修改，修改第 6 位的值變成 1， 第 7 位的值編程 0.
setbit key 6 1 setbit key 7 0在此使用get key 命令，會發(fā)現(xiàn)得到的結(jié)果是 n。
因為 n 的二進制是 1101110,(十進制是 110)。把上面的指定位修改之后，自然就得到了這樣的結(jié)果。
bit 操作在實際應(yīng)用中，可以怎么使用呢？
比如學(xué)習(xí)打卡功能就可以使用 setbit 操作，比如記錄一周的打卡記錄。
# 設(shè)置用戶id 1001的打卡記錄 set sign:1001 0 1 # 已打卡 set sign:1001 1 0 # 未打卡 set sign:1001 2 1 set sign:1001 3 1 set sign:1001 4 1查看某天是否已打卡
getbit sign 3統(tǒng)計當(dāng)前用戶總的打卡天數(shù)
bitcount sign:1001除了這個場景之外，還有很多類似的場景都可以使用，
- 統(tǒng)計活躍用戶
- 記錄用戶在線狀態(tài)
bit 最大的好處在于，它通過 bit 位來存儲 0/1 表示特定含義，我們知道一個 int 類型是 8 個字節(jié)，占 32 個 bit 位，意味著一個 int 類型的數(shù)字就可以存儲 32 個有意義的場景，大大壓縮了存儲空間。
總結(jié)
數(shù)據(jù)結(jié)構(gòu)總結(jié)
應(yīng)用場景總結(jié)
實際上，所謂的應(yīng)用場景，其實就是合理的利用 Redis 本身的數(shù)據(jù)結(jié)構(gòu)的特性來完成相關(guān)業(yè)務(wù)功能，就像 mysql，它可以用來做服務(wù)注冊，也可以用來做分布式鎖，但是 mysql 它本質(zhì)是一個關(guān)系型數(shù)據(jù)庫，只是用到了其他特性而已。
- 緩存 —— 提升熱點數(shù)據(jù)的訪問速度
- 共享數(shù)據(jù) —— 數(shù)據(jù)的存儲和共享的問題
- 全局 ID —— 分布式全局 ID 的生成方案（分庫分表）
- 分布式鎖 —— 進程間共享數(shù)據(jù)的原子操作保證
- 在線用戶統(tǒng)計和計數(shù)
- 隊列、棧 —— 跨進程的隊列 / 棧
- 消息隊列 —— 異步解耦的消息機制
- 服務(wù)注冊與發(fā)現(xiàn) —— RPC 通信機制的服務(wù)協(xié)調(diào)中心（Dubbo 支持 Redis）
- 購物車
- 新浪 / Twitter 用戶消息時間線
- 抽獎邏輯（禮物、轉(zhuǎn)發(fā)）
- 點贊、簽到、打卡
- 商品標(biāo)簽
- 用戶（商品）關(guān)注（推薦）模型
- 電商產(chǎn)品篩選
- 排行榜
總結(jié)
以上是生活随笔為你收集整理的Redis基础——数据类型详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [附源码]JAVA+ssm计算机毕业设计
- 下一篇： mysql面试题1