03-Redis存儲方式

關於Redis數據存儲的細節，涉及到內存分配器（如jemalloc）、簡單動態字符串（SDS）、5種對象類型及內部編碼、redisObject
這裏將說明這幾個概念之間的關係。

下圖是執行set hello world時，所涉及到的數據模型：

1. dictEntry：Redis是Key-Value數據庫，因此對每個鍵值對都會有一個dictEntry，裏面存儲了指向Key和Value的指針；next指向下一個dictEntry，與本Key-Value無關。
2. Key：圖中右上角可見，Key（”hello”）並不是直接以字符串存儲，而是存儲在SDS結構中。
3. redisObject：Value(“world”) 既不是直接以字符串存儲，也不是像Key一樣直接存儲在SDS中，而是存儲在redisObject中。實際上，不論Value是5種類型的哪一種，都是通過redisObject來存儲的；而redisObject中的type字段指明瞭Value對象的類型，ptr字段則指向對象所在的地址。不過可以看出，字符串對象雖然經過了redisObject的包裝，但仍然需要通過SDS存儲。實際上，redisObject除了type和ptr字段以外，還有其他字段圖中沒有給出，如用於指定對象內部編碼的字段
4. jemalloc：無論是DictEntry對象，還是redisObject、SDS對象，都需要內存分配器（如jemalloc）分配內存進行存儲。以DictEntry對象爲例，有3個指針組成，在64位機器下佔24個字節，jemalloc會爲它分配32字節大小的內存單元。

SDS–簡單動態字符串

• (1) SDS結構

struct sdsstr{
	// buf已使用的長度
	int len;
	// 示buf未使用的長度
	int free;
	// 字節數組，用來存儲字符串
	char buf[];
};

通過SDS的結構可以看出，buf數組的長度=free+len+1（其中1表示字符串結尾的空字符）
所以，一個SDS結構佔據的空間爲：free所佔長度+len所佔長度+ buf數組的長度=4+4+free+len+1=free+len+9

• (2) SDS與C字符串的比較
  SDS在C字符串的基礎上加入了free和len字段，帶來了很多好處：

1. 獲取字符串長度：SDS是O(1)，C字符串是O(n)
2. 緩衝區溢出：使用C字符串的API時，如果字符串長度增加（如strcat操作）而忘記重新分配內存，很容易造成緩衝區的溢出；而SDS由於記錄了長度，相應的API在可能造成緩衝區溢出時會自動重新分配內存，杜絕了緩衝區溢出。
3. 修改字符串時內存的重分配：對於C字符串，如果要修改字符串，必須要重新分配內存（先釋放再申請），因爲如果沒有重新分配，字符串長度增大時會造成內存緩衝區溢出，字符串長度減小時會造成內存泄露。而對於SDS，由於可以記錄len和free，因此解除了字符串長度和空間數組長度之間的關聯，可以在此基礎上進行優化：空間預分配策略（即分配內存時比實際需要的多）使得字符串長度增大時重新分配內存的概率大大減小；惰性空間釋放策略使得字符串長度減小時重新分配內存的概率大大減小。
4. 存取二進制數據：SDS可以，C字符串不可以。因爲C字符串以空字符作爲字符串結束的標識，而對於一些二進制文件（如圖片等），內容可能包括空字符串，因此C字符串無法正確存取；而SDS以字符串長度len來作爲字符串結束標識，因此沒有這個問題。

此外，由於SDS中的buf仍然使用了C字符串（即以’\0’結尾），因此SDS可以使用C字符串庫中的部分函數；但是需要注意的是，只有當SDS用來存儲文本數據時纔可以這樣使用，在存儲二進制數據時則不行（’\0’不一定是結尾）

• (3) SDS與C字符串的應用
  Redis在存儲對象時，一律使用SDS代替C字符串。

例如set hello world命令，hello和world都是以SDS的形式存儲的。
而sadd myset member1 member2 member3命令，不論是鍵（”myset”），還是集合中的元素 （”member1”、 ”member2”和”member3”），都是以SDS的形式存儲。 除了存儲對象，SDS還用於存儲各種緩衝區。
只有在字符串不會改變的情況下，如打印日誌時，纔會使用C字符串。

jemalloc

Redis在編譯時便會指定內存分配器；內存分配器可以是 libc 、jemalloc或者tcmalloc，默認是 jemalloc。

jemalloc作爲Redis的默認內存分配器，在減小內存碎片方面做的相對比較好。jemalloc在64位系統中，將內存空間劃分爲小、大、巨大三個範圍；每個範圍內又劃分了許多小的內存塊單位；當Redis存儲數據時，會選擇大小最合適的內存塊進行存儲。

jemalloc劃分的內存單元如下圖所示：

例如，如果需要存儲大小爲130

這裏是引用字節的對象，jemalloc會將其放入160字節的內存單元中

redisObject

Redis對象有

5種類型；無論是哪種類型，Redis都不會直接存儲，而是通過redisObject對象進行存儲。

redisObject對象非常重要，Redis對象的類型、內部編碼、內存回收、共享對象等功能，都需要redisObject支持，下面將通過redisObject的結構來說明它是如何起作用的。
redisObject的定義如下（列出了與保存數據有關的三個屬性）：

typedef struct redisObject{
	unsigned type: 4;
	unsigned encoding: 4;
	unsigned lru: REDIS_LRU_BITS;
	int refcount;
	void *ptr;
} robj

• (1) type
  type字段表示對象的類型，佔4個比特；
  目前包括REDIS_STRING(字符串)、REDIS_LIST (列表)、REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。
  當我們執行type命令時，便是通過讀取RedisObject的type字段獲得對象的類型；

127.0.0.1:6379> set test hello_redis
OK
127.0.0.1:6379> type test
string

127.0.0.1:6379> sadd myset member1 member2 member3
(integer) 3
127.0.0.1:6379> type myset
set

• (2) encoding
  encoding表示對象的內部編碼，佔4個比特。
  對於Redis支持的每種類型，都有至少兩種內部編碼，例如對於字符串，有int、embstr、raw三種編碼。
  通過encoding屬性，Redis可以根據不同的使用場景來爲對象設置不同的編碼，大大提高了Redis的靈活性和效率。

以列表對象爲例，有壓縮列表和雙端鏈表兩種編碼方式；如果列表中的元素較少，Redis傾向於使用壓縮列表進行存儲，因爲壓縮列表佔用內存更少，而且比雙端鏈表可以更快載入；當列表對象元素較多時，壓縮列表就會轉化爲更適合存儲大量元素的雙端鏈表。

通過object encoding命令，可以查看對象採用的編碼方式：

127.0.0.1:6379> set key1 123
OK
127.0.0.1:6379> object encoding key1
"int"
127.0.0.1:6379> set key1 helloredis
OK
127.0.0.1:6379> object encoding key1
"embstr"

• (3) lru
  lru記錄的是對象最後一次被命令程序訪問的時間，佔據的比特數不同的版本有所不同（如4.0版本佔24bit，2.6版本佔22bit）
  通過對比lru時間與當前時間，可以計算某個對象的閒置時間；object idletime命令可以顯示該閒置時間（單位是秒）。object idletime命令的一個特殊之處在於它不改變對象的lru值。

127.0.0.1:6379> set key1 helloredis
OK
127.0.0.1:6379> object idletime key1
(integer) 13
127.0.0.1:6379> object idletime key1
(integer) 37
127.0.0.1:6379> object idletime key1
(integer) 40
127.0.0.1:6379> object idletime key1
(integer) 43

lru值除了通過object idletime命令打印之外，還與Redis的內存回收有關係：
如果Redis打開了maxmemory選項，且內存回收算法選擇的是volatile-lru或allkeys—lru，那麼當Redis內存佔用超過maxmemory指定的值時，Redis會優先選擇空轉時間最長的對象進行釋放。

• (4) refcount

refcount與共享對象
refcount記錄的是該對象被引用的次數，類型爲整型。refcount的作用，主要在於對象的引用計數和內存回收。當創建新對象時，refcount初始化爲1；當有新程序使用該對象時，refcount加1；當對象不再被一個新程序使用時，refcount減1；當refcount變爲0時，對象佔用的內存會被釋放。
Redis中被多次使用的對象(refcount>1)，稱爲共享對象。 Redis爲了節省內存，當有一些對象重複出現時，新的程序不會創建新的對象，而是仍然使用原來的對象。這個被重複使用的對象，就是共享對象。目前共享對象僅支持整數值的字符串對象。

共享對象的具體實現
Redis的共享對象目前只支持整數值的字符串對象。之所以如此，實際上是對內存和CPU（時間）的平衡：共享對象雖然會降低內存消耗，但是判斷兩個對象是否相等卻需要消耗額外的時間。對於整數值，判斷操作複雜度爲O(1)；對於普通字符串，判斷複雜度爲O(n)；而對於哈希、列表、集合和有序集合，判斷的複雜度爲O(n^2)。
雖然共享對象只能是整數值的字符串對象，但是5種類型都可能使用共享對象（如哈希、列表等的元素可以使用）。
就目前的實現來說，Redis服務器在初始化時，會創建10000個字符串對象，值分別是0 ~ 9999的整數值；當Redis需要使用值爲0 ~ 9999的字符串對象時，可以直接使用這些共享對象。10000這個數字可以通過調整參數REDIS_SHARED_INTEGERS（4.0中是OBJ_SHARED_INTEGERS）的值進行改變。共享對象的引用次數可以通過object refcount命令查看，如下圖所示。命令執行的結果頁佐證了只有0~9999之間的整數會作爲共享對象。

127.0.0.1:6379> set k1 9999
OK
127.0.0.1:6379> set k2 9999
OK
127.0.0.1:6379> set k3 9999
OK
127.0.0.1:6379> object refcount k1
(integer) 2147483647

127.0.0.1:6379> set k1 10000
OK
127.0.0.1:6379> set k2 10000
OK
127.0.0.1:6379> set k3 10000
OK
127.0.0.1:6379> object refcount k1
(integer) 1

127.0.0.1:6379> set k1 hello
OK
127.0.0.1:6379> set k2 hello
OK
127.0.0.1:6379> set k3 hello
OK
127.0.0.1:6379> object refcount k1
(integer) 1

• (5) ptr

ptr指針指向具體的數據，如前面的例子中，set hello world，ptr指向包含字符串world的SDS。

綜上所述，redisObject的結構與對象類型、編碼、內存回收、共享對象都有關係；一個redisObject對象的大小爲16字節：

4bit+4bit+24bit+4Byte+8Byte=16Byte