圖解Redis6中的9種資料結構,牆裂建議準備去面試的人先看(乾貨,建議收藏)

語言: CN / TW / HK

如圖所示,Redis中提供了9種不同的資料操作型別,他們分別代表了不同的資料儲存結構。

圖2-17 資料型別

String型別

String型別是Redis用的較多的一個基本型別,也是最簡單的一種型別,它和我們在Java中使用的字元型別什麼太大區別,具體結構如圖2-18所示。

圖2-19

String常用操作指令

常用炒作指令如圖2-20所示,更多的指令查詢: http://doc.redisfans.com/

圖2-20

String的實際儲存結構

學過C++的同學都知道,C++中沒有String型別,而Redis又是基於C++來實現的,那麼它是如何儲存String型別的呢?

Redis並沒有採用C語言的傳統字串表示方式( char* 或者 char[] ),在Redis內部,String型別以 int/SDS(simple dynamic string) 作為結構儲存,int用來存放整型資料,sds存放位元組/字串和浮點型資料。

在C的標準字串結構下進行了封裝,用來提升基本操作的效能,同時充分利用以後的C的標準庫,簡化實現。我們可以在redis的原始碼中【 sds.h 】中看到sds的結構如下;

struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len;//表示當前sds的長度(單位是位元組)
    uint8_t alloc; //表示已為sds分配的記憶體大小(單位是位元組)
    unsigned char flags; //用一個位元組表示當前sdshdr的型別,因為有sdshdr有五種型別,所以至少需要3位來表示000:sdshdr5,001:sdshdr8,010:sdshdr16,011:sdshdr32,100:sdshdr64。高5位用不到所以都為0。
    char buf[];//sds實際存放的位置
};

也就是說實際上sds型別就是 char* 型別,那 sdschar* 有什麼區別呢?

主要區別就是:sds一定有一個所屬的結構(sdshdr),這個header結構在每次建立sds時被建立,用來儲存sds以及sds的相關資訊

對sds結構有一個簡單認識以後,我們如果通過set建立一個字串,那麼也就是會建立一個sds來儲存這個字串資訊,那麼這個過程是怎麼樣的呢?

  • 首先第一個要判斷選擇一個什麼型別的sdshdr來存放資訊?這就得根據要儲存的sds的長度決定了,redis在建立一個sds之前會呼叫【 sds.c檔案 】sdsReqType(size_t string_size)來判斷用哪個sdshdr。該函式傳遞一個sds的長度作為引數,返回應該選用的sdshdr型別。
  • 然後把資料儲存到對應的sdshdr中。

圖2-19

Redis採用類似C的做法儲存字串,也就是以’\0’結尾,’\0’只作為字串的定界符,不計入alloc或者len

key命名小技巧

  • a) redis並沒有規定我們對key應該怎麼命名,但是最好的實踐是“物件型別:物件id:物件屬性.子屬性”
  • b) key不要設定得太長,太長的key不僅僅消耗記憶體,而且在資料中查詢這類鍵值計算成本很高
  • c) key不要設定得太短,比如u:1000:pwd 來代替user:1000:password, 雖然沒什麼問題,但是後者的可讀性更好
  • d) 為了更好的管理你的key,對key進行業務上的分類;同時建議有一個wiki統一管理所有的key,通過查詢這個文件知道redis中的key的作用

String型別的應用場景

String型別使用比較多,一般來說,不太瞭解Redis的人,幾乎所有場景都是用String型別來儲存資料。

分散式快取

首先最基本的就是用來做業務資料的快取,如圖2-20,Redis中會快取一些常用的熱點資料,可以提升資料查詢的效能。

如圖2-20

分散式全域性ID

使用String型別的incr命令,實現原子遞增

限流

使用計數器實現手機驗證碼頻率限流。

分散式session

基於登入場景中,儲存token資訊。

List型別

列表型別(list)可以儲存一個有序且可重複的字串列表,常用的操作是向列表兩端新增元素或者獲得列表的某一個片段,List的儲存結構如圖2-20所示

圖2-20

常用操作命令

圖2-21表示list型別的常用操作命令,具體命令的操作,可以參考: http://doc.redisfans.com/

圖2-21

資料儲存結構

如圖2-22所示,在redis6.0中,List採用了QuickList這樣一種結構來儲存資料,QuickList是一個雙向連結串列,連結串列的每個節點儲存一個ziplist,所有的資料實際上是儲存在ziplist中,ziplist是一個壓縮列表,它可以節省記憶體空間。

ziplist詳細說明: https://www.cnblogs.com/hunternet/p/11306690.html

聽到“壓縮”兩個字,直觀的反應就是節省記憶體。之所以說這種儲存結構節省記憶體,是相較於陣列的儲存思路而言的。我們知道,陣列要求每個元素的大小相同,如果我們要儲存不同長度的字串,那我們就需要用最大長度的字串大小作為元素的大小(假設是5個位元組)。儲存小於5個位元組長度的字串的時候,便會浪費部分儲存空間,比如下面這個圖所示。

所以,ziplist就是根據每個節點的長度來決定佔用記憶體大小,然後每個元素儲存時同步記錄當前資料的長度,這樣每次新增元素是就可以計算下一個節點在記憶體中的儲存位置,從而形成一個壓縮列表。

另外,資料的方式儲存資料有一個很好的優勢,就是它儲存的是在一個連續的記憶體空間,它可以很好的利用CPU的快取來訪問資料,從而提升訪問效能。

圖2-22

其中,QuickList中的每個節點稱為QuickListNode,具體的定義在 quicklist.h 檔案中。

typedef struct quicklistNode {
    struct quicklistNode *prev;   //連結串列的上一個node節點
    struct quicklistNode *next;   //連結串列的下一個node節點
    unsigned char *zl;            //資料指標,如果當前節點資料沒有壓縮,它指向一個ziplist,否則,指向一個quicklistLZF
    unsigned int sz;             /* 指向的ziplist的總大小 */
    unsigned int count : 16;     /* ziplist中的元素個數 */
    unsigned int encoding : 2;   /* 表示ziplist是否壓縮了,1表示沒壓縮,2表示壓縮 */
    unsigned int container : 2;  /* 預留欄位 */
    unsigned int recompress : 1; /* 當使用類似lindex命令檢視某一個本壓縮的資料時,需要先解壓,這個用來儲存標記,等有機會再把資料重新壓縮 */
    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型別的儲存結構,其定義如下。

typedef struct quicklist {
    quicklistNode *head;    //指向quicklistNode頭節點
    quicklistNode *tail;    //指向quicklistNode的尾節點
    unsigned long count;        /* 所有ziplist資料項的個數綜合 */
    unsigned long len;          /* quicklist節點個數*/
    int fill : QL_FILL_BITS;              /* ziplist大小設定 */
    unsigned int compress : QL_COMP_BITS; /* 節點壓縮深度設定 */
    unsigned int bookmark_count: QL_BM_BITS;
    quicklistBookmark bookmarks[];
} quicklist;

如圖2-23所示,當向list中新增元素時,會直接儲存到某個QuickListNode中的ziplist中,不過不管是從頭部插入資料,還是從尾部插入資料,都包含兩種情況

  • 如果頭節點(尾部節點)上的ziplist大小沒有超過限制,新資料會直接插入到ziplist中
  • 如果頭節點上的ziplist達到閾值,則建立一個新的quicklistNode節點,該節點中會建立一個ziplist,然後把這個新建立的節點插入到quicklist雙向連結串列中。

圖2-23

實際使用場景

訊息佇列

列表型別可以使用 rpush 實現先進先出的功能,同時又可以使用 lpop 輕鬆的彈出(查詢並刪除)第一個元素,所以列表型別可以用來實現訊息佇列,如圖2-24所示。

圖2-24

發紅包的場景

在發紅包的場景中,假設發一個10元,10個紅包,需要保證搶紅包的人不會多搶到,也不會少搶到,這種情況下,可以根據圖2-25所示去實現。

圖2-25

Hash型別

Hash型別大家應該都不陌生,他就是一個鍵值對集合,如圖2-26所示。Hash相當於一個 string 型別的 key和 value 的對映表,key 還是key,但是value是一個鍵值對(key-value),類比於 Java裡面的 Map<String,Map<String,Object>> 集合。

圖2-26

Hash常用操作命令

Hash結構的常用操作命令如圖2-27所示,其他的指令可以參考: http://doc.redisfans.com/

圖2-27

Hash實際儲存結構

如圖2-28所示,雜湊型別的內部編碼有兩種: ziplist壓縮列表 , hashtable雜湊表 。只有當儲存的資料量比較小的情況下,Redis 才使用壓縮列表來實現字典型別。具體需要滿足兩個條件:

  • 當雜湊型別元素個數小於 hash-max-ziplist-entries 配置(預設512個)
  • 所有值都小於 hash-max-ziplist-value 配置(預設64位元組)
    ziplist 使用更加緊湊的結構實現多個元素的連續儲存,所以在節省記憶體方面比 hashtable 更加優秀。當雜湊型別無法滿足 ziplist 的條件時,Redis會使用 hashtable 作為雜湊的內部實現,因為此時 ziplist 的讀寫效率會下降,而 hashtable 的讀寫時間複雜度為O(1)。

圖2-28

Hash實際應用場景

Hash表使用用來儲存物件資料,比如使用者資訊,相對於通過將物件轉化為json儲存到String型別中,Hash結構的靈活性更大,它可以任何新增和刪除物件中的某些欄位。

購物車功能

  • 1.以使用者ID作為key

  • 2.以商品id作為field

  • 3.以商品的數量作為value

物件型別資料

比如優化之後的使用者資訊儲存,減少資料庫的關聯查詢導致的效能慢的問題。

  • 使用者資訊
  • 商品資訊
  • 計數器

Set型別

如圖2-29所示,集合型別 (Set) 是一個無序並唯一的鍵值集合。它的儲存順序不會按照插入的先後順序進行儲存。

集合型別和列表型別的區別如下:

  • 列表可以儲存重複元素,集合只能儲存非重複元素;
  • 列表是按照元素的先後順序儲存元素的,而集合則是無序方式儲存元素的。

圖2-29

set型別的常用操作

Set型別的常用操作指令如下。

命令 說明 時間複雜度
SADD key member [member ...] 新增一個或者多個元素到集合(set)裡 O(N)
SCARD key 獲取集合裡面的元素數量 O(1)
SDIFF key [key ...] 獲得佇列不存在的元素 O(N)
SDIFFSTORE destination key [key ...]] 獲得佇列不存在的元素,並存儲在一個關鍵的結果集 O(N)
SINTER key [key ...] 獲得兩個集合的交集 O(N*M)
SINTERSTORE destination key [key ...] 獲得兩個集合的交集,並存儲在一個關鍵的結果集 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元素,並將結果存入新的set裡面 O(N)

Set型別實際儲存結構

Set在的底層資料結構以intset或者hashtable來儲存。當set中只包含整數型的元素時,採用intset來儲存,否則,採用hashtable儲存,但是對於set來說,該hashtable的value值用於為NULL,通過key來儲存元素。

typedef struct intset {
    uint32_t encoding;
    uint32_t length;
    int8_t contents[];
} intset;

intset將整數元素按順序儲存在數組裡,並通過二分法降低查詢元素的時間複雜度。資料量大時,

依賴於“查詢”的命令(如SISMEMBER)就會由於O(logn)的時間複雜度而遇到一定的瓶頸,所以資料量大時會用dict來代替intset。

但是intset的優勢就在於比dict更省記憶體,而且資料量小的時候O(logn)未必會慢於O(1)的hash function,這也是intset存在的原因。

圖2-30

set型別的實際應用場景

標籤管理功能

  1. 給使用者新增標籤。

    sadd user:1:basketball game coding swing
    sadd user:2:sing coding sleep basketball
    ...
    sadd user:k:tags tag1 tag2 tag4
    ...
  2. 使用sinter命令,可以來計算使用者共同感興趣的標籤

    sinter user:1 user:2

這種標籤系統在電商系統、社交系統、影片網站,圖書網站,旅遊網站等都有著廣泛的應用。例如一個使用者可能對娛樂、體育比較感興趣,另一個使用者可能對歷史、新聞比較感興趣,

這些興趣點就是標籤。有了這些資料就可以得到喜歡同一個標籤的人,以及使用者的共同喜好的標籤,這些資料對於使用者體驗以及增強使用者黏度比較重要。

例如一個社交系統可以根據使用者的標籤進行好友的推薦,已經使用者感興趣的新聞的推薦等,一個電子商務的網站會對不同標籤的使用者做不同型別的推薦,比如對數碼產品比較感興趣的人,

在各個頁面或者通過郵件的形式給他們推薦最新的數碼產品,通常會為網站帶來更多的利益

相關商品資訊展示

比如在電商系統中,當用戶檢視某個商品時,可以推薦和這個商品標籤有關的商品資訊。

ZSet型別

有序集合型別,顧名思義,和前面講的集合型別的區別就是多了有序的功能。

如圖2-31所示,在集合型別的基礎上,有序集合型別為集合中的每個元素都關聯了一個分數(浮點型),這使得我們不僅可以完成插入、刪除和判斷元素是否存在等集合型別支援的操作,還能獲得分數最高(或最低)的前N個元素、獲得指定分數範圍內的元素等與分數有關的操作。

圖2-31

ZSet常用操作命令

ZSet的常用命令如圖2-32所示,完整的操作命令,詳見: http://doc.redisfans.com/

圖2-32

ZSet的資料儲存結構

ZSet的底層資料結構採用了zipList(壓縮表)和skiplist(跳躍表)組成,當同時滿足以下兩個條件時,有序集合採用的是ziplist儲存。

  • 有序集合儲存的元素個數要小於128個
  • 有序集合儲存的所有元素成員的長度必須小於64個位元組

如果不能滿足以上任意一個條件,有序集合會採用skiplist(跳躍表)結構進行儲存,如圖2-33所示,zSet不只是用skiplist,實際上,它使用了dict(字典表)和zskiplist(跳躍表)同時進行資料儲存。

  • dict,字典型別, 其中key表示zset的成員資料,value表示zset的分值, 用來支援O(1)複雜度的按照成員取分值的操作
  • zskiplist,跳躍表,按分值排序成員, 用來支援平均複雜度為O (logn) 的按照分值定位成員的操作,以及範圍查詢操作

其中zskiplistNode中 *obj 和Dic中 *key 指向同一個具體元素,所以不會存在多餘的記憶體消耗問題。另外,backward表示後退指標,方便進行回溯。

圖2-33

關於跳躍表

跳錶(skip list) 對標的是平衡樹(AVL Tree),是一種 插入/刪除/搜尋 都是 O(log n) 的資料結構。它最大的優勢是原理簡單、容易實現、方便擴充套件、效率更高。因此在一些熱門的專案裡用來替代平衡樹,如 redis, leveldb 等。

跳錶的基本思想

首先,跳錶處理的是有序的連結串列(一般是雙向連結串列,下圖未表示雙向),如下:

這個連結串列中,如果要搜尋一個數,需要從頭到尾比較每個元素是否匹配,直到找到匹配的數為止,即時間複雜度是 O(n)O(n)。同理,插入一個數並保持連結串列有序,需要先找到合適的插入位置,再執行插入,總計也是 O(n)O(n) 的時間。

那麼如何提高搜尋的速度呢?很簡單,做個索引:

如上圖,我們新建立一個連結串列,它包含的元素為前一個連結串列的偶數個元素。這樣在搜尋一個元素時,我們先在上層連結串列進行搜尋,當元素未找到時再到下層連結串列中搜索。例如搜尋數字 19 時的路徑如下圖:

先在上層中搜索,到達節點 17 時發現下一個節點為 21 ,已經大於 19 ,於是轉到下一層搜尋,找到的目標數字 19

我們知道上層的節點數目為 n/2n/2,因此,有了這層索引,我們搜尋的時間複雜度降為了:O(n/2)O(n/2)。同理,我們可以不斷地增加層數,來減少搜尋的時間:

在上面的 4 層連結串列中搜索 25 ,在最上層搜尋時就可以直接跳過 21 之前的所有節點,因此十分高效。

更一般地,如果有 kk 層,我們需要的搜尋次數會小於 ⌈n2k⌉+k⌈n2k⌉+k ,這樣當層數 kk 增加到 ⌈log2n⌉⌈log2⁡n⌉ 時,搜尋的時間複雜度就變成了 lognlog⁡n。其實這背後的原理和二叉搜尋樹或二分查詢很類似,通過索引來跳過大量的節點,從而提高搜尋效率。

動態跳錶

上節的結構是“靜態”的,即我們先擁有了一個連結串列,再在之上建了多層的索引。但是在實際使用中,我們的連結串列是通過多次插入/刪除形成的,換句話說是“動態”的。上節的結構要求上層相鄰節點與對應下層節點間的個數比是 1:2 ,隨意插入/刪除一個節點,這個要求就被被破壞了。

因此跳錶(skip list)表示,我們就不強制要求 1:2 了,一個節點要不要被索引,建幾層的索引,都在節點插入時由拋硬幣決定。當然,雖然索引的節點、索引的層數是隨機的,為了保證搜尋的效率,要大致保證每層的節點數目與上節的結構相當。下面是一個隨機生成的跳錶:

可以看到它每層的節點數還和上節的結構差不多,但是上下層的節點的對應關係已經完全被打破了。

現在假設節點 17 是最後插入的,在插入之前,我們需要搜尋得到插入的位置:

接著,拋硬幣決定要建立幾層的索引,虛擬碼如下:

randomLevel()
    lvl := 1
    -- random() that returns a random value in [0...1)
    while random() < p and lvl < MaxLevel do
        lvl := lvl + 1
    return lvl

上面的虛擬碼相當於拋硬幣,如果是正面( random() < p )則層數加一,直到丟擲反面為止。其中的 MaxLevel 是防止如果運氣太好,層數就會太高,而太高的層數往往並不會提供額外的效能,

一般 MaxLevel=log1/pnMaxLevel=log1/p⁡n。現在假設 randomLevel 返回的結果是 2 ,那麼就得到下面的結果。

如果要刪除節點,則把節點和對應的所有索引節點全部刪除即可。當然,要刪除節點時需要先搜尋得到該節點,搜尋過程中可以把路徑記錄下來,這樣刪除索引層節點的時候就不需要多次搜尋了

ZSet的使用場景

  • 排行榜系統

    有序集合比較典型的使用場景就是排行榜系統。例如學生成績的排名。某影片(部落格等)網站的使用者點贊、播放排名、電商系統中商品的銷量排名等。我們以部落格點贊為例。

    • 新增使用者贊數

      例如小編Tom發表了一篇博文,並且獲得了10個贊。

      zadd user:ranking article1 10
    • 取消使用者贊數

      這個時候有一個讀者又覺得Tom寫的不好,又取消了贊,此時需要將文章的贊數從榜單中減去1,可以使用zincrby。

      zincrby user:ranking -1 article1
    • 檢視某篇文章的贊數

      ZSCORE user:ranking arcticle1
    • 展示獲取贊數最多的十篇文章

      此功能使用zrevrange命令實現:

      zrevrange user:ranking 0 10  #0 到 10表示元素個數索引
      zrevrangebyscore user:ranking 99 0 #  按照分數從高到低排名,99,0表示score
  • 熱點話題排名

    比如想微博的熱搜,就可以使用ZSet來實現。

其他資料型別介紹

在Redis中,還有一些使用得非常少的資料型別,簡單給大家普及一下。

Geospatial

Geo是Redis3.2推出的一個型別,它提供了地理位置的計算功能,也就是可以計算出兩個地理位置的距離。

文件: https://www.redis.net.cn/order/3687.html

下面演示一下Geo的基本使用,其中需要用到經緯度資訊,可以從 http://www.jsons.cn/lngcode/查詢。

  1. 新增模擬資料

    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
  2. 獲取當前位置的座標值

    geopos china:city beijing
    geopos china:city shanghai
  3. 獲取兩個位置之間的距離: m-表示米/km-表示千米/mi-表示英里/ft表示英尺

    # 檢視北京到上海的直線距離
    geodist china:city beijing shanghai km
    # 檢視北京到深圳的直線距離
    geodist china:city beijing shenzhen km
  4. 給定一個經緯度,找出該經緯度某一半徑內的元素

    # 以110 30這個點為中心,尋找方圓1000km的城市
    georadius china:city 110 30 1000 km
  5. 找出指定位置周圍的其他元素

    georadiusbymember china:city shanghai 1000 km

比如現在比較火的直播業務,我們需要檢索附近的主播,那麼GEO就可以很好的實現這個功能。

Id
Id

HyperLogLog

HyperLogLog是Redis2.8.9提供的一種資料結構,他提供了一種基數統計方法。什麼是基數統計呢?簡單來說就是一個集合中不重複元素的個數,比如有一個集合{1,2,3,1,2},那麼它的基數就是3。

HyperLogLog提供了三種指令。

  • pfadd ,Redis Pfadd 命令將所有元素引數新增到 HyperLogLog 資料結構中。
  • pfcount,Redis Pfcount 命令返回給定 HyperLogLog 的基數估算值。
  • pgmerge,Redis Pgmerge 命令將多個 HyperLogLog 合併為一個 HyperLogLog ,合併後的 HyperLogLog 的基數估算值是通過對所有 給定 HyperLogLog 進行並集計算得出的。

使用方法如下。

pfadd uv a b c a c d e f   # 建立一組元素
pfcount uv                 # 統計基數

有同學會問了,這個功能,我用String型別、或者Set型別都可以實現,為什麼要用HyperLogLog呢?

最大的特性就是: HyperLogLog在資料量非常大的情況下,佔用的儲存空間非常小,每個 HyperLogLog 鍵只需要花費 12 KB 記憶體,就可以計算接近 2^64(2的64次方) 個不同元素的基數,這個是一個非常龐大的數字,為什麼能夠用這麼小的空間來儲存這麼大的資料呢?

不知道大家是否注意到,HyperLogLog並沒有提供資料查詢的命令,只提供了資料新增和資料統計。這是因為HyperLogLog並沒有儲存每個元素的值,它使用的是概率演算法,通過儲存元素的hash值的第一個1的位置,來計算元素數量,這塊在這裡就不做過多展開。

應用場景:

  • HyperLogLog更適合做一些統計類的工作,比如統計一個網站的UV。

  • 計算日活、7日活、月活資料.

    如果我們通過解析日誌,把 ip 資訊(或使用者 id)放到集合中,例如:HashSet。如果數量不多則還好,但是假如每天訪問的使用者有幾百萬。無疑會佔用大量的儲存空間。且計算月活時,還需要將一個整月的資料放到一個 Set 中,這隨時可能導致我們的程式 OOM。

    有了 HyperLogLog,這件事就變得很簡單了。因為儲存日活資料所需要的記憶體只有 12K,例如。

    # 使用日來儲存每天的ip地址
    pfadd ip_20190301 192.168.8.1
    pfadd ip_20190302 xxx
    pfadd ip_20190303 xxx
    ...
    pfadd ip_20190331 xxx

    計算某一天的日活,只需要執行 PFCOUNT ip_201903XX 就可以了。每個月的第一天,執行 PFMERGE 將上一個月的所有資料合併成一個 HyperLogLog,例如:ip_201903。再去執行 PFCOUNT ip_201903,就得到了 3 月的月活。

Bit

Bit,其實是String型別中提供的一個功能,他可以設定key對應儲存的值指定偏移量上的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

    列印上面的所有輸出,會發現得到一個 0 1 1 0 1 1 0 1 的二進位制資料,這個二進位制拼接得到的結果。 m 的ascII碼對應的是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 命令,會發現得到的結果是n。

    因為n的二進位制是1101110,(十進位制是110)。把上面的指定位修改之後,自然就得到了這樣的結果。

bit操作在實際應用中,可以怎麼使用呢?

比如學習打卡功能就可以使用setbit操作,比如記錄一週的打卡記錄。

# 設定使用者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

統計當前使用者總的打卡天數

bitcount sign:1001

除了這個場景之外,還有很多類似的場景都可以使用,

  • 統計活躍使用者
  • 記錄使用者線上狀態

bit最大的好處在於,它通過bit位來儲存0/1表示特定含義,我們知道一個int型別是8個位元組,佔32個bit位,意味著一個int型別的數字就可以儲存32個有意義的場景,大大壓縮了儲存空間。

階段性總結

資料結構總結

應用場景總結

實際上,所謂的應用場景,其實就是合理的利用Redis本身的資料結構的特性來完成相關業務功能,就像mysql,它可以用來做服務註冊,也可以用來做分散式鎖,但是mysql它本質是一個關係型資料庫,只是用到了其他特性而已。

  • 快取——提升熱點資料的訪問速度

  • 共享資料——資料的儲存和共享的問題

  • 全域性ID —— 分散式全域性ID的生成方案(分庫分表)

  • 分散式鎖——程序間共享資料的原子操作保證

  • 線上使用者統計和計數

  • 佇列、棧——跨程序的佇列/棧

  • 訊息佇列——非同步解耦的訊息機制

  • 服務註冊與發現 —— RPC通訊機制的服務協調中心(Dubbo支援Redis)

  • 購物車

  • 新浪/Twitter 使用者訊息時間線

  • 抽獎邏輯(禮物、轉發)

  • 點贊、簽到、打卡

  • 商品標籤

  • 使用者(商品)關注(推薦)模型

  • 電商產品篩選

  • 排行榜

    關注[跟著Mic學架構]公眾號,獲取更多精品原創