2. 程式人生 > >redis內部資料結構深入淺出

redis內部資料結構深入淺出

阿新 • • 發佈：2018-12-12

最大感受，無論從設計還是原始碼，Redis都儘量做到簡單，其中運用到的原理也通俗易懂。特別是原始碼，簡潔易讀，真正做到clean and clear， 這篇文章以unstable分支的原始碼為基準，先從大體上整理Redis的物件型別以及底層編碼。 當我們在本文中提到Redis的“資料結構”，可能是在兩個不同的層面來討論它。

  • 第一個層面，是從使用者的角度，string，list，hash，set，sorted set
  • 第二個層面，是從內部實現的角度，屬於更底層的實現，   ht(dict),raw,embstr,intset,sds,ziplist,quicklist,skiplist

在討論任何一個系統的內部實現的時候，我們都要先明確它的設計原則，這樣我們才能更深刻地理解它為什麼會進行如此設計的真正意圖。

  • 儲存效率（memory efficiency）。Redis是專用於儲存資料的，它對於計算機資源的主要消耗就在於記憶體，因此節省記憶體是它非常非常重要的一個方面。這意味著Redis一定是非常精細地考慮了壓縮資料、減少記憶體碎片等問題。

  • 快速響應時間（fast response time）。與快速響應時間相對的，是高吞吐量（high throughput）。Redis是用於提供線上訪問的，對於單個請求的響應時間要求很高，因此，快速響應時間是比高吞吐量更重要的目標。有時候，這兩個目標是矛盾的。

  • 單執行緒（single-threaded）。Redis的效能瓶頸不在於CPU資源，而在於記憶體訪問和網路IO。而採用單執行緒的設計帶來的好處是，極大簡化了資料結構和演算法的實現。相反，Redis通過非同步IO和pipelining等機制來實現高速的併發訪問。顯然，單執行緒的設計，對於單個請求的快速響應時間也提出了更高的要求。

比如：Redis一個重要的基礎資料結構：dict。

  • dict是一個用於維護key和value對映關係的資料結構，與很多語言中的Map或dictionary類似。Redis的一個database中所有key到value的對映，就是使用一個dict來維護的。不過，這只是它在Redis中的一個用途而已，它在Redis中被使用的地方還有很多。比如，一個Redis hash結構，當它的field較多時，便會採用dict來儲存。再比如，Redis配合使用dict和skiplist來共同維護一個sorted set

  • dict本質上是為了解決演算法中的查詢問題（Searching），一般查詢問題的解法分為兩個大類：一個是基於各種平衡樹，一個是基於雜湊表。我們平常使用的各種Map或dictionary，大都是基於雜湊表實現的。在不要求資料有序儲存，且能保持較低的雜湊值衝突概率的前提下，基於雜湊表的查詢效能能做到非常高效，接近O(1)，而且實現簡單。

  • dict也是一個基於雜湊表的演算法。和傳統的雜湊演算法類似，它採用某個雜湊函式從key計算得到在雜湊表中的位置，採用拉鍊法解決衝突，並在裝載因子（load factor）超過預定值時自動擴充套件記憶體，引發重雜湊（rehashing）。Redis的dict實現最顯著的一個特點，就在於它的重雜湊。它採用了一種稱為增量式重雜湊（incremental rehashing）的方法，在需要擴充套件記憶體時避免一次性對所有key進行重雜湊，而是將重雜湊操作分散到對於dict的各個增刪改查的操作中去。這種方法能做到每次只對一小部分key進行重雜湊，而每次重雜湊之間不影響dict的操作。dict之所以這樣設計，是為了避免重雜湊期間單個請求的響應時間劇烈增加，這與前面提到的“快速響應時間”的設計原則是相符的。

一、物件型別

redis 是 key-value 儲存系統，其中 key 型別一般為字串，而 value 型別則為 redis 物件（redis object），可以繫結各種型別的資料，譬如 string、list 和set，redis.h 中定義了 struct redisObject，它是一個簡單優秀的資料結構

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

#define LRU_BITS 24

#define LRU_CLOCK_MAX ((1<<LRU_BITS)-1) /* Max value of obj->lru */

#define LRU_CLOCK_RESOLUTION 1000 /* LRU clock resolution in ms */

typedef struct redisObject {

//物件的資料型別，佔4bits，共5種類型

unsigned type:4;       

//物件的編碼型別，佔4bits，共10種類型

unsigned encoding:4;

//least recently used

//實用LRU演算法計算相對server.lruclock的LRU時間

unsigned lru:LRU_BITS; /* lru time (relative to server.lruclock) */

//引用計數

int refcount;

//指向底層資料實現的指標

void *ptr;

} robj;

//type的佔5種類型：

/* Object types */

#define OBJ_STRING 0    //字串物件

#define OBJ_LIST 1      //列表物件

#define OBJ_SET 2       //集合物件

#define OBJ_ZSET 3      //有序集合物件

#define OBJ_HASH 4      //雜湊物件

/* Objects encoding. Some kind of objects like Strings and Hashes can be

* internally represented in multiple ways. The 'encoding' field of the object

* is set to one of this fields for this object. */

// encoding 的10種類型

#define OBJ_ENCODING_RAW 0     /* Raw representation */     //原始表示方式，字串物件是簡單動態字串

#define OBJ_ENCODING_INT 1     /* Encoded as integer */         //long型別的整數

#define OBJ_ENCODING_HT 2      /* Encoded as hash table */      //字典

#define OBJ_ENCODING_ZIPMAP 3  /* Encoded as zipmap */          //不在使用

#define OBJ_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */  //雙端連結串列,不在使用

#define OBJ_ENCODING_ZIPLIST 5 /* Encoded as ziplist */         //壓縮列表

#define OBJ_ENCODING_INTSET 6  /* Encoded as intset */          //整數集合

#define OBJ_ENCODING_SKIPLIST 7  /* Encoded as skiplist */      //跳躍表和字典

#define OBJ_ENCODING_EMBSTR 8  /* Embedded sds string encoding */   //embstr編碼的簡單動態字串

#define OBJ_ENCODING_QUICKLIST 9 /* Encoded as linked list of ziplists */   //由壓縮列表組成的雙向列表-->快速列表

其中，void *ptr 已經給了我們無限的遐想空間了（把最後一個指標留給了真正的資料）

每種型別的物件至少都有兩種或以上的encoding方式，不同編碼可以在不同的使用場景上優化物件的使用場景，用TYPE命令可檢視某個鍵值對的型別

二、物件編碼

 不同型別和編碼的物件

1

2

3

4

5

6

7

8

9

10

11

REDIS_STRING    REDIS_ENCODING_INT  使用整數值實現的字串物件。

REDIS_STRING    REDIS_ENCODING_EMBSTR   使用 embstr 編碼的簡單動態字串實現的字串物件。

REDIS_STRING    REDIS_ENCODING_RAW  使用簡單動態字串實現的字串物件。

REDIS_LIST  REDIS_ENCODING_ZIPLIST  使用壓縮列表實現的列表物件。

REDIS_LIST  REDIS_ENCODING_LINKEDLIST   使用雙端連結串列實現的列表物件。

REDIS_HASH  REDIS_ENCODING_ZIPLIST  使用壓縮列表實現的雜湊物件。

REDIS_HASH  REDIS_ENCODING_HT   使用字典實現的雜湊物件。

REDIS_SET   REDIS_ENCODING_INTSET   使用整數集合實現的集合物件。

REDIS_SET   REDIS_ENCODING_HT   使用字典實現的集合物件。

REDIS_ZSET  REDIS_ENCODING_ZIPLIST  使用壓縮列表實現的有序集合物件。

REDIS_ZSET  REDIS_ENCODING_SKIPLIST 使用跳躍表和字典實現的有序集合物件。

OBJECT ENCODING 對不同編碼的輸出

1

2

3

4

5

6

7

8

整數  REDIS_ENCODING_INT  "int"

embstr 編碼的簡單動態字串（SDS）  REDIS_ENCODING_EMBSTR   "embstr"

簡單動態字串 REDIS_ENCODING_RAW  "raw"

字典  REDIS_ENCODING_HT   "hashtable"

雙端連結串列    REDIS_ENCODING_LINKEDLIST   "linkedlist"

壓縮列表    REDIS_ENCODING_ZIPLIST  "ziplist"

整數集合    REDIS_ENCODING_INTSET   "intset"

跳躍表和字典  REDIS_ENCODING_SKIPLIST "skiplist"

本質上，Redis就是基於這些資料結構而構造出一個物件儲存系統。

關於redisObject 

  • ptr指標，指向物件的底層實現資料結構

  • encoding屬性記錄物件所使用的編碼

  • 淘汰時鐘，Redis 對資料集佔用記憶體的大小有「實時」的計算，當超出限額時，會淘汰超時的資料

  • 引用計數，一個 Redis 物件可能被多個指標引用。當需要增加或者減少引用的時候，必須呼叫相應的函式，程式設計師必須遵守這一準則

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

// 增加 Redis 物件引用

void incrRefCount(robj *o) {

o->refcount++;

}

// 減少 Redis 物件引用。特別的，引用為零的時候會銷燬物件

void decrRefCount(robj *o) {

if (o->refcount <= 0) redisPanic("decrRefCount against refcount <= 0");

// 如果取消的是最後一個引用，則釋放資源

if (o->refcount == 1) {

// 不同資料型別，銷燬操作不同

switch(o->type) {

case REDIS_STRING: freeStringObject(o); break;

case REDIS_LIST: freeListObject(o); break;

case REDIS_SET: freeSetObject(o); break;

case REDIS_ZSET: freeZsetObject(o); break;

case REDIS_HASH: freeHashObject(o); break;

default: redisPanic("Unknown object type"); break;

}

zfree(o);

} else {

o->refcount--;

}

}

得益於 Redis 是單程序單執行緒工作的，所以增加/減少引用的操作不必保證原子性，這在 memcache 中是做不到的（memcached 是多執行緒的工作模式，需要做到互斥）

1、Keys 

redis是一個key-value db，首先key也是字串型別，但是key中不能包括邊界字元，由於key不是binary safe的字串，所以像”my key”和”mykey\n”這樣包含空格和換行的key是不允許的 ，順便說一下在redis內部並不限制使用binary字元，這是redis協議限制的，”\r\n”在協議格式中會作為特殊字元。

redis 1.2以後的協議中部分命令已經開始使用新的協議格式了(比如MSET)，總之目前還是把包含邊界字元當成非法的key，另外關於key的一個格式約定介紹下，object-type:id:field。比如user:1000:password，blog:xxidxx:title  

2、string

string是redis最基本的型別，而且string型別是二進位制安全的。意思是redis的string可以包含任何資料，比如jpg圖片或者序列化的物件。從內部實現來看其實string可以看作byte陣列，最大上限是1G位元組。 

1

2

3

4

5

struct sdshdr {

long len;

long free;

char buf[];

};

buf是個char陣列用於存貯實際的字串內容。其實char和c#中的byte是等價的，都是一個位元組 ，len是buf陣列的長度，free是陣列中剩餘可用位元組數。 由此可以理解為什麼string型別是二進位制安全的了。因為它本質上就是個byte陣列。當然可以包含任何資料了。 另外string型別可以被部分命令按int處理，比如incr等命令，redis的其他型別像list,set,sorted set ,hash它們包含的元素與都只能是string型別。 

編碼

字串物件的編碼可以是 INT、RAW 或 EMBSTR。如果儲存的是整數值並且可以用long表示，那麼編碼會設定為INT。當字串值得長度大於44位元組使用RAW，小於等於44位元組使用EMBSTR。

Redis在3.0引入EMBSTR編碼，這是一種專門用於儲存短字串的一種優化編碼方式，這種編碼和RAW編碼都是用sdshdr簡單動態字串結構來表示。RAW編碼會呼叫兩次記憶體分配函式來分別建立redisObject和sdshdr結構，而EMBSTR只調用一次記憶體分配函式來分配一塊連續的空間儲存資料，比起RAW編碼的字串更能節省記憶體，以及能提升獲取資料的速度。

不過要注意！EMBSTR是不可修改的，當對EMBSTR編碼的字串執行任何修改命令，總會先將其轉換成RAW編碼再進行修改；而INT編碼在條件滿足的情況下也會被轉換成RAW編碼。

兩種字串物件編碼方式的區別

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

/* Create a string object with EMBSTR encoding if it is smaller than

* REIDS_ENCODING_EMBSTR_SIZE_LIMIT, otherwise the RAW encoding is

* used.

*

* The current limit of 39 is chosen so that the biggest string object

* we allocate as EMBSTR will still fit into the 64 byte arena of jemalloc. */

//sdshdr8的大小為3個位元組，加上1個結束符共4個位元組

//redisObject的大小為16個位元組

//redis使用jemalloc記憶體分配器，且jemalloc會分配8，16，32，64等位元組的記憶體

//一個embstr固定的大小為16+3+1 = 20個位元組，因此一個最大的embstr字串為64-20 = 44位元組

#define OBJ_ENCODING_EMBSTR_SIZE_LIMIT 44

// 建立字串物件，根據長度使用不同的編碼型別

// createRawStringObject和createEmbeddedStringObject的區別是：

// createRawStringObject是當字串長度大於44位元組時，robj結構和sdshdr結構在記憶體上是分開的

// createEmbeddedStringObject是當字串長度小於等於44位元組時，robj結構和sdshdr結構在記憶體上是連續的

robj *createStringObject(const char *ptr, size_t len) {

if (len <= OBJ_ENCODING_EMBSTR_SIZE_LIMIT)

return createEmbeddedStringObject(ptr,len);

else

return createRawStringObject(ptr,len);

}

字串物件編碼的優化

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

/* Try to encode a string object in order to save space */

//嘗試優化字串物件的編碼方式以節約空間

robj *tryObjectEncoding(robj *o) {

long value;

sds s = o->ptr;

size_t len;

/* Make sure this is a string object, the only type we encode

* in this function. Other types use encoded memory efficient

* representations but are handled by the commands implementing

* the type. */

serverAssertWithInfo(NULL,o,o->type == OBJ_STRING);

/* We try some specialized encoding only for objects that are

* RAW or EMBSTR encoded, in other words objects that are still

* in represented by an actually array of chars. */

//如果字串物件的編碼型別為RAW或EMBSTR時，才對其重新編碼

if (!sdsEncodedObject(o)) return o;

/* It's not safe to encode shared objects: shared objects can be shared

* everywhere in the "object space" of Redis and may end in places where

* they are not handled. We handle them only as values in the keyspace. */

//如果refcount大於1，則說明物件的ptr指向的值是共享的，不對共享物件進行編碼

if (o->refcount > 1) return o;

/* Check if we can represent this string as a long integer.

* Note that we are sure that a string larger than 20 chars is not

* representable as a 32 nor 64 bit integer. */

len = sdslen(s);            //獲得字串s的長度

//如果len小於等於20，表示符合long long可以表示的範圍，且可以轉換為long型別的字串進行編碼

if (len <= 20 && string2l(s,len,&value)) {

/* This object is encodable as a long. Try to use a shared object.

* Note that we avoid using shared integers when maxmemory is used

* because every object needs to have a private LRU field for the LRU

* algorithm to work well. */

if ((server.maxmemory == 0 ||

(server.maxmemory_policy != MAXMEMORY_VOLATILE_LRU &&

server.maxmemory_policy != MAXMEMORY_ALLKEYS_LRU)) &&

value >= 0 &&

value < OBJ_SHARED_INTEGERS)    //如果value處於共享整數的範圍內

{

decrRefCount(o);                //原物件的引用計數減1，釋放物件

incrRefCount(shared.integers[value]); //增加共享物件的引用計數

return shared.integers[value];      //返回一個編碼為整數的字串物件

} else {        //如果不處於共享整數的範圍

if (o->encoding == OBJ_ENCODING_RAW) sdsfree(o->ptr);   //釋放編碼為OBJ_ENCODING_RAW的物件

o->encoding = OBJ_ENCODING_INT;     //轉換為OBJ_ENCODING_INT編碼

o->ptr = (void*) value;             //指標ptr指向value物件

return o;

}

}

/* If the string is small and is still RAW encoded,

* try the EMBSTR encoding which is more efficient.

* In this representation the object and the SDS string are allocated

* in the same chunk of memory to save space and cache misses. */

//如果len小於44，44是最大的編碼為EMBSTR型別的字串物件長度

if (len <= OBJ_ENCODING_EMBSTR_SIZE_LIMIT) {

robj *emb;

if (o->encoding == OBJ_ENCODING_EMBSTR) return o;   //將RAW物件轉換為OBJ_ENCODING_EMBSTR編碼型別

emb = createEmbeddedStringObject(s,sdslen(s)); //建立一個編碼型別為OBJ_ENCODING_EMBSTR的字串物件

decrRefCount(o);    //釋放之前的物件

return emb;

}

/* We can't encode the object...

*

* Do the last try, and at least optimize the SDS string inside

* the string object to require little space, in case there

* is more than 10% of free space at the end of the SDS string.

*

* We do that only for relatively large strings as this branch

* is only entered if the length of the string is greater than

* OBJ_ENCODING_EMBSTR_SIZE_LIMIT. */

//無法進行編碼，但是如果s的未使用的空間大於使用空間的10分之1

if (o->encoding == OBJ_ENCODING_RAW &&

sdsavail(s) > len/10)

{

o->ptr = sdsRemoveFreeSpace(o->ptr);    //釋放所有的未使用空間

}

/* Return the original object. */

return o;

}

3、list

list型別其實就是一個每個子元素都是string型別的雙向連結串列。所以[lr]push和[lr]pop命令的演算法時間複雜度都是O(n)，另外list會記錄連結串列的長度。所以llen操作也是O(n).連結串列的最大長度是(2的32次方-1)。  我們可以通過push,pop操作從連結串列的頭部或者尾部新增刪除元素。這使得list既可以用作棧，也可以用作佇列。 有意思的是list的pop操作還有阻塞版本的。當我們[lr]pop一個list物件，如果list是空，或者不存在，會立即返回nil。但是阻塞版本的b[lr]pop可以則可以阻塞， 當然可以加超時時間，超時後也會返回nil。為什麼要阻塞版本的pop呢，主要是為了避免輪詢。 如果我們用list來實現一個工作佇列。執行任務的thread可以呼叫阻塞版本的pop去 ，獲取任務這樣就可以避免輪詢去檢查是否有任務存在。當任務來時候工作執行緒可以立即返回，也可以避免輪詢帶來的延遲。

編碼

Redis3.0之前的列表物件的編碼可以是ziplist或者linkedlist。當列表物件儲存的字串元素的長度都小於64位元組並且儲存的元素數量小於512個，使用ziplist編碼，可以通過修改配置list-max-ziplist-value和list-max-ziplist-entries來修改這兩個條件的上限值、兩個條件任意一個不滿足時，ziplist會變為linkedlist。

從3.2開始Redis只使用quicklist作為列表的編碼，quicklist是ziplist和雙向連結串列的結合體，quicklist的每個節點都是一個ziplist。可以通過修改list-max-ziplist-size來設定一個quicklist節點上的ziplist的長度，取正值表示通過元素數量來限定ziplist的長度；負數表示按照佔用位元組數來限定，並且Redis規定只能取-1到-5這五個負值

1

2

3

4

5

-5: 每個quicklist節點上的ziplist大小不能超過64 Kb。（注：1kb => 1024 bytes）

-4: 每個quicklist節點上的ziplist大小不能超過32 Kb。

-3: 每個quicklist節點上的ziplist大小不能超過16 Kb。

-2: 每個quicklist節點上的ziplist大小不能超過8 Kb。（預設值）

-1: 每個quicklist節點上的ziplist大小不能超過4 Kb。

另外配置引數list-compress-depth表示一個quicklist兩端不被壓縮的節點個數

1

2

3

4

5

0: 表示都不壓縮。預設值。

1: 表示quicklist兩端各有1個節點不壓縮，中間的節點壓縮。

2: 表示quicklist兩端各有2個節點不壓縮，中間的節點壓縮。

3: 表示quicklist兩端各有3個節點不壓縮，中間的節點壓縮。

依此類推…

這裡採用的是一種叫LZF的無失真壓縮演算法

4、hash

雜湊物件的編碼可以是ziplist或者hashtable。使用ziplist 編碼時，儲存同一鍵值對的兩個節點總是緊挨在一起，鍵節點在前，值節點在後，同時滿足以下兩個條件將使用ziplist編碼：

  • 所有鍵和值的字串長度小於64位元組

  • 鍵值對的數量小於512個

不能滿足這兩個條件的都需要使用hashtable編碼。以上兩個上限值可以通過hash-max-ziplist-value和hash-max-ziplist-entries來修改

hash是一個string型別的field和value的對映表，它的新增，刪除操作都是O(1)，hash特別適合用於儲存物件。 相較於將物件的每個欄位存成單個string型別，將一個物件儲存在hash型別中會佔用更少的記憶體，並且可以更方便的存取整個物件。

省記憶體的原因是新建一個hash物件時開始是用zipmap（又稱為small hash）來儲存的。 這個zipmap其實並不是hash table，但是zipmap相比正常的hash實現可以節省不少hash本身需要的一些元資料儲存開銷。 儘管zipmap的新增，刪除，查詢都是O(n)，但是由於一般物件的field數量都不太多。 所以使用zipmap也是很快的,也就是說新增刪除平均還是O(1)。 如果field或者value的大小超出一定限制後，redis會在內部自動將zipmap替換成正常的hash實現，這個限制可以在配置檔案中指定 

1

2

hash-max-zipmap-entries 64 #配置欄位最多64個

hash-max-zipmap-value 512 #配置value最大為512位元組

5、set

集合物件的編碼可以是intset或者hashtable。當滿足以下兩個條件時使用intset編碼：

  • 所有元素都是整數值

  • 元素數量不超過512個

可以修改set-max-intset-entries設定元素數量的上限。使用hashtable編碼時，字典的每一個鍵都是字串物件，每個字串物件包含一個集合元素，字典的值全部設定為null。

redis的set是string型別的無序集合。set元素最大可以包含(2的32次方-1)個元素。 set的是通過hash table實現的，所以新增，刪除，查詢的複雜度都是O(1)。hash table會隨著新增或者刪除自動的調整大小。 需要注意的是調整hash table大小時候需要同步（獲取寫鎖）會阻塞其他讀寫操作。 可能不久後就會改用跳錶（skip list）來實現跳錶已經在sorted set中使用了 關於set集合型別除了基本的新增刪除操作，其他有用的操作還包含集合的取並集(union)，交集(intersection)， 差集(difference)。

6、sorted set

有序集合物件的編碼可以是ziplist或者skiplist。同時滿足以下條件時使用ziplist編碼：

  • 元素數量小於128個

  • 所有member的長度都小於64位元組

以上兩個條件的上限值可通過zset-max-ziplist-entries和zset-max-ziplist-value來修改。

ziplist編碼的有序集合使用緊挨在一起的壓縮列表節點來儲存，第一個節點儲存member，第二個儲存score。ziplist內的集合元素按score從小到大排序，score較小的排在表頭位置。

skiplist編碼的有序集合底層是一個命名為zset的結構體，而一個zset結構同時包含一個字典和一個跳躍表。跳躍表按score從小到大儲存所有集合元素。而字典則儲存著從member到score的對映，這樣就可以用O(1)的複雜度來查詢member對應的score值。雖然同時使用兩種結構，但它們會通過指標來共享相同元素的member和score，因此不會浪費額外的記憶體。

和set一樣sorted set也是string型別元素的集合，不同的是每個元素都會關聯一個double型別的score。sorted set的實現是skip list和hash table的混合體，當元素被新增到集合中時，一個元素到score的對映被新增到hash table中，所以給定一個元素獲取score的開銷是O(1)，另一個score到元素的對映被新增到skip list並按照score排序，所以就可以有序的獲取集合中的元素。 新增，刪除操作開銷都是O(1)和skip list的開銷一致，redis的skip list實現用的是雙向連結串列，這樣就可以逆序從尾部取元素。 sorted set最經常的使用方式應該是作為索引來使用，我們可以把要排序的欄位作為score儲存，物件的id當元素儲存。

相關推薦

redis內部資料結構深入淺出

最大感受，無論從設計還是原始碼，Redis都儘量做到簡單，其中運用到的原理也通俗易懂。特別是原始碼，簡潔易讀，真正做到clean and clear， 這篇文章以unstable分支的原始碼為基準，先從大體上整理Redis的物件型別以及底層編碼。 當我們在本文中提到Red

Redis內部資料結構詳解——intset

本文是《Redis內部資料結構詳解》系列的第七篇。在本文中，我們圍繞一個Redis的內部資料結構——intset展開討論。 Redis裡面使用intset是為了實現集合(set)這種對外的資料結構。set結構類似於數學上的集合的概念，它包含的元素無序，且不能重複。Redis裡的set結構還實現了

[轉]Redis內部資料結構詳解-sds

本文是《Redis內部資料結構詳解》系列的第二篇，講述Redis中使用最多的一個基礎資料結構：sds。 不管在哪門程式語言當中，字串都幾乎是使用最多的資料結構。sds正是在Redis中被廣泛使用的字串結構，它的全稱是Simple Dynamic String。與其它語言環境中出現的字串相比，它具有如下顯著的

Redis內部資料結構詳解(1)——dict

如果你使用過Redis，一定會像我一樣對它的內部實現產生興趣。《Redis內部資料結構詳解》是我準備寫的一個系列，也是我個人對於之前研究Redis的一個階段性總結，著重講解Redis在記憶體中的資料結構實現（暫不涉及持久化的話題）。Redis本質上是一個數據結構伺服器（data st

Redis內部資料結構詳解之整數集合(intset)

整數集合簡介 整數集合intset用於有序、無重複地儲存多個整數值，根據集合中元素的值自動選擇使用整數型別來儲存元素，例如：如果intset中絕對值最大的整數可以用int32_t來儲存，那麼整個

Redis內部資料結構詳解之字典(dict)

/* Expand or create the hash table */ int dictExpand(dict *d, unsigned long size) { dictht n; /* the new hash table */ unsigned long realsize = _di

Redis內部資料結構詳解(4)——ziplist

本文是《Redis內部資料結構詳解》系列的第四篇。在本文中，我們首先介紹一個新的Redis內部資料結構——ziplist，然後在文章後半部分我們會討論一下在robj, dict和ziplist的基礎上，Redis對外暴露的hash結構是怎樣構建起來的。 我們在討論中還會

Redis內部資料結構實現解析

當對value進行append操作時，顯然，最初建立時分配給sds的空間已無法滿足儲存要求，因而Redis會為buf[]動態分配儲存空間。當新字串的總長度小於時sds最大預分配長度時，新的儲存空間所能存放的字串長度為(oldStr.length + appendStr.length) * 2 + 1，其中後

Redis內部資料結構詳解之簡單動態字串(sds)

本文所引用的原始碼全部來自Redis2.8.2版本。 Redis中簡單動態字串sds資料結構與API相關檔案是：sds.h, sds.c。 預備知識 下面介紹有關sizeof計算引數

【Redis】內部資料結構自頂向下梳理

本部落格將順著自頂向下的思路梳理一下Redis的資料結構體系，從資料庫到物件體系，再到底層資料結構。我將基於我的一個專案的程式碼來進行介紹：[daredis](https://github.com/CuriousLei/daredis)。該專案中，使用Java實現了Redis中所有的資料結構，思想與Redis

Redis基本資料結構及SpringBoot中使用redisTemplate操作Redis

文章目錄 一、Redis環境 1、環境：CentOS7.0，redis-4.0.2 2、首先啟動redis服務 二、Redis資料結構 1、string（字串） （1）鍵值對 （2）使用

Redis rdb資料結構 原始碼詳解

記錄下來以後方便回憶，需要時隨時翻閱 一、Redis  RDB檔案的資料結構  二、Redis  RDB檔案的十六進位制碼和對應的字元   三、Redis  save和bgsave命令處理過程  

Redis底層資料結構--SDS

這是一種用於儲存二進位制資料的一種結構, 具有動態擴容的特點. 其實現位於src/sds.h與src/sds.c中, 其關鍵定義如下: typedef char *sds; /* Note: sdshdr5 is never used, we just access the flags byt

Redis底層資料結構--連結串列

這是普通的連結串列實現, 連結串列結點不直接持有資料, 而是通過void *指標來間接的指向資料. 其實現位於 src/adlist.h與src/adlist.c中, 關鍵定義如下: typedef struct listNode { struct listNode *prev

Redis底層資料結構dict

dict是Redis底層資料結構中實現最為複雜的一個數據結構, 其功能類似於C++標準庫中的std::unordered_map, 其實現位於 src/dict.h 與 src/dict.c中, 其關鍵定義如下: typedef struct dictEntry {

Redis 基礎資料結構（二）

1.String字串 string 是 Redis 最簡單的資料結構。Redis 所有的資料結構都是以唯一的 key 字串作為名稱，然後通過這個唯一 key 值來獲取相應的 value 資料。不同型別的資料結構的差異就在於 value 的結構不一樣。字串結構使用最為廣泛，最常見的就是快取資訊。一般情況下我們是

Redis的資料結構之字串

  今天呢，學習下Redis的資料結構，開始進入正題......   redis支援五種資料型別：       字串（String）       字串列表（list）       有序字串集合（sorted set）        雜湊（hash）      字串

Redis的資料結構之List

儲存list:       ArrayList使用陣列方式     LinkedList使用雙向連結方式 這裡主要講如下兩種:      雙向連結表中增加資料     雙向連結表中刪除資料 儲存list常用命令: 兩端新增 兩端彈出 擴充套件命令 lp

Redis的資料結構之Set

儲存Set      和List型別不同的是，Set集合中不允許出現重複的元素     Set可包含的最大元素數量是4294967295 儲存set常用命令：       新增/刪除元素       獲取集合中的元素       集合中的差集運算       集

Redis的資料結構之sorted-set

儲存Sorted-Set Sorted-Set和Set的區別:         Sorted-Set中的成員在集合中的位置是有序的 儲存Sorted-set常用命令        新增元素        獲得元素        刪除元素        範圍查詢