如圖所示，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*或者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型別的常用操作命令，具體命令的操作，可以參考： 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學架構]公眾號，獲取更多精品原創

標籤：Java

上一篇：java 自定義表單設計方案

下一篇：我的成長記1：手把手教你如何畫出令人稱贊的圖（程式員必讀）