關於redis中的字元串對象

一、SDS

redis中定義Object types有5種

/* Object types */
#define REDIS_STRING 0
#define REDIS_LIST 1
#define REDIS_SET 2
#define REDIS_ZSET 3
#define REDIS_HASH 4

Objects encoding有9種　

#define REDIS_ENCODING_RAW 0     /* Raw representation */
#define REDIS_ENCODING_INT 1     /* Encoded as integer */
#define REDIS_ENCODING_HT 2      /* Encoded as hash table */
#define REDIS_ENCODING_ZIPMAP 3  /* Encoded as zipmap */
#define REDIS_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */
#define REDIS_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
#define REDIS_ENCODING_INTSET 6  /* Encoded as intset */
#define REDIS_ENCODING_SKIPLIST 7  /* Encoded as skiplist */
#define REDIS_ENCODING_EMBSTR 8  /* Embedded sds string encoding */

關於SDS的結構，在sds.h文件中定義

struct sdshdr {
    int len;// 記錄buf數組中已使用位元組的數量，等於SDS所保存字元串的長度
    int free;//記錄buf數組中未使用位元組的數量
    char buf[]; // 位元組數組，用於保存字元串
};

這個與C中定義有一些區別

1、對於運算或者連接(strcat）等的時候，不需要每次都擴展字元串（空間換時間），這樣對記憶體可以大量的記憶體分配；還可以避免緩衝區的溢出，

2、strlen計算長度的時候時間複雜度是O(n)，而這裡直接記錄，時間複雜度為1

3、SDS遵循C字元串以空字元結尾（\0）的慣例，遵循這一慣例SDS可以直接重用一部分C字元串函數庫裡面的函數

二、對象類型

/* A redis object, that is a type able to hold a string / list / set */
  
/* The actual Redis Object */
#define REDIS_LRU_BITS 24
#define REDIS_LRU_CLOCK_MAX ((1<<REDIS_LRU_BITS)-1) /* Max value of obj->lru */
#define REDIS_LRU_CLOCK_RESOLUTION 1000 /* LRU clock resolution in ms */
typedef struct redisObject {
    unsigned type:4;//(REDIS_STRING,REDIS_LIST,REDIS_HASH,REDIS_SET,REDIS_ZSET)
    unsigned encoding:4; // 1
    unsigned lru:REDIS_LRU_BITS; //記憶體緊張的時候使用
    int refcount;
    void *ptr;//數據指針，例如：10086
} robj;

redis 中定義了 struct redisObject，它是一個簡單優秀的數據結構，因為在 redisObject 中數據屬性和數據分開來了，其中，數據屬性包括數據類型，存儲編碼方式，淘汰時鐘，引用計數

淘汰時鐘，redis 對數據集占用記憶體的大小有「實時」的計算，當超出限額時，會淘汰超時的數據。

引用計數，一個 redis 對象可能被多個指針引用。當需要增加或者減少引用的時候，必須調用相應的函數，程式員必須遵守這一准則

// 增加 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--;
    }
}

字元串對象底層數據結構當然可以全部是SDS，但是在某些場景下SDS可能不是最優解

三、字元串對象編碼

可以是 int 、 raw 或者 embstr

A、整形

如果一個字元串對象保存的是整數值，並且這個整數值可以用long類型來表示，那麼字元串對象會將整數值保存在字元串對象結構的ptr屬性裡面（將void*轉換成long），並將字元串對象的編碼設置為int

相對於SDS優勢在於 1、節省記憶體 2、對於整數值的字元串對象可能會被執行INCR操作，SDS需要先將字元串轉成整形，在執行加減操作，再將結果轉成字元串保存如果底層保存一個整形變數就不需要做類型轉換了

B、字元串值

如果字元串對象保存的是一個字元串值， 並且這個字元串值的長度大於 39 位元組， 那麼字元串對象將使用一個簡單動態字元串（SDS）來保存這個字元串值， 並將對象的編碼設置為 raw

如果字元串對象保存的是一個字元串值， 並且這個字元串值的長度小於等於 39 位元組， 那麼字元串對象將使用 embstr 編碼的方式來保存這個字元串值

embstr與sdshdr區別

embstr 編碼是專門用於保存短字元串的一種優化編碼方式， 這種編碼和 raw 編碼一樣， 都使用 redisObject 結構和 sdshdr 結構來表示字元串對象

raw 編碼會調用兩次記憶體分配函數來分別創建 redisObject 結構和 sdshdr 結構， 而 embstr 編碼則通過調用一次記憶體分配函數來分配一塊連續的空間， 空間中依次包含 redisObject 和 sdshdr 兩個結構、

embstr 有以下好處

• embstr 編碼將創建字元串對象所需的記憶體分配次數從 raw 編碼的兩次降低為一次

• 釋放 embstr 編碼的字元串對象只需要調用一次記憶體釋放函數， 而釋放 raw 編碼的字元串對象需要調用兩次記憶體釋放函數

• 因為 embstr 編碼的字元串對象的所有數據都保存在一塊連續的記憶體裡面， 所以這種編碼的字元串對象比起 raw 編碼的字元串對象能夠更好地利用緩存帶來的優勢

四、編碼的轉換

int 編碼的字元串對象和 embstr 編碼的字元串對象在條件滿足的情況下， 會被轉換為 raw 編碼的字元串對象。

對於 int 編碼的字元串對象來說， 如果我們向對象執行了一些命令， 使得這個對象保存的不再是整數值， 而是一個字元串值， 那麼字元串對象的編碼將從 int 變為 raw 。

在下麵的示例中， 我們通過 APPEND 命令， 向一個保存整數值的字元串對象追加了一個字元串值， 因為追加操作只能對字元串值執行， 所以程式會先將之前保存的整數值 10086 轉換為字元串值 "10086" ， 然後再執行追加操作， 操作的執行結果就是一個 raw 編碼的、保存了字元串值的字元串對象：

redis> SET number 10086
OK

redis> OBJECT ENCODING number
"int"

redis> APPEND number " is a good number!"
(integer) 23

redis> GET number
"10086 is a good number!"

redis> OBJECT ENCODING number
"raw"

另外， 因為 Redis 沒有為 embstr 編碼的字元串對象編寫任何相應的修改程式 （只有 int 編碼的字元串對象和 raw 編碼的字元串對象有這些程式）， 所以 embstr 編碼的字元串對象實際上是只讀的： 當我們對 embstr 編碼的字元串對象執行任何修改命令時， 程式會先將對象的編碼從 embstr 轉換成 raw ， 然後再執行修改命令； 因為這個原因， embstr 編碼的字元串對象在執行修改命令之後， 總會變成一個 raw 編碼的字元串對象。

以下代碼展示了一個 embstr 編碼的字元串對象在執行 APPEND 命令之後， 對象的編碼從 embstr 變為 raw 的例子：

redis> SET msg "hello world"
OK

redis> OBJECT ENCODING msg
"embstr"

redis> APPEND msg " again!"
(integer) 18

redis> OBJECT ENCODING msg
"raw"

五、字元串命令的實現

因為字元串鍵的值為字元串對象， 所以用於字元串鍵的所有命令都是針對字元串對象來構建的， 表 8-7 列舉了其中一部分字元串命令， 以及這些命令在不同編碼的字元串對象下的實現方法

六、embstr為什麼是39　

這要從記憶體分配說起了，embstr是一塊連續的記憶體區域，由redisObject和sdshdr組成

使用info查看，redis的記憶體分配方式為：mem_allocator:jemalloc-3.6.0（redis 2.4以後），這個比glibc的malloc要好不少，節省記憶體。在這裡可以簡單理解，jemalloc會分配8，16，32，64等位元組的記憶體

再看一下結構體

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
    int refcount;
    void *ptr;
} robj;
struct sdshdr {
    unsigned int len;
    unsigned int free;
    char buf[];
};

redisObject 占（4+4+24)/4+4+4 = 16 位元組，sdshdr為8+1 +一個不固定的值(這裡的1是指\0)，那麼64-25 = 39 ，這樣39就來了