Redis 沒有直接使用C語言傳統的字符串表示,而是本身構建了一種名爲簡單動態字符串(simple dynamic string SDS)的抽象類型,並將SDS用做Redis 的默認字符串表示:redis
10.143.128.165:6379> SET msg "hello world" OK
設置一個key= msg,value = hello world 的新鍵值對,算法
鍵(key)是一個字符串對象,對象的底層實現是一個保存着字符串「msg」 的SDS;數組
值(value)也是一個字符串對象,對象的底層實現是一個保存着字符串「hello world」 的SDS安全
SDS除了用來保存字符串之外,SDS還被用做緩衝區(buffer)AOF模塊中的AOF緩衝區。數據結構
Redis 中定義動態字符串的結構:函數
/* * 保存字符串對象的結構 */ struct sdshdr { int len;// buf 中已佔用空間的長度 int free;// buf 中剩餘可用空間的長度 char buf[];// 數據空間 };
一、len 變量,用於記錄buf 中已經使用的空間長度(這裏指出Redis 的長度爲5)優化
二、free 變量,用於記錄buf 中還空餘的空間(初次分配空間,通常沒有空餘,在對字符串修改的時候,會有剩餘空間出現)ui
三、buf 字符數組,用於記錄咱們的字符串(記錄Redis)編碼
C 字符串 | SDS |
獲取字符串長度的複雜度爲O(N) | 獲取字符串長度的複雜度爲O(1) |
API 是不安全的,可能會形成緩衝區溢出 | API 是安全的,不會形成緩衝區溢出 |
修改字符串長度N次必然須要執行N次內存重分配 | 修改字符串長度N次最多執行N次內存重分配 |
只能保存文本數據 | 能夠保存二進制數據和文本文數據 |
可使用全部<String.h>庫中的函數 | 可使用一部分<string.h>庫中的函數 |
1 獲取字符串長度(SDS O(1)/C 字符串 O(n))spa
傳統的C 字符串 使用長度爲N+1 的字符串數組來表示長度爲N 的字符串,因此爲了獲取一個長度爲C字符串的長度,必須遍歷整個字符串。
SDS 的數據結構中,有專門用於保存字符串長度的變量,能夠經過獲取len 屬性的值,直接知道字符串長度。
2 杜絕緩衝區溢出
C 字符串 不記錄字符串長度,除了獲取的時候複雜度高之外,還容易致使緩衝區溢出。
假設程序中有兩個在內存中緊鄰着的 字符串 s1 和 s2,其中s1 保存了字符串「redis」,二s2 則保存了字符串「MongoDb」:
若是咱們如今將s1 的內容修改成redis cluster,可是又忘了從新爲s1 分配足夠的空間,這時候就會出現如下問題:
本來s2 中的內容已經被S1的內容給佔領了,s2 如今爲 cluster,而不是「Mongodb」。
當須要對一個SDS 進行修改的時候,redis 會在執行拼接操做以前,預先檢查給定SDS 空間是否足夠,若是不夠,會先拓展SDS 的空間,而後再執行拼接操做:
3 減小修改字符串時帶來的內存重分配次數
C語言字符串在進行字符串的擴充和收縮的時候,都會面臨着內存空間的從新分配問題。
1. 字符串拼接會產生字符串的內存空間的擴充,在拼接的過程當中,原來的字符串的大小極可能小於拼接後的字符串的大小,那麼這樣的話,就會致使一旦忘記申請分配空間,就會致使內存的溢出。
2. 字符串在進行收縮的時候,內存空間會相應的收縮,而若是在進行字符串的切割的時候,沒有對內存的空間進行一個從新分配,那麼這部分多出來的空間就成爲了內存泄露。
咱們須要對下面的SDS進行拓展,則須要進行空間的拓展,這時候redis 會將SDS的長度修改成13字節,而且將未使用空間一樣修改成1字節
由於在上一次修改字符串的時候已經拓展了空間,再次進行修改字符串的時候會發現空間足夠使用,所以無須進行空間拓展
經過這種預分配策略,SDS將連續增加N次字符串所需的內存重分配次數從一定N次下降爲最多N次
4 惰性空間釋放
SDS 的free 屬性,是用於記錄空餘空間的。除了在拓展字符串的時候會使用到free 來進行記錄空餘空間之外,在對字符串進行收縮的時候,也可使用free 屬性來進行記錄剩餘空間,避免下次對字符串進行再次修改的時候,須要對字符串的空間進行拓展。
SDS 提供了相應的API,能夠在有須要的時候,自行釋放SDS 的空餘空間。
經過惰性空間釋放,SDS 避免了縮短字符串時所需的內存重分配操做,並未未來可能有的增加操做提供了優化
5 二進制安全
C 字符串中的字符必須符合某種編碼,而且除了字符串的末尾以外,字符串裏面不能包含空字符,不然最早被程序讀入的空字符將被誤認爲是字符串結尾,這些限制使得C字符串只能保存文本數據,而不能保存想圖片,音頻,視頻,壓縮文件這樣的二進制數據。
Redis 不是靠空字符來判斷字符串的結束的,而是經過len這個屬性。
6 兼容部分C字符串函數
雖然SDS 的API 都是二進制安全的,但同樣遵循C字符串以空字符串結尾的慣例。
========================================================================
鏈表提供了高效的節點重排能力,以及順序性的節點訪問方式,而且能夠經過增刪節點來靈活地調整鏈表的長度。
Redis 中 列表鍵的底層實現之一就是鏈表。當一個列表鍵包含了數量較多的元素,又或者列表中包含的元素都是比較長的字符串時,Redis 就會使用鏈表做爲列表鍵的底層實現。
每一個鏈表節點使用一個 listNode結構表示:
typedef struct listNode{ struct listNode *prev; struct listNode * next; void * value; }
多個鏈表節點組成的雙端鏈表:
list:
typedef struct list{ listNode * head;//表頭節點 listNode * tail;//表尾節點 unsigned long len;//鏈表長度 void *(*dup) (void *ptr);//節點值複製函數 void (*free) (void *ptr);//節點值釋放函數 int (*match)(void *ptr, void *key);//節點值對比函數 }
========================================================================
字典,又稱爲符號表(symbol table)、關聯數組(associative array)或映射(map),是一種用於保存鍵值對的抽象數據結構。
在字典中,一個鍵(key)能夠和一個值(value)進行關聯,字典中的每一個鍵都是獨一無二的。在C語言中,並無這種數據結構,可是Redis 中構建了本身的字典實現。
10.143.128.165:6379> SET msg "hello world" OK
Redis 字典所使用的哈希表由 dict.h/dictht 結構定義:
typedef struct dictht { dictEntry **table; //哈希表數組 unsigned long size;//哈希表大小 unsigned long sizemask;//哈希表大小掩碼,用於計算索引值 unsigned long used;//該哈希表已有節點的數量 }
一個空的字典的結構圖以下:
在結構中存有指向dictEntry 數組的指針,而咱們用來存儲數據的空間就是 dictEntry
typeof struct dictEntry{ void *key; //鍵 union{ //值 void *val; uint64_tu64; int64_ts64; } struct dictEntry *next; }
在數據結構中,key 是惟一的,可是存入裏面的key 並非直接的字符串,而是一個hash 值,經過hash 算法,將字符串轉換成對應的hash 值,而後在dictEntry 中找到對應的位置。
若是出現hash 值相同的狀況,Redis 採用了鏈地址法:
當k1 和k0 的hash 值相同時,將k1中的next 指向k0 造成一個鏈表。
typedef struct dict { dictType *type; // 類型特定函數 void *privedata; // 私有數據 dictht ht[2]; // 哈希表 in trehashidx; // rehash 索引 }
type 屬性 和privdata 屬性是針對不一樣類型的鍵值對,爲建立多態字典而設置的。
ht 屬性是一個包含兩個項(兩個哈希表)的數組
普通狀態下的字典:
在插入一條新的數據時,會進行哈希值的計算,若是出現了hash值相同的狀況,Redis 中採用了連地址法(separate chaining)來解決鍵衝突。每一個哈希表節點都有一個next 指針,多個哈希表節點可使用next 構成一個單向鏈表,被分配到同一個索引上的多個節點可使用這個單向鏈表鏈接起來解決hash值衝突的問題。
如今要插入k2,經過hash 算法計算到k2 的hash 值爲2,即須要將k2 插入到dictEntry[2]中:
在插入後,dictEntry指向了k2,k2的next 指向了k1,從而完成了一次插入操做(這裏選擇表頭插入是由於哈希表節點中沒有記錄鏈表尾節點位置)
Rehash
隨着對哈希表的不斷操做,哈希表保存的鍵值對會逐漸的發生改變,爲了讓哈希表的負載因子維持在一個合理的範圍以內,須要對哈希表的大小進行相應的擴展或者壓縮,能夠經過 rehash(從新散列)操做來完成。
1 目前的哈希表狀態:
若是執行的是拓展操做,那麼ht[1] 的大小爲第一個大於等於ht[0] 的2的n次冪
若是執行的是收縮操做,那麼ht[1] 的大小爲第一個大於等於ht[0] 的2的n次冪
所以這裏 爲ht[1] 分配 空間爲8,
3 數據轉移
將ht[0]中的數據轉移到ht[1]中,在轉移的過程當中,須要對哈希表節點的數據從新進行哈希值計算
數據轉移後的結果:
4 釋放ht[0]
將ht[0]釋放,而後將ht[1]設置成ht[0],最後爲ht[1]分配一個空白哈希表:
5 漸進式 rehash
在進行拓展或者壓縮的時候,能夠直接將全部的鍵值對rehash 到ht[1]中,這是由於數據量比較小。
在實際開發過程當中,這個rehash 操做並非一次性、集中式完成的,而是分屢次、漸進式地完成的。
漸進式rehash 的詳細步驟:
一、爲ht[1] 分配空間,讓字典同時持有ht[0]和ht[1]兩個哈希表
二、在幾點鐘維持一個索引計數器變量rehashidx,並將它的值設置爲0,表示rehash 開始
三、在rehash 進行期間,每次對字典執行CRUD操做時,程序除了執行指定的操做之外,還會將ht[0]中的數據rehash 到ht[1]表中,而且將rehashidx加一
四、當ht[0]中全部數據轉移到ht[1]中時,將rehashidx 設置成-1,表示rehash 結束
採用漸進式rehash 的好處在於它採起分而治之的方式,避免了集中式rehash 帶來的龐大計算量。
待續