1.keys命令
keys命令相信大家應該都用過,該命令會遍歷整個redis的字典空間,對要查找的key進行匹配並返回。
就像官方文檔所說:在生產環境使用該方法的過程中要非常小心,因爲redis服務器在執行該命令的時候其他客戶端讀寫命令都會被阻塞。
使用方法:
KEYS pattern
示例:
127.0.0.1:6379> set why1 1
OK
127.0.0.1:6379> set why2 2
OK
127.0.0.1:6379> set why3 3
OK
127.0.0.1:6379> set why4 4
OK
127.0.0.1:6379> keys why*
1) "why3"
2) "why4"
3) "why2"
4) "why1"
127.0.0.1:6379>
2.redis的HashTable(字典)
keys命令,是遍歷整個數據庫。而redis是又是一個k-v型的內存數據庫,一說到k-v,不由自主就想到了Java的HashMap。那麼redis的"hashtable"的數據結構是什麼樣的呢?
1.HashTable的數據結構上下文
我們以debug模式運行redis-server的時候,可以看到在redis.c的initServer方法中,初始化了db。
dbnum的值來源於配置:databases,默認爲16。
在Redis.h中,對每個數據庫實例做了定義:
/* Redis database representation. There are multiple databases identified
* by integers from 0 (the default database) up to the max configured
* database. The database number is the 'id' field in the structure. */
typedef struct redisDb {
dict *dict; /* The keyspace for this DB */
//刪除了一些參數.......
} redisDb;
那看樣子,dict可能是對應的哈希表實現了,我們看下dict的結構:
/* This is our hash table structure. Every dictionary has two of this as we
* implement incremental rehashing, for the old to the new table. */
typedef struct dict {
//一系列操作鍵值空間的函數
dictType *type;
//私有數據
void *privdata;
dictht ht[2];
int rehashidx; /* rehashing not in progress if rehashidx == -1 */
int iterators; /* number of iterators currently running */
} dict;
看樣子dict並不是最終的哈希表。我們繼續看下dictht的結構:
typedef struct dictht {
// hash表的數組
dictEntry **table;
//表的大小
unsigned long size;
//size-1,用於計算索引
unsigned long sizemask;
//hash表中元素的數量
unsigned long used;
} dictht;
看樣子dicttht就是哈希表的實現了。可以看到dictht中定義了一個dictEntry類型的數組table,又定義了一系列的和table有關的上下文。
我們繼續看下dictEntry的結構:
typedef struct dictEntry {
void *key;
union {
void *val;
uint64_t u64;
int64_t s64;
} v;
struct dictEntry *next;
} dictEntry;
看樣子dictEntry就是存儲我們數據的地方了,看到next指針,我們可以猜到,redis解決hash衝突的方法和HashMap一樣,也是拉鍊法。
到這裏我們可以總結一下:
-
dict是hash表的最外層,存儲了整個鍵值空間。並通過dictType定義了一系列的操作鍵值的函數。
-
dictht是hash表的實現,定義了hash表的數據結構。
-
而dictEntry則是定義了數據的存放結構。
2.漸進式rehash
redis的哈希表和HashMap在設計上面一個比較明顯不同就是rehash操作。因爲redis的定義是一個數據庫。所以其存放的數據會很多很多,爲了防止在rehash的過程中因爲大批量數據需要做遷移而引起的服務器長時間阻塞,redis採用的方法是漸進式rehash。
首先我們重新看一下dict結構體,它定義了2個hashtable。其中ht[1]就是協助完成漸進式rehash的。
typedef struct dict {
//一系列操作鍵值空間的函數
dictType *type;
//私有數據
void *privdata;
dictht ht[2];
int rehashidx; /* rehashing not in progress if rehashidx == -1 */
int iterators; /* number of iterators currently running */
} dict;
1.rehash的觸發
就拿新增操作來說,每次新增前,都會調用_dictExpandIfNeeded,檢測一下是否要進行擴容操作:
static int _dictExpandIfNeeded(dict *d)
{
/* Incremental rehashing already in progress. Return. */
if (dictIsRehashing(d)) return DICT_OK;
/* If the hash table is empty expand it to the initial size. */
// T = O(1)
if (d->ht[0].size == 0) return dictExpand(d, DICT_HT_INITIAL_SIZE);
/* If we reached the 1:1 ratio, and we are allowed to resize the hash
* table (global setting) or we should avoid it but the ratio between
* elements/buckets is over the "safe" threshold, we resize doubling
* the number of buckets. */
if (d->ht[0].used >= d->ht[0].size &&
(dict_can_resize ||
d->ht[0].used/d->ht[0].size > dict_force_resize_ratio))
{
// 擴容到原來的2倍
return dictExpand(d, d->ht[0].used*2);
}
return DICT_OK;
}
如果滿足下面的case,就會調用dictExpand函數:
-
使用的數量used大於當前字典的長度size。
-
參數dict_can_resize爲1或者當前數組長度滿足強制擴容閾值dict_force_resize_ratio
就會去調用dictExpand函數,將當前字典擴容到已經使用元素的二倍。
可以看到當我添加第16個元素的時候 就觸發擴容操作了。
dictExpand函數負責擴容的的初始化動作(我們只看擴容部分的賦值邏輯):
-
調用_dictNextPower函數修正size,保證其大小始終是2的N次冪。
-
然後將dict中的ht[1]設置爲擴容後的hashtable,並將rehashidx從-1設置爲0。
int dictExpand(dict *d, unsigned long size)
{
dictht n; /* the new hash table */
unsigned long realsize = _dictNextPower(size);
/* the size is invalid if it is smaller than the number of
* elements already inside the hash table */
if (dictIsRehashing(d) || d->ht[0].used > size)
return DICT_ERR;
/* Allocate the new hash table and initialize all pointers to NULL */
n.size = realsize;
n.sizemask = realsize-1;
// T = O(N)
n.table = zcalloc(realsize*sizeof(dictEntry*));
n.used = 0;
/* Is this the first initialization? If so it's not really a rehashing
* we just set the first hash table so that it can accept keys. */
if (d->ht[0].table == NULL) {
d->ht[0] = n;
return DICT_OK;
}
/* Prepare a second hash table for incremental rehashing */
d->ht[1] = n;
d->rehashidx = 0;
return DICT_OK;
}
2.dict_force_resize_ratio和dict_can_resize
允許擴容的第二個條件中,需要dict_can_resize=1才允許擴容。這個參數的作用是什麼?什麼情況下dict_can_resize會被更新成0?
帶着這兩個問題我們看下dict_can_resize變量的註釋:
/* Using dictEnableResize() / dictDisableResize() we make possible to
* enable/disable resizing of the hash table as needed. This is very important
* for Redis, as we use copy-on-write and don't want to move too much memory
* around when there is a child performing saving operations.
* Note that even when dict_can_resize is set to 0, not all resizes are
* prevented: a hash table is still allowed to grow if the ratio between
* the number of elements and the buckets > dict_force_resize_ratio.
*/
static int dict_can_resize = 1;
static unsigned int dict_force_resize_ratio = 5;
註釋中說的很清楚:不希望在執行寫時複製的過程中再過多的去操作內存。
個人理解:save操作(比如 bgsave )通過fork函數創建的子進程,使用的是寫時複製。執行save的過程中一方面有大量的讀取內存的操作(子進程);另一方面如果在寫時複製的過程中,redis服務端(父進程)又收到大量的寫操作,那麼就會觸發共享對象的只讀保護,引發缺頁中斷,進而觸發頁面的複製和頁表的更新,這個時候系統負載會很大。爲了降低系統負載,就嘗試先關閉數據的遷移(數據遷移的過程中也涉及到了內存的讀寫操作)。
但是dict_can_resize並不會完全的去關閉遷移操作,如果這個時候load factor(used和size之比)超過dict_force_resize_ratio=5了,那麼就強制做一次rehash。
3. 漸進rehash的處理
1.增刪改查前協助rehash
進行rehash的函數是_dictRehashStep,該函數分別被dictAddRaw,dictGenericDelete,dictFind,dictGetRandomKey函數所調用。也就說redis每次在執行指令的時候都會嘗試做一次數據遷移操作:
判斷代碼如下:
//還記得嗎?在rehash開始前,將rehashidx設置爲了0.
//如果當前rehashidx不爲-1 說明在進行擴容
if (dictIsRehashing(d))
{
_dictRehashStep(d);
}
//dictIsRehashing的判斷邏輯就是判斷是否等於-1
#define dictIsRehashing(ht) ((ht)->rehashidx != -1)
具體的,協助擴容代碼如下:
當不存在安全迭代器的時候,進行一次數據的遷移。
static void _dictRehashStep(dict *d) {
if (d->iterators == 0)
dictRehash(d,1);
}
dictRehash函數是真正做數據遷移的操作,n控制遷移的步數。可以知道的是在進行增刪改查操作前,redis每次遷移1個hash槽下所有的數據到新的哈希表中:
int dictRehash(dict *d, int n) {
if (!dictIsRehashing(d)) return 0;
// 遷移次數
while(n--) {
dictEntry *de, *nextde;
/* Check if we already rehashed the whole table... */
//在下面可以看到每次遷移完成一個元素後,used都會做一個減1的操作. 那麼當used等於0的時候,說明遷移結束了
if (d->ht[0].used == 0) {
//做一些數據的釋放和hashtable的替換。
zfree(d->ht[0].table);
d->ht[0] = d->ht[1];
_dictReset(&d->ht[1]);
//設置當前狀態爲非擴容的標記
d->rehashidx = -1;
//返回0 說明rehash結束
return 0;
}
//越界判斷
assert(d->ht[0].size > (unsigned)d->rehashidx);
//在舊的hashtable中找到一個非空的鏈表
while(d->ht[0].table[d->rehashidx] == NULL) d->rehashidx++;
de = d->ht[0].table[d->rehashidx];
//遷移開始
//整個while循環中做的操作就是將舊鏈表中的元素拿出來重新計算hash值,然後放到新hashtable中,並更新新舊hashtable的used
while(de) {
unsigned int h;
nextde = de->next;
h = dictHashKey(d, de->key) & d->ht[1].sizemask;
de->next = d->ht[1].table[h];
d->ht[1].table[h] = de;
d->ht[0].used--;
d->ht[1].used++;
de = nextde;
}
d->ht[0].table[d->rehashidx] = NULL;
// 更新rehashidx。也就是說rehashidx不等於的時候,它所指向的就是下一個要進行擴容的hash槽
d->rehashidx++;
}
//返回1 說明還需要繼續rehash
return 1;
}
2.定時事件中處理擴容
如果說我們的redis服務器正在擴容,但是還沒什麼讀寫請求,那這擴容總不能停下來不做了吧?所以redis除了在執行命令前做一個單步擴容外,在其定時事件中,也做了一次rehash操作:
void databasesCron(void) {
//省略和擴容無關的代碼.....
//沒有做後臺線程在工作,纔去做協助做rehash。
if (server.rdb_child_pid == -1 && server.aof_child_pid == -1) {
if (server.activerehashing) {
for (j = 0; j < dbs_per_call; j++) {
int work_done = incrementallyRehash(rehash_db % server.dbnum);
rehash_db++;
if (work_done) {
/* If the function did some work, stop here, we'll do
* more at the next cron loop. */
break;
}
}
}
}
}
}
定時事件做遷移的前提:
-
沒有rdb和aof在執行。
-
Redid.config中的activerehashing配置開啓。關於該配置的介紹:
# Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in
# order to help rehashing the main Redis hash table (the one mapping top-level
# keys to values). The hash table implementation Redis uses (see dict.c)
# performs a lazy rehashing: the more operation you run into a hash table
# that is rehashing, the more rehashing "steps" are performed, so if the
# server is idle the rehashing is never complete and some more memory is used
# by the hash table.
#
# The default is to use this millisecond 10 times every second in order to
# active rehashing the main dictionaries, freeing memory when possible.
#
# If unsure:
# use "activerehashing no" if you have hard latency requirements and it is
# not a good thing in your environment that Redis can reply form time to time
# to queries with 2 milliseconds delay.
#
# use "activerehashing yes" if you don't have such hard requirements but
# want to free memory asap when possible.
一次處理100個hash槽下面的數據:
int dictRehashMilliseconds(dict *d, int ms) {
long long start = timeInMilliseconds();
int rehashes = 0;
while(dictRehash(d,100)) {
rehashes += 100;
if (timeInMilliseconds()-start > ms) break;
}
return rehashes;
}
3.keys命令的處理邏輯
說完了字典的數據結構和擴容操作後,我們回到key命令,看下keys命令的處理邏輯。keys命令的處理函數是src/db.c的keysCommand函數:
void keysCommand(redisClient *c) {
dictIterator *di;
dictEntry *de;
// 得到匹配模式
sds pattern = c->argv[1]->ptr;
int plen = sdslen(pattern), allkeys;
unsigned long numkeys = 0;
void *replylen = addDeferredMultiBulkLength(c);
// 獲取一個安全迭代器 迭代當前連接的整個db
di = dictGetSafeIterator(c->db->dict);
allkeys = (pattern[0] == '*' && pattern[1] == '\0');
while((de = dictNext(di)) != NULL) {
sds key = dictGetKey(de);
robj *keyobj;
// 將鍵名和模式進行比對
if (allkeys || stringmatchlen(pattern,plen,key,sdslen(key),0)) {
// 創建一個保存鍵名字的字符串對象
keyobj = createStringObject(key,sdslen(key));
// 刪除已過期鍵
if (expireIfNeeded(c->db,keyobj) == 0) {
addReplyBulk(c,keyobj);
numkeys++;
}
decrRefCount(keyobj);
}
}
//釋放安全迭代器
dictReleaseIterator(di);
setDeferredMultiBulkLength(c,replylen,numkeys);
}
處理邏輯很簡單:解析命令,然後遍歷當前連接對應的db,檢查是否匹配,檢查數據是否過期,最後將數據返回。
但是這個過程中,獲取了一個安全迭代器,爲什麼有安全迭代器?安全指的是什麼安全?線程安全嗎?
4.安全迭代器和非安全迭代器
1.迭代器的上下文
先看下迭代器的結構體定義的參數:
/* If safe is set to 1 this is a safe iterator, that means, you can call
* dictAdd, dictFind, and other functions against the dictionary even while
* iterating. Otherwise it is a non safe iterator, and only dictNext()
* should be called while iterating. */
typedef struct dictIterator {
// 字典
dict *d;
int
table, //當前迭代器指向的hashtable,因爲rehash存在2個hashtable,所以迭代器需要知道當前遍歷到哪個了。
index, //迭代器所指向的hashtable的位置。
safe; //是否爲安全迭代器
// entry :當前迭代的節點
// nextEntry :當前節點的下一個節點
dictEntry *entry, *nextEntry;
long long fingerprint; //指紋。非安全迭代器釋放前做驗證用
} dictIterator;
從作者的註釋中我們可以知道的是:迭代器區分安全和非安全,並不是爲了處理併發問題,而是決定遍歷的過程中可以不可以去修改數據。
安全迭代器在其迭代過程中,允許執行其他對字典的操作(最典型的就是過期鍵的清理)。
而非安全迭代器只能做遍歷使用。
2.安全迭代器的創建
我們先看下安全迭代器的創建過程,安全迭代器的創建函數是dictGetSafeIterator:
dictIterator *dictGetSafeIterator(dict *d) {
dictIterator *i = dictGetIterator(d);
// 設置安全迭代器標識
i->safe = 1;
return i;
}
內部調用了dictGetIterator函數,它的作用就是初始化迭代器:
dictIterator *dictGetIterator(dict *d)
{
dictIterator *iter = zmalloc(sizeof(*iter));
iter->d = d;
iter->table = 0;
iter->index = -1;
iter->safe = 0;
iter->entry = NULL;
iter->nextEntry = NULL;
return iter;
}
小總結一下,初始化安全迭代器的過程有兩步:
-
初始化迭代器的內存和參數。
-
設置迭代器標記爲安全。
3.非安全迭代器的創建
非安全迭代器其實就是少了設置safe=1的那一步。
dictIterator *dictGetIterator(dict *d)
{
dictIterator *iter = zmalloc(sizeof(*iter));
iter->d = d;
iter->table = 0;
iter->index = -1;
iter->safe = 0;
iter->entry = NULL;
iter->nextEntry = NULL;
return iter;
}
4.迭代器的使用
看下迭代器被使用的地方dictNext函數:
dictEntry *dictNext(dictIterator *iter)
{
while (1) {
//當entry=null當時候,會進入這個分支
if (iter->entry == NULL) {
dictht *ht = &iter->d->ht[iter->table];
//只有首次遍歷,纔會出現index=-1並且table等於0這種情況,這個時候會去更新iterators
if (iter->index == -1 && iter->table == 0) {
if (iter->safe)
//還記得我們的dict結構體中定義的變量嗎?當安全迭代器首次進行遍歷的時候
//就會增加該變量的值
iter->d->iterators++;
else
//非安全迭代器
iter->fingerprint = dictFingerprint(iter->d);
}
iter->index++;
if (iter->index >= (signed) ht->size) {
//遍歷結束前判斷是否在rehash,如果是,更新index=0,table=1。
if (dictIsRehashing(iter->d) && iter->table == 0) {
iter->table++;
iter->index = 0;
ht = &iter->d->ht[1];
} else {
break;
}
}
//綜上所述,觸發這個賦值的情況有2種:
//1.首次遍歷hashtable[0]
//2.字典在進行rehash,首次遍歷hashtable[1]
iter->entry = ht->table[iter->index];
} else {
iter->entry = iter->nextEntry;
}
if (iter->entry) {
//記錄這次遍歷的下一個節點
iter->nextEntry = iter->entry->next;
return iter->entry;
}
}
return NULL;
}
-
該函數其實就是使用迭代器獲取一個字典中的元素。
-
如果當前傳入的是安全迭代器,在進行第一次遍歷的時候,iterators會做一個增加。
-
如果當前是非安全迭代器,會計算一個fingerprint(不展開了,簡單理解就是如果使用非安全迭代器的過程中,有數據被修改了那麼指紋就會發生變化,當釋放迭代器的時候會做指紋檢測)。
-
如果當前在進行rehash,那麼table[1]也會被遍歷。
-
在函數返回前, iter->nextEntry = iter->entry->next記錄了這次遍歷過程中的下一條數據。並且下一次遍歷會使用 iter->nextEntry。
iterators++的作用?
還記得分步rehash的函數判斷嗎?
static void _dictRehashStep(dict *d) {
if (d->iterators == 0) dictRehash(d,1);
}
也就是說,當有安全迭代器存在的時候,單步rehash的操作會被禁止。
爲什麼要記錄下一次要遍歷的節點?
首先安全迭代器的定義是遍歷的過程中可以做讀寫操作。如果迭代器返回的當前節點設置了過期時間,那麼就可能因爲過期導致該節點被清理掉,也就是從鏈表中移除。那麼下一次迭代就會終止進而導致數據遍歷的缺失。
5.迭代器的釋放
迭代器的釋放函數是dictReleaseIterator:
void dictReleaseIterator(dictIterator *iter)
{
if (!(iter->index == -1 && iter->table == 0)) {
// 釋放安全迭代器對漸進式rehash的阻止
if (iter->safe)
iter->d->iterators--;
// 如果當前是非安全迭代器,需要看一下指紋是否有變化,如果有變化會觸發一個警告:
/**
=== REDIS BUG REPORT START: Cut & paste starting from here ===
[23085] 20 Jan 22:45:08.802 * DB saved on disk
[23086] 20 Jan 22:45:08.804 # === ASSERTION FAILED ===
[23086] 20 Jan 22:45:08.808 # ==> dict.c:1029 'iter->fingerprint == dictFingerprint(iter->d)' is not true
*/
else
assert(iter->fingerprint == dictFingerprint(iter->d));
}
zfree(iter);
}
5.總結
最後我們做一個總結:首先我們從keys命令出發對redis的字典結構和漸進式rehash做了一個分析。
漸進rehash的觸發有2種情況:一個是redis讀寫的時候做一次rehash,一個是定時事件定時協助rehash(前提是配置開啓並且沒有進行rdb和aof)。
然後我們又從keys命令的處理函數出發,對redis的兩種迭代器做了一次分析:
安全迭代器:安全迭代器會讓漸進式rehash停止,並且還允許在迭代的過程中對數據做增刪,能夠保證不會遍歷到重複的數據。
除了keys使用了安全迭代器外,像rdb持久化和BGREWRITEAOF都使用的安全迭代器去遍歷的數據,來防止重複的數據和過期數據的寫入。
我理解安全迭代器其實是給後臺進程做各種數據的持久化用的。我上面說安全迭代器存在的時候,**單步rehash的操作會被禁止。**但是我們還有定時事件也在做rehash呀?那裏並沒有判斷 if (d->iterators == 0) 。
但是它做了這個判斷:if (server.rdb_child_pid == -1 && server.aof_child_pid == -1),在沒有 BGSAVE 或者 BGREWRITEAOF 執行時,纔對哈希表進行 rehash。
非安全迭代器:非安全迭代器只允許做遍歷操作,可能遍歷到重複數據(因爲沒有對rehash做限制,此時如果發生rehash操作,那麼就可能將遍歷過的數據遷移到未遍歷過的位置上)。並且非安全迭代器還有一個fingerprint,每次釋放迭代器前都會看一下指紋是否被修改過。
我個人理解,非安全迭代器其實是給redis的主進程用的。因爲有fingerprint的存在,如果說後臺進程使用了非安全迭代器,在後臺進程使用的過程中,主進程做了大批量的數據修改,那麼在釋放的迭代器的時候,對fingerprint做的校驗就會不通過。
全文完
參考資料:
redis官方文檔:https://redis.io/
redis源碼:https://github.com/redis/redis
書籍:《Redis設計與實現》
最後,本人能力有限,可能有分析不到位或者錯誤的地方,在此先說一聲抱歉。
如果有錯誤的地方,請批評指正,謝謝!