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

String型別

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

String常用操作指令

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

String的實際儲存結構

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

Redis並沒有採用C語言的傳統字串表示方式（char*

在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型別的常用操作命令，具體命令的操作，可以參考： http://doc.redisfans.com/

資料儲存結構

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

ziplist詳細說明：https://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所示，其他的指令可以參考：http://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所示，完整的操作命令，詳見：http://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推出的一個型別，它提供了地理位置的計算功能，也就是可以計算出兩個地理位置的距離。

文件：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學架構]公眾號，獲取更多精品原創