欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

一篇文章帶你弄清楚Redis的精髓

 更新時間:2023年02月08日 08:23:04   作者:京東云官方  
Redis是一個開源的、支持網(wǎng)絡(luò)、基于內(nèi)存的鍵值對存儲系統(tǒng),它可以用作數(shù)據(jù)庫、緩存和消息中間件。它支持多種數(shù)據(jù)類型,包括字符串、散列、列表、集合、位圖等,擁有極快的讀寫速度,并且支持豐富的特性,如事務(wù)、持久化、復(fù)制、腳本、發(fā)布/訂閱等。

一、Redis的特性

1.1 Redis為什么快?

  • 基于內(nèi)存操作,操作不需要跟磁盤交互,單次執(zhí)行很快
  • 命令執(zhí)行是單線程,因?yàn)槭腔趦?nèi)存操作,單次執(zhí)行的時間快于線程切換時間,同時通信采用多路復(fù)用
  • Redis本身就是一個k-v結(jié)構(gòu),類似于hashMap,所以查詢性能接近于O(1)
  • 同時redis自己底層數(shù)據(jù)結(jié)構(gòu)支持,比如跳表、SDS
  • lO多路復(fù)用,單個線程中通過記錄跟蹤每一個sock(I/O流)的狀態(tài)來管理多個I/O流

1.2 Redis其他特性

  • 更豐富的數(shù)據(jù)類型,雖然都是k、v結(jié)構(gòu),value可以存儲很多的數(shù)據(jù)類型
  • 完善的內(nèi)存管理機(jī)制、保證數(shù)據(jù)一致性:持久化機(jī)制、過期策略
  • 支持多種編程語言
  • 高可用,集群、保證高可用

1.3 Redis高可用

  • 很完善的內(nèi)存管理機(jī)制,過期、淘汰、持久化
  • 集群模式,主從、哨兵、cluster集群

二、Redis數(shù)據(jù)類型以及使用場景

Redis的數(shù)據(jù)類型有String、Hash、Set、List、Zset、bitMap(基于String類型)、 Hyperloglog(基于String類型)、Geo(地理位置)、Streams流。

2.1 String

2.1.1 基本指令

// 批量設(shè)置
> mset key1 value1 key2 value2
// 批量獲取
> mget key1 key2
// 獲取長度
> strlen key  
//  字符串追加內(nèi)容
> append key xxx
// 獲取指定區(qū)間的字符
> getrange key 0 5
// 整數(shù)值遞增 (遞增指定的值)
> incr intkey (incrby intkey 10)
// 當(dāng)key 存在時將覆蓋
> SETEX key seconds value
// 將 key 的值設(shè)為 value ,當(dāng)且僅當(dāng) key 不存在。
> SETNX key value

2.1.2 應(yīng)用場景

  1. 緩存相關(guān)場景 緩存、 token(跟過期屬性完美契合)
  2. 線程安全的計數(shù)場景 (軟限流、分布式ID等)

2.2 Hash

2.2.1 基本指令

// 將哈希表 key 中的域 field 的值設(shè)為 value 。
> HSET key field value
// 返回哈希表 key 中給定域 field 的值。
>  HGET key field
// 返回哈希表 key 中的所有域。
> HKEYS key
// 返回哈希表 key 中所有域的值。
>  HVALS key
// 為哈希表 key 中的域 field 的值加上增量 increment 。
> HINCRBY key field increment
// 查看哈希表 key 中,給定域 field 是否存在。
> HEXISTS key field

2.2.2 應(yīng)用場景

  1. 存儲對象類的數(shù)據(jù)(官網(wǎng)說的)比如一個對象下有多個字段
  2. 統(tǒng)計類的數(shù)據(jù),可以對單個統(tǒng)計數(shù)據(jù)進(jìn)行單獨(dú)操作

2.3 List

存儲有序的字符串列表,元素可以重復(fù)。列表的最大長度為 2^32 - 1 個元素(4294967295,每個列表超過 40 億個元素)。

2.3.1 基本指令

// 將一個或多個值 value 插入到列表 key 的表頭
> LPUSH key value [value ...]
// 將一個或多個值 value 插入到列表 key 的表尾(最右邊)。
> RPUSH key value [value ...]
// 移除并返回列表 key 的頭元素。
> LPOP key
// 移除并返回列表 key 的尾元素。
> RPOP key
// BLPOP 是列表的阻塞式(blocking)彈出原語。
> BLPOP key [key ...] timeout
// BRPOP 是列表的阻塞式(blocking)彈出原語。
> BRPOP key [key ...] timeout
// 獲取指點(diǎn)位置元素
> LINDEX key index

2.3.2 應(yīng)用場景

  1. 用戶消息時間線

因?yàn)閘ist是有序的,所以我們可以先進(jìn)先出,先進(jìn)后出的列表都可以做

2.4 Set

2.4.1 基本指令

// 將一個或多個 member 元素加入到集合 key 當(dāng)中,已經(jīng)存在于集合的 member 元素將被忽略。
> SADD key member [member ...]
// 返回集合 key 中的所有成員。
> SMEMBERS key
// 返回集合 key 的基數(shù)(集合中元素的數(shù)量)。
> SCARD key
// 如果命令執(zhí)行時,只提供了 key 參數(shù),那么返回集合中的一個隨機(jī)元素。
> SRANDMEMBER key [count]
// 移除并返回集合中的一個隨機(jī)元素。
> SPOP key
// 移除集合 key 中的一個或多個 member 元素,不存在的 member 元素會被忽略。
> SREM key member [member ...]
// 判斷 member 元素是否集合 key 的成員。
> SISMEMBER key member
// 獲取前一個集合有而后面1個集合沒有的
> sdiff huihuiset huihuiset1
// 獲取交集
> sinter huihuiset huihuiset1
// 獲取并集
> sunion huihuiset huihuiset1

2.4.2 應(yīng)用場景

  1. 抽獎 spop跟srandmember隨機(jī)彈出或者獲取元素
  2. 點(diǎn)贊、簽到等,sadd集合存儲
  3. 交集并集 關(guān)注等場景

2.5 ZSet(SortedSet)

sorted set,有序的set,每個元素有個score。

score相同時,按照key的ASCII碼排序。

2.5.1 基本指令

//將一個或多個 member 元素及其 score 值加入到有序集 key 當(dāng)中。
> ZADD key score member [[score member] [score member] ...]
// 返回有序集 key 中,指定區(qū)間內(nèi)的成員。其中成員的位置按 score 值遞增(從小到大)來排序
> ZRANGE key start stop [WITHSCORES]
// 返回有序集 key 中,指定區(qū)間內(nèi)的成員。其中成員的位置按 score 值遞減(從大到小)來排列。
> ZREVRANGE key start stop [WITHSCORES]
// 返回有序集 key 中,所有 score 值介于 min 和 max 之間(包括等于 min 或 max )的成員。有序集成員按 score 值遞增(從小到大)次序排列。
>  ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]
// 移除有序集 key 中的一個或多個成員,不存在的成員將被忽略。
> ZREM key member [member ...]
// 返回有序集 key 的基數(shù)。
> ZCARD key
// 為有序集 key 的成員 member 的 score 值加上增量 increment 。
> ZINCRBY key increment member
// 返回有序集 key 中, score 值在 min 和 max 之間(默認(rèn)包括 score 值等于 min 或 max )的成員的數(shù)量。
> ZCOUNT key min max
// 返回有序集 key 中成員 member 的排名。其中有序集成員按 score 值遞增(從小到大)順序排列。
> ZRANK key member

2.5.2 應(yīng)用場景

  1. 排行榜

三、Redis的事務(wù)

3.1 事務(wù)基本操作

// 1. multi命令開啟事務(wù),exec命令提交事務(wù)
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
// 2. 組隊(duì)的過程中可以通過discard來放棄組隊(duì)。
 127.0.0.1:6379> multi
OK
 127.0.0.1:6379(TX)> set k3 v3
QUEUED
 127.0.0.1:6379(TX)> set k4 v4
QUEUED
 127.0.0.1:6379(TX)> discard
OK

3.2 Redis事務(wù)特性

  1. 單獨(dú)的隔離操作

事務(wù)中的所有命令都會序列化、按順序地執(zhí)行。

事務(wù)在執(zhí)行過程中,不會被其他客戶端發(fā)送來的命令請求所打斷。

  1. 沒有隔離級別的概念

隊(duì)列中的命令沒有提交之前,都不會被實(shí)際地執(zhí)行,因?yàn)槭聞?wù)提交之前任何指令都不會被實(shí)際執(zhí)行,也就不存在“事務(wù)內(nèi)的查詢要看到事務(wù)里的更新,在事務(wù)外查詢不能看到”這個讓人萬分頭疼的問題。

  1. 不保證原子性

Redis同一個事務(wù)中如果有一條命令執(zhí)行失敗,其后的命令仍然會被執(zhí)行,沒有回滾。

四、Redis 分布式鎖

4.1 Lua 實(shí)現(xiàn)分布式鎖

local lockSet = redis.call('exists', KEYS[1])
if lockSet == 0 
  then
    redis.call('set', KEYS[1], ARG[1])
    redis.call('expire', KEYS[1], ARG[2])
  end
return lockSet

5.1 Redis dict字典

5.1.1 RedisDb數(shù)據(jù)接口(server.h文件)

數(shù)據(jù)最外層的結(jié)構(gòu)為RedisDb

typedef struct redisDb {
    dict *dict; /* The keyspace for this DB */ //數(shù)據(jù)庫的鍵
    dict *expires; /* Timeout of keys with a timeout set */ //設(shè)置了超時時間的鍵
    dict *blocking_keys; /* Keys with clients waiting for data (BLPOP)*/ //客戶端等待的keys
    dict *ready_keys; /* Blocked keys that received a PUSH */
    dict *watched_keys; /* WATCHED keys for MULTI/EXEC CAS */
    int id; /* Database ID */ //所在數(shù) 據(jù)庫ID
    long long avg_ttl; /* Average TTL, just for tats */ //平均TTL,僅用于統(tǒng)計
    unsigned long expires_cursor; /* Cursor of the active expire cycle. */
    list *defrag_later; /* List of key names to attempt to defrag one by one, gradually. */
} redisDb;

5.1.2 dict數(shù)據(jù)結(jié)構(gòu)(dict.h文件)

我們發(fā)現(xiàn)數(shù)據(jù)存儲在dict中

typedef struct dict {
    dictType *type; //理解為面向?qū)ο笏枷耄瑸橹С植煌臄?shù)據(jù)類型對應(yīng)dictType抽象方法,不同的數(shù)據(jù)類型可以不同實(shí)現(xiàn)
    void *privdata; //也可不同的數(shù)據(jù)類型相關(guān),不同類型特定函數(shù)的可選參數(shù)。
    dictht ht[2]; //2個hash表,用來數(shù)據(jù)存儲 2個dictht
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */ // rehash標(biāo)記 -1代表不再rehash
    unsigned long iterators; /* number of iterators currently running */
} dict;

5.1.3 dictht結(jié)構(gòu)(dict.h文件)

typedef struct dictht {
    dictEntry **table; //dictEntry 數(shù)組
    unsigned long size; //數(shù)組大小 默認(rèn)為4 #define DICT_HT_INITIAL_SIZE 4
    unsigned long sizemask; //size-1 用來取模得到數(shù)據(jù)的下標(biāo)值
    unsigned long used; //改hash表中已有的節(jié)點(diǎn)數(shù)據(jù)
} dictht;

5.1.4 dictEntry節(jié)點(diǎn)結(jié)構(gòu)(dict.h文件)

typedef struct dictEntry {
    void *key; //key
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v; //value
    struct dictEntry *next; //指向下一個節(jié)點(diǎn)
} dictEntry;

/* 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. */
#define OBJ_ENCODING_RAW 0 /* Raw representation */
#define OBJ_ENCODING_INT 1 /* Encoded as integer */
#define OBJ_ENCODING_HT 2 /* Encoded as hash table */
#define OBJ_ENCODING_ZIPMAP 3 /* Encoded as zipmap */
#define OBJ_ENCODING_LINKEDLIST 4 /* No longer used: old
list encoding. */
#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 */
#define OBJ_ENCODING_QUICKLIST 9 /* Encoded as linked list
of ziplists */
#define OBJ_ENCODING_STREAM 10 /* Encoded as a radix tree
of listpacks */
#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 */
#define OBJ_SHARED_REFCOUNT INT_MAX /* Global object
never destroyed. */
#define OBJ_STATIC_REFCOUNT (INT_MAX-1) /* Object
allocated in the stack. */
#define OBJ_FIRST_SPECIAL_REFCOUNT OBJ_STATIC_REFCOUNT
typedef struct redisObject {
unsigned type:4; //數(shù)據(jù)類型 string hash list
unsigned encoding:4; //底層的數(shù)據(jù)結(jié)構(gòu) 跳表
unsigned lru:LRU_BITS; /* LRU time (relative to global
lru_clock) or
* LFU data (least significant
8 bits frequency
* and most significant 16 bits
access time). */
int refcount; //用于回收,引用計數(shù)法
void *ptr; //指向具體的數(shù)據(jù)結(jié)構(gòu)的內(nèi)存地址 比如 跳表、壓縮列表
} robj;

5.2 Redis數(shù)據(jù)結(jié)構(gòu)圖

一文搞懂Redis_Redis

5.3 Redis擴(kuò)容機(jī)制

因?yàn)槲覀兊膁ictEntry數(shù)組默認(rèn)大小是4,如果不進(jìn)行擴(kuò)容,那么我們所有的數(shù)據(jù)都會以鏈表的形式添加至數(shù)組下標(biāo) 隨著數(shù)據(jù)量越來越大,之前只需要hash取模就能得到下標(biāo)位置,現(xiàn)在得去循環(huán)我下標(biāo)的鏈表,所以性能會越來越慢,當(dāng)我們的數(shù)據(jù)量達(dá)到一定程度后,我們就得去觸發(fā)擴(kuò)容操作。

5.3.1 什么時候擴(kuò)容

5.3.1.1 擴(kuò)容機(jī)制
  1. 當(dāng)沒有fork子進(jìn)程在進(jìn)行RDB或AOF持久化時,ht[0]的used大于size時,觸發(fā)擴(kuò)容
  2. 如果有子進(jìn)程在進(jìn)行RDB或者AOF時,ht[0]的used大于等于size的5倍的時候,會觸發(fā)擴(kuò)容
5.3.1.2 源碼驗(yàn)證

擴(kuò)容,肯定是在添加數(shù)據(jù)的時候才會擴(kuò)容,所以我們找一個添加數(shù)據(jù)的入口。

  1. 入口,添加或替換dictReplace (dict.c文件)
int dictReplace(dict *d, void *key, void *val) {
    dictEntry *entry, *existing, auxentry;
    /* Try to add the element. If the key
    * does not exists dictAdd will succeed. */
    entry = dictAddRaw(d,key,&existing);
    if (entry) {
        dictSetVal(d, entry, val);
        return 1;
    }
    /* Set the new value and free the old one. Note that
    it is important
    * to do that in this order, as the value may just be
    exactly the same
    * as the previous one. In this context, think to
    reference counting,
    * you want to increment (set), and then decrement
    (free), and not the
    * reverse. */
    auxentry = *existing;
    dictSetVal(d, existing, val);
    dictFreeVal(d, &auxentry);
    return 0;
}
  1. 進(jìn)入dictAddRaw方法 (dict.c文件)
dictEntry *dictAddRaw(dict *d, void *key, dictEntry **existing){
    long index;
    dictEntry *entry;
    dictht *ht;
    
    if (dictIsRehashing(d)) _dictRehashStep(d); //如果正在Rehash 進(jìn)行漸進(jìn)式hash 按步rehash
    
    /* Get the index of the new element, or -1 if
    * the element already exists. */
    if ((index = _dictKeyIndex(d, key, dictHashKey(d,key),existing)) == -1)
        return NULL;
    
    /* Allocate the memory and store the new entry.
    * Insert the element in top, with the assumption that
    in a database
    * system it is more likely that recently added
    entries are accessed
    * more frequently. */
    //如果在hash 放在ht[1] 否則放在ht[0]
    ht = dictIsRehashing(d) ? &d->ht[1] : &d->ht[0];
    entry = zmalloc(sizeof(*entry));
    //采用頭插法插入hash桶
    entry->next = ht->table[index];
    ht->table[index] = entry;
    //已使用++
    ht->used++;
    
    /* Set the hash entry fields. */
    dictSetKey(d, entry, key);
    return entry;
}
static long _dictKeyIndex(dict *d, const void *key,uint64_t hash, dictEntry **existing){
    unsigned long idx, table;
    dictEntry *he;
    if (existing) *existing = NULL;
    
    /* Expand the hash table if needed */
    //擴(kuò)容如果需要
    if (_dictExpandIfNeeded(d) == DICT_ERR)
        return -1;
    //比較是否存在這個值
    for (table = 0; table <= 1; table++) {
        idx = hash & d->ht[table].sizemask;
        /* Search if this slot does not already contain
        the given key */
        he = d->ht[table].table[idx];
        while(he) {
            if (key==he->key || dictCompareKeys(d, key,he->key)) {
                if (existing) *existing = he;
                    return -1;
                }
            he = he->next;
        }
        if (!dictIsRehashing(d)) break;
    }
    return idx;
}
/* Expand the hash table if needed */
static int _dictExpandIfNeeded(dict *d){
    /* Incremental rehashing already in progress. Return.*/
    if (dictIsRehashing(d)) return DICT_OK; //正在rehash,返回
    
    /* If the hash table is empty expand it to the initialsize. */
    //如果ht[0]的長度為0,設(shè)置默認(rèn)長度4 dictExpand為擴(kuò)容的關(guān)鍵方法
    if (d->ht[0].size == 0) 
            return dictExpand(d,DICT_HT_INITIAL_SIZE);

    //擴(kuò)容條件 hash表中已使用的數(shù)量大于等于 hash表的大小
    //并且dict_can_resize為1 或者 已使用的大小大于hash表大小的 5倍,大于等于1倍的時候,下面2個滿足一個條件即可
    if (d->ht[0].used >= d->ht[0].size &&
        (dict_can_resize || d->ht[0].used/d->ht[0].size >dict_force_resize_ratio)){
        //擴(kuò)容成原來的2倍
        return dictExpand(d, d->ht[0].used*2);
    }
    return DICT_OK;
}
5.3.2.1 擴(kuò)容步驟
  1. 當(dāng)滿足我擴(kuò)容條件,觸發(fā)擴(kuò)容時,判斷是否在擴(kuò)容,如果在擴(kuò)容,或者 擴(kuò)容的大小跟我現(xiàn)在的ht[0].size一樣,這次擴(kuò)容不做
  2. new一個新的dictht,大小為ht[0].used * 2(但是必須向上2的冪,比 如6 ,那么大小為8) ,并且ht[1]=新創(chuàng)建的dictht
  3. 我們有個更大的table了,但是需要把數(shù)據(jù)遷移到ht[1].table ,所以將 dict的rehashidx(數(shù)據(jù)遷移的偏移量)賦值為0 ,代表可以進(jìn)行數(shù)據(jù)遷 移了,也就是可以rehash了
  4. 等待數(shù)據(jù)遷移完成,數(shù)據(jù)不會馬上遷移,而是采用漸進(jìn)式rehash,慢慢的把數(shù)據(jù)遷移到ht[1]
  5. 當(dāng)數(shù)據(jù)遷移完成,ht[0].table=ht[1] ,ht[1] .table = NULL、ht[1] .size = 0、ht[1] .sizemask = 0、 ht[1] .used = 0
  6. 把dict的rehashidex=-1
5.3.2.2 源碼驗(yàn)證
  1. dictExpand方法在_dictExpandIfNeeded 方法中調(diào)用 (dict.c文件),為擴(kuò)容的關(guān)鍵方法
int dictExpand(dict *d, unsigned long size){
    /* the size is invalid if it is smaller than the
    number of
    * elements already inside the hash table */
    //正在擴(kuò)容,不允許第二次擴(kuò)容,或者h(yuǎn)t[0]的數(shù)據(jù)量大于擴(kuò)容后的數(shù)量,沒有意義,這次不擴(kuò)容
    if (dictIsRehashing(d) || d->ht[0].used > size)
        return DICT_ERR;
    
    dictht n; /* the new hash table */
    //得到最接近2的冪 跟hashMap思想一樣
    unsigned long realsize = _dictNextPower(size);
    
    /* Rehashing to the same table size is not useful. */
    //如果跟ht[0]的大小一致 直接返回錯誤
    if (realsize == d->ht[0].size) return DICT_ERR;
    
    /* Allocate the new hash table and initialize all
    pointers to NULL */
    //為新的dictht賦值
    n.size = realsize;
    n.sizemask = realsize-1;
    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. */
    //ht[0].table為空,代表是初始化
    if (d->ht[0].table == NULL) {
        d->ht[0] = n;
        return DICT_OK;
    }
    
    /* Prepare a second hash table for incremental rehashing */
    //將擴(kuò)容后的dictht賦值給ht[1]
    d->ht[1] = n;
    //標(biāo)記為0,代表可以開始rehash
    d->rehashidx = 0;
    return DICT_OK;
}
5.3.3.1 遷移方式

假如一次性把數(shù)據(jù)全部遷移會很耗時間,會讓單條指令等待很久,會形成阻塞。

所以,redis采用漸進(jìn)式Rehash,所謂漸進(jìn)式,就是慢慢的,不會一次性把所有數(shù)據(jù)遷移。

那什么時候會進(jìn)行漸進(jìn)式數(shù)據(jù)遷移?

  1. 每次進(jìn)行key的crud操作都會進(jìn)行一個hash桶的數(shù)據(jù)遷移
  2. 定時任務(wù),進(jìn)行部分?jǐn)?shù)據(jù)遷移
5.3.3.2 源碼驗(yàn)證
CRUD觸發(fā)都會觸發(fā)_dictRehashStep(漸進(jìn)式hash)
  1. 每次增刪改的時候都會調(diào)用_dictRehashStep方法
if (dictIsRehashing(d)) _dictRehashStep(d); //這個代碼在增刪改查的方法中都會調(diào)用
  1. _dictRehashStep方法
static void _dictRehashStep(dict *d) {
  if (d->iterators == 0) dictRehash(d,1);
}
int dictRehash(dict *d, int n) {
    int empty_visits = n*10; /* Max number of empty
    buckets to visit. */ //要訪問的最大的空桶數(shù) 防止此次耗時過長
    
    if (!dictIsRehashing(d)) return 0; //如果沒有在rehash返回0
    
    //循環(huán),最多1次,并且ht[0]的數(shù)據(jù)沒有遷移完 進(jìn)入循環(huán)
    while(n-- && d->ht[0].used != 0) {
        dictEntry *de, *nextde;
        /* Note that rehashidx can't overflow as we are
        sure there are more
        * elements because ht[0].used != 0 */
        assert(d->ht[0].size > (unsigned long)d->rehashidx);
        //rehashidx rehash的索引,默認(rèn)0 如果hash桶為空 進(jìn)入自旋 并且判斷是否到了最大的訪問空桶數(shù)
        while(d->ht[0].table[d->rehashidx] == NULL) {
            d->rehashidx++;
            if (--empty_visits == 0) return 1;
        }
        de = d->ht[0].table[d->rehashidx]; //得到ht[0]的下標(biāo)為rehashidx桶
        /* Move all the keys in this bucket from the old
        to the new hash HT */
        while(de) { //循環(huán)hash桶的鏈表 并且轉(zhuǎn)移到ht[1]
            uint64_t h;
            nextde = de->next;
            /* Get the index in the new hash table */
            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;
        }
        //轉(zhuǎn)移完后 將ht[0]相對的hash桶設(shè)置為null
        d->ht[0].table[d->rehashidx] = NULL;
        d->rehashidx++;
    }
    /* Check if we already rehashed the whole table... */
    //ht[0].used=0 代表rehash全部完成
    if (d->ht[0].used == 0) {
        //清空ht[0]table
        zfree(d->ht[0].table);
        //將ht[0] 重新指向已經(jīng)完成rehash的ht[1]
        d->ht[0] = d->ht[1];
        //將ht[1]所有數(shù)據(jù)重新設(shè)置
        _dictReset(&d->ht[1]);
        //設(shè)置-1,代表rehash完成
        d->rehashidx = -1;
        return 0;
    }
    /* More to rehash... */
    return 1;
}

//將ht[1]的屬性復(fù)位
static void _dictReset(dictht *ht)
{
    ht->table = NULL;
    ht->size = 0;
    ht->sizemask = 0;
    ht->used = 0;
}

再講定時任務(wù)之前,我們要知道Redis中有個時間事件驅(qū)動,在 server.c文件下有個serverCron 方法。

serverCron 每隔多久會執(zhí)行一次,執(zhí)行頻率根據(jù)redis.conf中的hz配置,serverCorn中有個方法databasesCron()

  1. 定時方法serverCron
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
    //.......
    /* We need to do a few operations on clients
    asynchronously. */
    clientsCron();
    /* Handle background operations on Redis databases. */
    databasesCron(); //處理Redis數(shù)據(jù)庫上的后臺操作。
    //.......
}
  1. databasesCron方法
void databasesCron(void) {
    /* Expire keys by random sampling. Not required for
    slaves
    * as master will synthesize DELs for us. */
    if (server.active_expire_enabled) {
        if (iAmMaster()) {
            activeExpireCycle(ACTIVE_EXPIRE_CYCLE_SLOW);
        } else {
            expireSlaveKeys();
        }
    }
    /* Defrag keys gradually. */
    activeDefragCycle();
    /* Perform hash tables rehashing if needed, but only
    if there are no
    * other processes saving the DB on disk. Otherwise
    rehashing is bad
    * as will cause a lot of copy-on-write of memory
    pages. */
    if (!hasActiveChildProcess()) {
        /* We use global counters so if we stop the
        computation at a given
        * DB we'll be able to start from the successive
        in the next
        * cron loop iteration. */
        static unsigned int resize_db = 0;
        static unsigned int rehash_db = 0;
        int dbs_per_call = CRON_DBS_PER_CALL;
        int j;
        /* Don't test more DBs than we have. */
        if (dbs_per_call > server.dbnum) 
            dbs_per_call = server.dbnum;
        /* Resize */
        for (j = 0; j < dbs_per_call; j++) {
            tryResizeHashTables(resize_db % server.dbnum);
            resize_db++;
        }
        /* Rehash */ //Rehash邏輯
        if (server.activerehashing) {
            for (j = 0; j < dbs_per_call; j++) {
                //進(jìn)入incrementallyRehash
                int work_done = incrementallyRehash(rehash_db);
                if (work_done) {
                    /* If the function did some work, stop
                        here, we'll do
                        * more at the next cron loop. */
                    break;
                } else {
                    /* If this db didn't need rehash,
                        we'll try the next one. */
                    rehash_db++;
                    rehash_db %= server.dbnum;
                }
            }
        }
    }
}

int incrementallyRehash(int dbid) {
    /* Keys dictionary */
    if (dictIsRehashing(server.db[dbid].dict)) {
        dictRehashMilliseconds(server.db[dbid].dict,1);
        return 1; 
        /* already used our millisecond for this
        loop... */
    }
    /* Expires */
    if (dictIsRehashing(server.db[dbid].expires)) {
        dictRehashMilliseconds(server.db[dbid].expires,1);
        return 1; /* already used our millisecond for this
        loop... */
    }
    return 0;
}
  1. 進(jìn)入dictRehashMilliseconds(dict.c)
int dictRehashMilliseconds(dict *d, int ms) {
    long long start = timeInMilliseconds();
    int rehashes = 0;
    //進(jìn)入rehash方法 dictRehash 去完成漸進(jìn)時HASH
    while(dictRehash(d,100)) {
        rehashes += 100;
        //判斷是否超時
        if (timeInMilliseconds()-start > ms) break;
    }
    return rehashes;
}

5.4 String類型數(shù)據(jù)結(jié)構(gòu)

Redis中String的底層沒有用c的char來實(shí)現(xiàn),而是采用了SDS(simple Dynamic String)的數(shù)據(jù)結(jié)構(gòu)來實(shí)現(xiàn)。并且提供了5種不同的類型

5.4.1 SDS數(shù)據(jù)結(jié)構(gòu)定義(sds.h文件)

typedef char *sds;
/* Note: sdshdr5 is never used, we just access the flags
    byte directly.
    * However is here to document the layout of type 5 SDS
strings. */
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of
        string length */
    char buf[];
}

struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len;  /* used */ //已使用的長度
    uint8_t alloc; /* excluding the header and null terminator */ //分配的總?cè)萘?不包含頭和空終止符
    unsigned char flags; /* 3 lsb of type, 5 unused bits */ //低三位類型 高5bit未使用
    char buf[]; //數(shù)據(jù)buf 存儲字符串?dāng)?shù)組
};

struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null
    terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits
    */
    char buf[];
};

struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null
    terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits
    */
    char buf[];
};

struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null
    terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits
    */
    char buf[];
};
  1. char字符串不記錄自身長度,所以獲取一個字符串長度的復(fù)雜度是O(n),但是SDS記錄分配的長度alloc,已使用的長度len,獲取長度為 O(1)
  2. 減少修改字符串帶來的內(nèi)存重分配次數(shù)
  3. 空間預(yù)分配,SDS長度如果小于1MB,預(yù)分配跟長度一樣的,大于1M,每次跟len的大小多1M
  4. 惰性空間釋放,截取的時候不馬上釋放空間,供下次使用!同時提供相應(yīng)的釋放SDS未使用空間的API
  5. 二進(jìn)制安全

5.5 Hash類型數(shù)據(jù)結(jié)構(gòu)

Redis的字典相當(dāng)于Java語言中的HashMap,他是無序字典。內(nèi)部結(jié)構(gòu)上同樣是數(shù)組 + 鏈表二維結(jié)構(gòu)。第一維hash的數(shù)組位置碰撞時,就會將碰撞的元素使用鏈表串起來。

5.5.1 Hash數(shù)據(jù)結(jié)構(gòu)圖

一文搞懂Redis_Redis_02

5.5.2 Hash的壓縮列表

壓縮列表會根據(jù)存入的數(shù)據(jù)的不同類型以及不同大小,分配不同大小的空間。所以是為了節(jié)省內(nèi)存而采用的。

因?yàn)槭且粔K完整的內(nèi)存空間,當(dāng)里面的元素發(fā)生變更時,會產(chǎn)生連鎖更新,嚴(yán)重影響我們的訪問性能。所以,只適用于數(shù)據(jù)量比較小的場景。

所以,Redis會有相關(guān)配置,Hashes只有小數(shù)據(jù)量的時候才會用到ziplist,當(dāng)hash對象同時滿足以下兩個條件的時候,使用ziplist編碼:

  1. 哈希對象保存的鍵值對數(shù)量<512個
  2. 所有的鍵值對的鍵和值的字符串長度都<64byte(一個英文字母一個字節(jié))
hash-max-ziplist-value 64 // ziplist中最大能存放的值長度
hash-max-ziplist-entries 512 // ziplist中最多能存放的entry節(jié)點(diǎn)數(shù)量

5.6 List類型數(shù)據(jù)結(jié)構(gòu)

5.6.1 quickList快速列表

兼顧了ziplist的節(jié)省內(nèi)存,并且一定程度上解決了連鎖更新的問題,我們的 quicklistNode節(jié)點(diǎn)里面是個ziplist,每個節(jié)點(diǎn)是分開的。那么就算發(fā)生了連鎖更新,也只會發(fā)生在一個quicklistNode節(jié)點(diǎn)。

quicklist.h文件

typedef struct{
    struct quicklistNode *prev; //前指針
    struct quicklistNode *next; //后指針
    unsigned char *zl; //數(shù)據(jù)指針 指向ziplist結(jié)果
    unsigned int sz; //ziplist大小 /* ziplist
    size in bytes */
    unsigned int count : 16; /* count of items in ziplist */ //ziplist的元素
    unsigned int encoding : 2; /* RAW==1 or LZF==2 */ //
    是否壓縮, 1沒有壓縮 2 lzf壓縮
    unsigned int container : 2; /* NONE==1 or ZIPLIST==2 */ //預(yù)留容器字段
    unsigned int recompress : 1; /* was this node previous compressed? */
    unsigned int attempted_compress : 1; /* node can't compress; too small */
    unsigned int extra : 10; /* more bits to steal for  future usage */ //預(yù)留字段
} quicklistNode;

5.6.2 list數(shù)據(jù)結(jié)構(gòu)圖

一文搞懂Redis_redis?。洌椋悖鬫03

5.7 Set類型數(shù)據(jù)結(jié)構(gòu)

Redis用intset或hashtable存儲set。滿足下面條件,就用inset存儲。

  1. 如果不是整數(shù)類型,就用dictht hash表(數(shù)組+鏈表)
  2. 如果元素個數(shù)超過512個,也會用hashtable存儲。跟一個配置有關(guān):
set-max-intset-entries 512

不滿足上述條件的,都使用hash表存儲,value存null。

5.8 ZSet數(shù)據(jù)結(jié)構(gòu)

5.8.1 ZipList

默認(rèn)使用ziplist編碼。

在ziplist的內(nèi)部,按照score排序遞增來存儲。插入的時候要移動之后的數(shù)據(jù)。

如果元素數(shù)量大于等于128個,或者任一member長度大于等于64字節(jié)使用 skiplist+dict存儲。

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

如果不滿足條件,采用跳表。

5.8.2 跳表(skiplist)

結(jié)構(gòu)定義(servier.h)

/* ZSETs use a specialized version of Skiplists */
typedef struct zskiplistNode {
 sds ele; //sds數(shù)據(jù)
 double score; //score
 struct zskiplistNode *backward; //后退指針
 //層級數(shù)組
 struct zskiplistLevel {
     struct zskiplistNode *forward; //前進(jìn)指針
     unsigned long span; //跨度
 } level[];
} zskiplistNode;

//跳表列表
typedef struct zskiplist {
 struct zskiplistNode *header, *tail; //頭尾節(jié)點(diǎn)
 unsigned long length; //節(jié)點(diǎn)數(shù)量
 int level; //最大的節(jié)點(diǎn)層級
} zskiplist;

zslInsert 添加節(jié)點(diǎn)方法 (t_zset.c)

zskiplistNode *zslInsert(zskiplist *zsl, double score, sds
ele) {
 zskiplistNode *update[ZSKIPLIST_MAXLEVEL], *x;
 unsigned int rank[ZSKIPLIST_MAXLEVEL];
 int i, level;
 serverAssert(!isnan(score));
 x = zsl->header;
 for (i = zsl->level-1; i >= 0; i--) {
     /* store rank that is crossed to reach the insert
     position */
     rank[i] = i == (zsl->level-1) ? 0 : rank[i+1];
     while (x->level[i].forward &&
         (x->level[i].forward->score < score ||
         咕泡出品 必屬精品精品屬精品 咕泡出品 必屬精品 咕泡出品 必屬精品 咕泡咕泡
         (x->level[i].forward->score == score
         &&
         sdscmp(x->level[i].forward->ele,ele) <
         0)))
         {
         rank[i] += x->level[i].span;
         x = x->level[i].forward;
     }
     update[i] = x;
 }
 /* we assume the element is not already inside, since
 we allow duplicated
    * scores, reinserting the same element should never
    happen since the
    * caller of zslInsert() should test in the hash table
    if the element is
    * already inside or not. */
    level = zslRandomLevel();
    if (level > zsl->level) {
        for (i = zsl->level; i < level; i++) {
            rank[i] = 0;
            update[i] = zsl->header;
            update[i]->level[i].span = zsl->length;
        }
        zsl->level = level;
    }
    x = zslCreateNode(level,score,ele);
    //不同層級建立鏈表聯(lián)系
    for (i = 0; i < level; i++) {
        x->level[i].forward = update[i]->level[i].forward;
        update[i]->level[i].forward = x;
        /* update span covered by update[i] as x is
        inserted here */
        x->level[i].span = update[i]->level[i].span -
        (rank[0] - rank[i]);
        update[i]->level[i].span = (rank[0] - rank[i]) +
        1;
    }
    /* increment span for untouched levels */
    for (i = level; i < zsl->level; i++) {
        update[i]->level[i].span++;
    }
    x->backward = (update[0] == zsl->header) ? NULL :
    update[0];
    if (x->level[0].forward)
        x->level[0].forward->backward = x;
    else
        zsl->tail = x;
        zsl->length++;
    return x;
}
#define ZSKIPLIST_MAXLEVEL 32 /* Should be enough for 2^64
elements */

六、Redis過期策略

6.1 惰性過期

所謂惰性過期,就是在每次訪問操作key的時候,判斷這個key是不是過期了,過期了就刪除。

6.1.1 源碼驗(yàn)證

  1. expireIfNeeded方法(db.c文件)
int expireIfNeeded(redisDb *db, robj *key) {
    if (!keyIsExpired(db,key)) return 0;
    /* If we are running in the context of a slave,
    instead of
    * evicting the expired key from the database, we
    return ASAP:
    * the slave key expiration is controlled by the
    master that will
    * send us synthesized DEL operations for expired
    keys.
    *
    * Still we try to return the right information to the
    caller,
    * that is, 0 if we think the key should be still
    valid, 1 if
    * we think the key is expired at this time. */
    // 如果配置有masterhost,說明是從節(jié)點(diǎn),那么不操作刪除
    if (server.masterhost != NULL) return 1;
    /* Delete the key */
    server.stat_expiredkeys++;
    propagateExpire(db,key,server.lazyfree_lazy_expire);
    notifyKeyspaceEvent(NOTIFY_EXPIRED,
    "expired",key,db->id);
    //是否是異步刪除 防止單個Key的數(shù)據(jù)量很大 阻塞主線程 是4.0之后添加的新功能,默認(rèn)關(guān)閉
    int retval = server.lazyfree_lazy_expire ? dbAsyncDelete(db,key) : dbSyncDelete(db,key);
    if (retval) signalModifiedKey(NULL,db,key);
    return retval;
}

該策略可以最大化的節(jié)省CPU資源。

但是卻對內(nèi)存非常不友好。因?yàn)槿绻麤]有再次訪問,就可能一直堆積再內(nèi)存中。占用內(nèi)存

所以就需要另一種策略來配合使用,就是定期過期

6.2 定期過期

那么多久去清除一次,我們在講Rehash的時候,有個方法是serverCron,執(zhí)行頻率根據(jù)redis.conf中的hz配置。

這方法除了做Rehash以外,還會做很多其他的事情,比如:

  1. 清理數(shù)據(jù)庫中的過期鍵值對
  2. 更新服務(wù)器的各類統(tǒng)計信息,比如時間、內(nèi)存占用、數(shù)據(jù)庫占用情況等
  3. 關(guān)閉和清理連接失效的客戶端
  4. 嘗試進(jìn)行持久化操作

6.2.1 實(shí)現(xiàn)流程

  1. 定時serverCron方法去執(zhí)行清理,執(zhí)行頻率根據(jù)redis.cong中的hz配置的值(默認(rèn)是10,也就是1s執(zhí)行10次,100ms執(zhí)行一次)
  2. 執(zhí)行清理的時候,不是去掃描所有的key,而是去掃描所有設(shè)置了過期時間的key redisDB.expires
  3. 如果每次去把所有的key都拿出來,那么假如過期的key很多,就會很慢,所以也不是一次性拿出所有的key
  4. 根據(jù)hash桶的維度去掃描key,掃到20(可配置)個key為止。假如第一個桶是15個key沒有滿足20,繼續(xù)掃描第二個桶,第二個桶20個key,由于是以hash桶的維度掃描的,所以第二個掃到了就會全掃,總共掃描35個key
  5. 找到掃描的key里面過期的key,并進(jìn)行刪除
  6. 如果取了400個空桶(最多拿400個桶),或者掃描的刪除比例跟掃描的總數(shù)超過10%,繼續(xù)執(zhí)行4、5步
  7. 也不能無限的循環(huán),循環(huán)16次后回去檢測時間,超過指定時間會跳出

6.2.2 源碼驗(yàn)證

  1. 入口serverCrom
// serverCron方法調(diào)用databasesCron方法(server.c)
/* Handle background operations on Redis databases. */
databasesCron();

void databasesCron(void) {
    /* Expire keys by random sampling. Not required for
    slaves
    * as master will synthesize DELs for us. */
    if (server.active_expire_enabled) {
        if (iAmMaster()) {
            activeExpireCycle(ACTIVE_EXPIRE_CYCLE_SLOW);
        //過期刪除方法
        } else {
            expireSlaveKeys();
        }
    }
}

由于Redis內(nèi)存是有大小的,并且我可能里面的數(shù)據(jù)都沒有過期,當(dāng)快滿的時候,我又沒有過期的數(shù)據(jù)進(jìn)行淘汰,那么這個時候內(nèi)存也會滿。內(nèi)存滿了,Redis也會不能放入新的數(shù)據(jù)。所以,我們不得已需要一些策略來解決這個問題來保證可用性。

7.1 淘汰策略

7.1.1 noeviction

New values aren’t saved when memory limit is reached. When a database uses replication, this applies to the primary database.

默認(rèn),不淘汰 能讀不能寫

7.1.2 allkeys-lru

Keeps most recently used keys; removes least recently used (LRU) keys

基于偽LRU算法,在所有的key中去淘汰

7.1.3 allkeys-lfu

Keeps frequently used keys; removes least frequently used (LFU) keys.

基于偽LFU算法,在所有的key中去淘汰

7.1.4 volatile-lru

Removes least recently used keys with the expire field set to true.

基于偽LRU算法,在設(shè)置了過期時間的key中去淘汰

7.1.5 volatile-lfu

Removes least frequently used keys with the expire field set to true.

基于偽LFU算法 在設(shè)置了過期時間的key中去淘汰

7.1.6 allkeys-random

Randomly removes keys to make space for the new data added.

基于隨機(jī)算法,在所有的key中去淘汰

7.1.7 volatile-random

Randomly removes keys with expire field set to true.

基于隨機(jī)算法 在設(shè)置了過期時間的key中去淘汰

7.1.8 volatile-ttl

Removes least frequently used keys with expire field set to true and the shortest remaining time-to-live (TTL) value.

根據(jù)過期時間來,淘汰即將過期的

7.2 淘汰流程

  1. 首先,我們會有個淘汰池,默認(rèn)大小是16,并且里面的數(shù)據(jù)是末尾淘汰制
  2. 每次指令操作的時候,自旋會判斷當(dāng)前內(nèi)存是否滿足指令所需要的內(nèi)存
  3. 如果當(dāng)前不滿足,會從淘汰池的尾部拿一個最適合淘汰的數(shù)據(jù)
  • 會取樣(配置 maxmemory-samples),從Redis中獲取隨機(jī)獲取到取樣的數(shù)據(jù),解決一次性讀取所有的數(shù)據(jù)慢的問題
  • 在取樣的數(shù)據(jù)中,根據(jù)淘汰算法找到最適合淘汰的數(shù)據(jù)
  • 將最合適的那個數(shù)據(jù)跟淘汰池中的數(shù)據(jù)進(jìn)行比較,是否比淘汰池的數(shù)據(jù)更適合淘汰,如果更適合,放入淘汰池
  • 按照適合的程度進(jìn)行排序,最適合淘汰的放入尾部
  1. 將需要淘汰的數(shù)據(jù)從Redis刪除,并且從淘汰池移除

7.3 LRU算法

Lru,Least Recently Used 翻譯過來是最久未使用,根據(jù)時間軸來走,仍很久沒用的數(shù)據(jù)。只要最近有用過,我就默認(rèn)是有效的。

那么它的一個衡量標(biāo)準(zhǔn)是啥?時間!根據(jù)使用時間,從近到遠(yuǎn),越遠(yuǎn)的越容易淘汰。

7.3.1 實(shí)現(xiàn)原理

需求:得到對象隔多久沒訪問,隔的時間越久,越容易被淘汰

  1. 首先,LRU是根據(jù)這個對象的訪問操作時間來進(jìn)行淘汰的,那么我們需要知道這個對象最后操作的訪問時間
  2. 知道了對象的最后操作訪問時間后,我們只需要跟當(dāng)前系統(tǒng)時間來進(jìn)行對比,就能算出對象多久沒訪問了

7.3.2 源碼驗(yàn)證

redis中,對象都會被redisObject對象包裝,其中有個字段叫l(wèi)ru。

redisObject對象 (server.h文件)

typedef struct redisObject {
 unsigned type:4;
 unsigned encoding:4;
 unsigned lru:LRU_BITS; /* LRU time (relative to global
 lru_clock) or
 * LFU data (least significant 8 bits frequency
 * and most significant 16 bits access time). */
 int refcount;
 void *ptr;
} robj;

看LRU的字段的說明,那么我們大概能猜出來,redis去實(shí)現(xiàn)lru淘汰算法肯定跟我們這個對象的lru相關(guān)

并且這個字段的大小為24bit,那么這個字段記錄的是對象操作訪問時候的秒單位時間的后24bit

相當(dāng)于:

long timeMillis=System.currentTimeMillis();
System.out.println(timeMillis/1000); //獲取當(dāng)前秒
System.out.println(timeMillis/1000 & ((1<<24)-1)); //獲取秒的后24位

我們知道了這個對象的最后操作訪問的時間。如果我們要得到這個對象多久沒訪問了,我們是不是就很簡單,用我當(dāng)前的時間-這個對象的訪問時間就可以了!但是這個訪問時間是秒單位時間的后24bit 所以,也是用當(dāng)前的時間的秒單位的后24bit去減。

estimateObjectIdleTime方法(evict.c)

unsigned long long estimateObjectIdleTime(robj *o) {
 //獲取秒單位時間的最后24位
 unsigned long long lruclock = LRU_CLOCK();
 //因?yàn)橹挥?4位,所有最大的值為2的24次方-1
 //超過最大值從0開始,所以需要判斷l(xiāng)ruclock(當(dāng)前系統(tǒng)時間)跟緩存對象的lru字段的大小
 if (lruclock >= o->lru) {
     //如果lruclock>=robj.lru,返回lruclock-o->lru,再轉(zhuǎn)換單位
     return (lruclock - o->lru) * LRU_CLOCK_RESOLUTION;
 } else {
     //否則采用lruclock + (LRU_CLOCK_MAX - o->lru),得到對
     象的值越小,返回的值越大,越大越容易被淘汰
     return (lruclock + (LRU_CLOCK_MAX - o->lru)) *
     LRU_CLOCK_RESOLUTION;
 }
}

7.3.3 LRU總結(jié)

用lruclock與 redisObject.lru進(jìn)行比較,因?yàn)閘ruclock只獲取了當(dāng)前秒單位時間的后24位,所以肯定有個輪詢。

所以,我們會用lruclock跟 redisObject.lru進(jìn)行比較,如果lruclock>redisObject.lru,那么我們用lruclock- redisObject.lru,否則lruclock+(24bit的最大值-redisObject.lru),得到lru越小,那么返回的數(shù)據(jù)越大,相差越大的越優(yōu)先會被淘汰!

<??https://www.processon.com/view/link/5fbe0541e401fd2d6ed8fc38??>

7.4 LFU算法

LFU,英文 Least Frequently Used,翻譯成中文就是最不常用的優(yōu)先淘汰。

不常用,它的衡量標(biāo)準(zhǔn)就是次數(shù),次數(shù)越少的越容易被淘汰。

這個實(shí)現(xiàn)起來應(yīng)該也很簡單,對象被操作訪問的時候,去記錄次數(shù),每次操作訪問一次,就+1;淘汰的時候,直接去比較這個次數(shù),次數(shù)越少的越容易淘汰!

7.4.1 LFU的時效性問題

何為時效性問題?就是只會去考慮數(shù)量,但是不會去考慮時間。

ps:去年的某個新聞很火,點(diǎn)擊量3000W,今年有個新聞剛出來點(diǎn)擊量100次,本來我們是想保留今年的新的新聞的,但是如果根據(jù)LFU來做的話,我們發(fā)現(xiàn)淘汰的是今年的新聞,明顯是不合理的

導(dǎo)致的問題:新的數(shù)據(jù)進(jìn)不去,舊的數(shù)據(jù)出不來。

那么如何解決呢,且往下看

7.4.2 源碼分析

我們還是來看redisObject(server.h)

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time (relative to global
    lru_clock) or
    * LFU data (least significant 8 bits frequency
    * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

我們看它的lru,它如果在LFU算法的時候!它前面16位代表的是時間,后8位代表的是一個數(shù)值,frequency是頻率,應(yīng)該就是代表這個對象的訪問次數(shù),我們先給它叫做counter。

前16bits時間有啥用?

跟時間相關(guān),我猜想應(yīng)該是跟解決時效性相關(guān)的,那么怎么解決的?從生活中找例子

大家應(yīng)該充過一些會員,比如我這個年紀(jì)的,小時候喜歡充騰訊的黃鉆、綠鉆、藍(lán)鉆等等。但是有一個點(diǎn),假如哪天我沒充錢了的話,或者沒有續(xù)VIP的時候,我這個鉆石等級會隨著時間的流失而降低。比如我本來是黃鉆V6,但是一年不充錢的話,可能就變成了V4。

那么回到Redis,大膽的去猜測,那么這個時間是不是去記錄這個對象有多久沒訪問了,如果多久沒訪問,我就去減少對應(yīng)的次數(shù)。

LFUDecrAndReturn方法(evict.c)

unsigned long LFUDecrAndReturn(robj *o) {
    //lru字段右移8位,得到前面16位的時間
    unsigned long ldt = o->lru >> 8;
    //lru字段與255進(jìn)行&運(yùn)算(255代表8位的最大值),
    //得到8位counter值
    unsigned long counter = o->lru & 255;
    //如果配置了lfu_decay_time,用LFUTimeElapsed(ldt) 除以配置的值
    //LFUTimeElapsed(ldt)源碼見下
    //總的沒訪問的分鐘時間/配置值,得到每分鐘沒訪問衰減多少
    unsigned long num_periods = server.lfu_decay_time ?LFUTimeElapsed(ldt) / server.lfu_decay_time : 0;
    if (num_periods)
    //不能減少為負(fù)數(shù),非負(fù)數(shù)用couter值減去衰減值
    counter = (num_periods > counter) ? 0 : counter - num_periods;
    return counter;
}

衰減因子由配置

lfu-decay-time 1 //多少分鐘沒操作訪問就去衰減一次

后8bits的次數(shù),最大值是255,夠不夠?

肯定不夠,一個對象的訪問操作次數(shù)肯定不止255次。

但是我們可以讓數(shù)據(jù)達(dá)到255的很難。那么怎么做的?這個比較簡單,我們先看源碼,然后再總結(jié)

LFULogIncr方法 (evict.c 文件)

uint8_t LFULogIncr(uint8_t counter) {
    //如果已經(jīng)到最大值255,返回255 ,8位的最大值
    if (counter == 255) return 255;
    //得到隨機(jī)數(shù)(0-1)
    double r = (double)rand()/RAND_MAX;
    //LFU_INIT_VAL表示基數(shù)值(在server.h配置)
    double baseval = counter - LFU_INIT_VAL;
    //如果達(dá)不到基數(shù)值,表示快不行了,baseval =0
    if (baseval < 0) baseval = 0;
    //如果快不行了,肯定給他加counter
    //不然,按照幾率是否加counter,同時跟baseval與lfu_log_factor相關(guān)
    //都是在分子,所以2個值越大,加counter幾率越小
    double p = 1.0/(baseval*server.lfu_log_factor+1);
    if (r < p) counter++;
    return counter;
}

八、Redis 持久化

8.1 RBD

8.1.1 何時觸發(fā)RBD

自動觸發(fā)

  1. 配置觸發(fā)
save 900 1 900s檢查一次,至少有1個key被修改就觸發(fā)
save 300 10 300s檢查一次,至少有10個key被修改就觸發(fā)
save 60 10000 60s檢查一次,至少有10000個key被修改
  1. shutdown正常關(guān)閉

任何組件在正常關(guān)閉的時候,都會去完成應(yīng)該完成的事。比如Mysql 中的Redolog持久化,正常關(guān)閉的時候也會去持久化。

  1. flushall指令觸發(fā)

數(shù)據(jù)清空指令會觸發(fā)RDB操作,并且是觸發(fā)一個空的RDB文件,所以, 如果在沒有開啟其他的持久化的時候,flushall是可以刪庫跑路的,在生產(chǎn)環(huán)境慎用。

8.1.2 RDB的優(yōu)劣

優(yōu)勢

  1. 是個非常緊湊型的文件,非常適合備份與災(zāi)難恢復(fù)
  2. 最大限度的提升了性能,會fork一個子進(jìn)程,父進(jìn)程永遠(yuǎn)不會產(chǎn)于磁盤 IO或者類似操作
  3. 更快的重啟

不足

  1. 數(shù)據(jù)安全性不是很高,因?yàn)槭歉鶕?jù)配置的時間來備份,假如每5分鐘備份 一次,也會有5分鐘數(shù)據(jù)的丟失
  2. 經(jīng)常fork子進(jìn)程,所以比較耗CPU,對CPU不是很友好

8.2 AOF

由于RDB的數(shù)據(jù)可靠性非常低,所以Redis又提供了另外一種持久化方案: Append Only File 簡稱:AOF

AOF默認(rèn)是關(guān)閉的,你可以在配置文件中進(jìn)行開啟:

appendonly no //默認(rèn)關(guān)閉,可以進(jìn)行開啟
# The name of the append only file (default:"appendonly.aof")
appendfilename "appendonly.aof" //AOF文件名

追加文件,即每次更改的命令都會附加到我的AOF文件中。

8.2.1 同步機(jī)制

AOF會記錄每個寫操作,那么問題來了。我難道每次操作命令都要和磁盤交互?

當(dāng)然不行,所以redis支持幾種策略,由用戶來決定要不要每次都和磁盤交互

# appendfsync always 表示每次寫入都執(zhí)行fsync(刷新)函數(shù) 性能會非常非常慢 但是非常安全
appendfsync everysec 每秒執(zhí)行一次fsync函數(shù) 可能丟失1s的數(shù)據(jù)
# appendfsync no 由操作系統(tǒng)保證數(shù)據(jù)同步到磁盤,速度最快 你的數(shù)據(jù)只需要交給操作系統(tǒng)就行

默認(rèn)1s一次,最多有1s丟失

8.2.2 重寫機(jī)制

由于AOF是追加的形式,所以文件會越來越大,越大的話,數(shù)據(jù)加載越慢。 所以我們需要對AOF文件進(jìn)行重寫。

何為重寫

比如 我們的incr指令,假如我們incr了100次,現(xiàn)在數(shù)據(jù)是100,但是我們的aof文件中會有100條incr指令,但是我們發(fā)現(xiàn)這個100條指令用處不大, 假如我們能把最新的內(nèi)存里的數(shù)據(jù)保存下來的話。所以,重寫就是做了這么一件事情,把當(dāng)前內(nèi)存的數(shù)據(jù)重寫下來,然后把之前的追加的文件刪除。

重寫流程

  • 在Redis7之前
  1. Redis fork一個子進(jìn)程,在一個臨時文件中寫入新的AOF(當(dāng)前內(nèi)存的數(shù)據(jù)生成的新的AOF)
  2. 那么在寫入新的AOF的時候,主進(jìn)程還會有指令進(jìn)入,那么主進(jìn)程會在內(nèi)存緩存區(qū)中累計新的指令 (但是同時也會寫在舊的AOF文件中,就算 重寫失敗,也不會導(dǎo)致AOF損壞或者數(shù)據(jù)丟失)
  3. 如果子進(jìn)程重寫完成,父進(jìn)程會收到完成信號,并且把內(nèi)存緩存中的指令追加到新的AOF文件中
  4. 替換舊的AOF文件 ,并且將新的指令附加到重寫好的AOF文件中
  • 在Redis7之后,AOF文件不再是一個,所以會有臨時清單的概念
  1. 子進(jìn)程開始在一個臨時文件中寫入新的基礎(chǔ)AOF
  2. 父級打開一個新的增量 AOF 文件以繼續(xù)寫入更新。如果重寫失敗,舊的基礎(chǔ)和增量文件(如果有的話)加上這個新打開的增量文件就代表了完整的更新數(shù)據(jù)集,所以我們是安全的
  3. 當(dāng)子進(jìn)程完成基礎(chǔ)文件的重寫后,父進(jìn)程收到一個信號,并使用新打開 的增量文件和子進(jìn)程生成的基礎(chǔ)文件來構(gòu)建臨時清單,并將其持久化
  4. 現(xiàn)在 Redis 對清單文件進(jìn)行原子交換,以便此 AOF 重寫的結(jié)果生效。 Redis 還會清理舊的基礎(chǔ)文件和任何未使用的增量文件

但是重寫是把當(dāng)前內(nèi)存的數(shù)據(jù),寫入一個新的AOF文件,如果當(dāng)前數(shù)據(jù)比較大,然后以指令的形式寫入的話,會很慢很慢

所以在4.0之后,在重寫的時候是采用RDB的方式去生成新的AOF文件,然 后后續(xù)追加的指令,還是以指令追加的形式追加的文件末尾

aof-use-rdb-preamble yes //是否開啟RDB與AOF混合模式

什么時候重寫

配置文件redis.conf

# 重寫觸發(fā)機(jī)制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb 就算達(dá)到了第一個百分比的大小,也必須大于 64M

在 aof 文件小于64mb的時候不進(jìn)行重寫,當(dāng)?shù)竭_(dá)64mb的時候,就重寫一
次。重寫后的 aof 文件可能是40mb。上面配置了auto-aof-rewritepercentag為100,即 aof 文件到了80mb的時候,進(jìn)行重寫。

8.2.3 AOF的優(yōu)勢與不足

優(yōu)勢

  1. 安全性高,就算是默認(rèn)的持久化同步機(jī)制,也最多只會丟失1s數(shù)據(jù)
  2. AOF由于某些原因,比如磁盤滿了等導(dǎo)致追加失敗,也能通過redischeck-aof 工具來修復(fù)
  3. 格式都是追加的日志,所以可讀性更高

不足

  1. 數(shù)據(jù)集一般比RDB大
  2. 持久化跟數(shù)據(jù)加載比RDB更慢
  3. 在7.0之前,重寫的時候,因?yàn)橹貙懙臅r候,新的指令會緩存在內(nèi)存區(qū),所以會導(dǎo)致大量的內(nèi)存使用
  4. 并且重寫期間,會跟磁盤進(jìn)行2次IO,一個是寫入老的AOF文件,一個是寫入新的AOF文件

九、Redis常見問題總結(jié)

9.1 Redis數(shù)據(jù)丟失場景

9.1.1 持久化丟失

采用RDB或者不持久化, 會有數(shù)據(jù)丟失,因?yàn)槭鞘謩踊蛘吲渲靡钥煺盏男问絹磉M(jìn)行備份。

解決:啟用AOF,以命令追加的形式進(jìn)行備份,但是默認(rèn)也會有1s丟失, 這是在性能與數(shù)據(jù)安全性中尋求的一個最適合的方案,如果為了保證數(shù)據(jù) 一致性,可以將配置更改為always,但是性能很慢,一般不用。

9.1.2 主從切換

因?yàn)镽edis的數(shù)據(jù)是主異步同步給從的,提升了性能,但是由于是異步同步到從。所以存在數(shù)據(jù)丟失的可能

  1. master寫入數(shù)據(jù)k1 ,由于是異步同步到slave,當(dāng)master沒有同步給slave的時候,master掛了
  2. slave會成為新的master,并且沒有同步k1
  3. master重啟,會成為新master的slave,同步數(shù)據(jù)會清空自己的數(shù)據(jù),從新的master加載
  4. k1丟失

9.2 Redis緩存雪崩、穿透、擊穿問題分析

9.2.1 緩存雪崩

緩存雪崩就是Redis的大量熱點(diǎn)數(shù)據(jù)同時過期(失效),因?yàn)樵O(shè)置了相同的過期時間,剛好這個時候Redis請求的并發(fā)量又很大,就會導(dǎo)致所有的請求落到數(shù)據(jù)庫。

  1. 保證Redis的高可用,防止由于Redis不可用導(dǎo)致全部打到DB
  2. 加互斥鎖或者使用隊(duì)列,針對同一個key只允許一個線程到數(shù)據(jù)庫查詢
  3. 緩存定時預(yù)先更新,避免同時失效
  4. 通過加隨機(jī)數(shù),使key在不同的時間過期

9.2.2 緩存穿透

緩存穿透是指緩存和數(shù)據(jù)庫中都沒有的數(shù)據(jù),但是用戶一直請求不存在的數(shù)據(jù)!這時的用戶很可能就是攻擊者,惡意搞你們公司的,攻擊會導(dǎo)致數(shù)據(jù)庫壓力過大。

解決方案:布隆過濾器

布隆過濾器的思想:既然是因?yàn)槟鉘edis跟DB都沒有,然后用戶惡意一直訪問不存在的key,然后全部打到Redis跟DB。那么我們能不能單獨(dú)把DB的數(shù)據(jù)單獨(dú)存到另外一個地方,但是這個地方只存一個簡單的標(biāo)記,標(biāo)記這個key存不存在,如果存在,就去訪問Redis跟DB,否則直接返回。并且這個內(nèi)存最好很小。

9.2.3 緩存擊穿

單個key過期的時候有大量并發(fā),使用互斥鎖,回寫redis,并且采用雙重檢查鎖來提升性能!減少對DB的訪問。

到此這篇關(guān)于一篇文章帶你弄清楚Redis的精髓的文章就介紹到這了,更多相關(guān)一文搞懂Redis內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • Redis下載部署并加入idea應(yīng)用的小結(jié)

    Redis下載部署并加入idea應(yīng)用的小結(jié)

    這篇文章主要介紹了Redis下載部署并加入idea應(yīng)用,需要的朋友可以參考下
    2022-10-10
  • Redis配合SSDB實(shí)現(xiàn)持久化存儲代碼示例

    Redis配合SSDB實(shí)現(xiàn)持久化存儲代碼示例

    這篇文章主要介紹了Redis配合SSDB實(shí)現(xiàn)持久化存儲代碼示例,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下
    2020-11-11
  • Redis集群部署的過程詳解

    Redis集群部署的過程詳解

    Redis集群是Redis官方推出的分布式解決方案,它允許將數(shù)據(jù)分布在多個Redis節(jié)點(diǎn)中,從而提高Redis的性能和可擴(kuò)展性,本文給大家介紹了Redis集群部署的過程步驟,需要的朋友可以參考下
    2024-06-06
  • Redis 基礎(chǔ)教程之事務(wù)的使用方法

    Redis 基礎(chǔ)教程之事務(wù)的使用方法

    這篇文章主要介紹了Redis 基礎(chǔ)教程之事務(wù)的使用方法的相關(guān)資料,Redis 事務(wù)可以一次執(zhí)行多個命令和保證,單獨(dú)的隔離操作和原子操作需要的朋友可以參考下
    2017-08-08
  • redis過期監(jiān)聽機(jī)制方式

    redis過期監(jiān)聽機(jī)制方式

    這篇文章主要介紹了redis過期監(jiān)聽機(jī)制方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2024-05-05
  • redis緩存一致性延時雙刪代碼實(shí)現(xiàn)方式

    redis緩存一致性延時雙刪代碼實(shí)現(xiàn)方式

    這篇文章主要介紹了redis緩存一致性延時雙刪代碼實(shí)現(xiàn)方式,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2022-08-08
  • 詳解Redis實(shí)現(xiàn)限流的三種方式

    詳解Redis實(shí)現(xiàn)限流的三種方式

    這篇文章主要介紹了詳解Redis實(shí)現(xiàn)限流的三種方式,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2021-04-04
  • spring?boot整合redis中間件與熱部署實(shí)現(xiàn)代碼

    spring?boot整合redis中間件與熱部署實(shí)現(xiàn)代碼

    spring?boot整合redis最常用的有三個工具庫Jedis,Redisson,Lettuce,本文重點(diǎn)介紹spring?boot整合redis中間件與熱部署實(shí)現(xiàn),需要的朋友可以參考下
    2023-01-01
  • Redis類型type與編碼encoding原理及使用示例

    Redis類型type與編碼encoding原理及使用示例

    這篇文章主要為大家介紹了Redis類型type與編碼encoding原理及使用示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-03-03
  • Redis官方ORM框架比RedisTemplate更優(yōu)雅

    Redis官方ORM框架比RedisTemplate更優(yōu)雅

    這篇文章主要為大家介紹了Redis官方ORM框架比RedisTemplate更優(yōu)雅的使用詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-07-07

最新評論