圖解Redis6中的9種數據結構，牆裂建議準備去面試的人先看（乾貨，建議收藏）

• 2021 年 10 月 20 日
• 筆記

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

String類型

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

String常用操作指令

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

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*類型，那sds和char*有什麼區別呢？

主要區別就是：sds一定有一個所屬的結構(sdshdr)，這個header結構在每次創建sds時被創建，用來存儲sds以及sds的相關信息

對sds結構有一個簡單認識以後，我們如果通過set創建一個字符串，那麼也就是會創建一個sds來存儲這個字符串信息，那麼這個過程是怎麼樣的呢？

• 首先第一個要判斷選擇一個什麼類型的sdshdr來存放信息？這就得根據要存儲的sds的長度決定了，redis在創建一個sds之前會調用【sds.c文件】sdsReqType(size_t string_size)來判斷用哪個sdshdr。該函數傳遞一個sds的長度作為參數，返回應該選用的sdshdr類型。
• 然後把數據保存到對應的sdshdr中。

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中會緩存一些常用的熱點數據，可以提升數據查詢的性能。

分佈式全局ID

使用String類型的incr命令，實現原子遞增

限流

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

分佈式session

基於登錄場景中，保存token信息。

List類型

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

常用操作命令

圖2-21表示list類型的常用操作命令，具體命令的操作，可以參考： //doc.redisfans.com/

數據存儲結構

如圖2-22所示，在redis6.0中，List採用了QuickList這樣一種結構來存儲數據，QuickList是一個雙向鏈表，鏈表的每個節點保存一個ziplist，所有的數據實際上是存儲在ziplist中，ziplist是一個壓縮列表，它可以節省內存空間。

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

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

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

另外，數據的方式存儲數據有一個很好的優勢，就是它存儲的是在一個連續的內存空間，它可以很好的利用CPU的緩存來訪問數據，從而提升訪問性能。

其中，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雙向鏈表中。

實際使用場景

消息隊列

列表類型可以使用 rpush 實現先進先出的功能，同時又可以使用 lpop 輕鬆的彈出（查詢並刪除）第一個元素，所以列表類型可以用來實現消息隊列，如圖2-24所示。

發紅包的場景

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

Hash類型

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

Hash常用操作命令

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

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）。

Hash實際應用場景

Hash表使用用來存儲對象數據，比如用戶信息，相對於通過將對象轉化為json存儲到String類型中，Hash結構的靈活性更大，它可以任何添加和刪除對象中的某些字段。

購物車功能

• 1.以用戶ID作為key

• 2.以商品id作為field

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

對象類型數據

比如優化之後的用戶信息存儲，減少數據庫的關聯查詢導致的性能慢的問題。

• 用戶信息
• 商品信息
• 計數器

Set類型

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

集合類型和列表類型的區別如下：

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

set類型的常用操作

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

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存在的原因。

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個元素、獲得指定分數範圍內的元素等與分數有關的操作。

ZSet常用操作命令

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

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表示後退指針，方便進行回溯。

關於跳躍表

跳錶(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推出的一個類型，它提供了地理位置的計算功能，也就是可以計算出兩個地理位置的距離。

文檔：//www.redis.net.cn/order/3687.html

下面演示一下Geo的基本使用，其中需要用到經緯度信息，可以從 //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學架構]公眾號，獲取更多精品原創