當(dāng)前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

【Redis】一文掌握Redis原理及常见问题

發(fā)布時間：2023/12/31 数据库 32 coder

生活随笔收集整理的這篇文章主要介紹了【Redis】一文掌握Redis原理及常见问题小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

Redis是基于內(nèi)存數(shù)據(jù)庫，操作效率高，提供豐富的數(shù)據(jù)結(jié)構(gòu)（Redis底層對數(shù)據(jù)結(jié)構(gòu)還做了優(yōu)化），可用作數(shù)據(jù)庫，緩存，消息中間件等。如今廣泛用于互聯(lián)網(wǎng)大廠，面試必考點之一，本文從數(shù)據(jù)結(jié)構(gòu)，到集群，到常見問題逐步深入了解Redis，看完再也不怕面試官提問！

高性能之道

單線程模型
基于內(nèi)存操作
epoll多路復(fù)用模型
高效的數(shù)據(jù)存儲結(jié)構(gòu)

redis的單線程指的是數(shù)據(jù)處理使用的單線程，實際上它主要包含

IO線程：處理網(wǎng)絡(luò)消息收發(fā)

主線程：處理數(shù)據(jù)讀寫操作，包括事務(wù)、Lua腳本等

持久化線程：執(zhí)行RDB或AOF時，使用持久化線程處理，避免主線程的阻塞

過期鍵清理線程：用于定期清理過期鍵

至于redis為什么使用單線程處理數(shù)據(jù)，是因為redis基于內(nèi)存操作，并且有高效的數(shù)據(jù)類型，它的性能瓶頸并不在CPU計算，主要在于網(wǎng)絡(luò)IO，而網(wǎng)絡(luò)IO在后來的版本中也被獨立出來了IO線程，因此它能快速處理數(shù)據(jù)，單線程反而避免了多線程所帶來的并發(fā)和資源爭搶的問題

全局?jǐn)?shù)據(jù)存儲

Redis底層存儲基于全局Hash表，存儲結(jié)構(gòu)和Java的HashMap類似（數(shù)組+鏈表方式）

rehash

Redis 默認(rèn)使用了兩個全局哈希表：哈希表 1 和哈希表 2。一開始，當(dāng)你剛插入數(shù)據(jù)時，默認(rèn)使用哈希表 1，此時的哈希表 2 并沒有被分配空間。隨著數(shù)據(jù)逐步增多，Redis 開始執(zhí)行 rehash

給哈希表 2 分配更大的空間，例如是當(dāng)前哈希表 1 大小的兩倍；
把哈希表 1 中的數(shù)據(jù)重新進(jìn)行打散映射到hash表2中；這個過程采用漸進(jìn)式hash
即拷貝數(shù)據(jù)時，Redis 仍然正常處理客戶端請求，每處理一個請求時，從哈希表 1 中的第一個索引位置開始，順帶著將這個索引位置上的所有 entries 拷貝到哈希表 2 中；等處理下一個請求時，再順帶拷貝哈希表 1 中的下一個索引位置的 entries
釋放哈希表 1 的空間。

數(shù)據(jù)類型

查看存儲編碼類型：object encoding key

1. string

源碼位置：t_string.c

string是最常用的類型，它的底層存儲結(jié)構(gòu)是SDS

存儲結(jié)構(gòu)

redis的string分三種情況對對象編碼，目的是為了節(jié)省內(nèi)存空間：

robj *tryObjectEncodingEx(robj *o, int try_trim)

if: value長度小于20字節(jié)且可以轉(zhuǎn)換為整數(shù)（long類型），編碼為OBJ_ENCODING_INT，其中若數(shù)字在0到10000之間，還可以使用內(nèi)存共享的數(shù)字對象
else if: 若value長度小于OBJ_ENCODING_EMBSTR_SIZE_LIMIT（44字節(jié)），編碼為OBJ_ENCODING_EMBSTR
else: 保持編碼為OBJ_ENCODING_RAW

常用命令

SET key value
MSET key value [key value ...]
SETNX key value #常用作分布式鎖
GET key
MGET key [key ...]
DEL key [key ...]
EXPIRE key seconds
INCR key
DECR key
INCRBY key increment
DECRBY key increment

常用場景

簡單鍵值對
自增計數(shù)器

INCR作為主鍵的問題

缺陷：若數(shù)據(jù)量大的情況下，大量使用INCR來自增主鍵會讓redis的自增操作頻繁，影響redis的正常使用
優(yōu)化：每臺服務(wù)可以使用INCRBY一次性獲取一百或者一千或者多少個id段來慢慢分配，這樣能大量減少redis的incr命令所帶來的消耗

2. list

源碼位置：t_list.c

存儲結(jié)構(gòu)

redis的list首先會按緊湊列表存儲（listPack），當(dāng)緊湊列表的長度達(dá)到list_max_listpack_size之后，會轉(zhuǎn)換為雙向鏈表

// 1.LPUSH/RPUSH/LPUSHX/RPUSHX這些命令的統(tǒng)一入口
void pushGenericCommand(client *c, int where, int xx)
// 2.追加元素，并嘗試轉(zhuǎn)換緊湊列表
void listTypeTryConversionAppend(robj *o, robj **argv, int start, int end, beforeConvertCB fn, void *data)
// 3.嘗試轉(zhuǎn)換緊湊列表
static void listTypeTryConversionRaw(robj *o, list_conv_type lct, robj **argv, int start, int end, beforeConvertCB fn, void *data)
// 4.嘗試轉(zhuǎn)換緊湊列表
// 若緊湊列表的長度達(dá)到list_max_listpack_size之后，則轉(zhuǎn)換
static void listTypeTryConvertQuicklist(robj *o, int shrinking, beforeConvertCB fn, void *data)

當(dāng)redis進(jìn)行l(wèi)ist元素移除時

// 1.移除list元素的統(tǒng)一入口
void listElementsRemoved(client *c, robj *key, int where, robj *o, long count, int signal, int *deleted)
// 2.嘗試轉(zhuǎn)換
void listTypeTryConversion(robj *o, list_conv_type lct, beforeConvertCB fn, void *data)
// 3.嘗試轉(zhuǎn)換
static void listTypeTryConversionRaw(robj *o, list_conv_type lct, robj **argv, int start, int end, beforeConvertCB fn, void *data)
// 4.嘗試轉(zhuǎn)換雙向鏈表
// 若雙向鏈表中只剩一個節(jié)點，且是壓縮節(jié)點，則對雙向鏈表轉(zhuǎn)換為緊湊列表
static void listTypeTryConvertQuicklist(robj *o, int shrinking, beforeConvertCB fn, void *data)

以下參數(shù)可在redis.conf配置

list_max_listpack_size：默認(rèn)-2

常用命令

LPUSH key value [value ...]
RPUSH key value [value ...]
LPOP key
RPOP key
LRANGE key start stop
BLPOP key [key ...] timeout #從key列表頭彈出一個元素，若沒有元素，則阻塞等待timeout秒，0則一直阻塞等待
BRPOP key [key ...] timeout #從key列表尾彈出一個元素，若沒有元素，則阻塞等待timeout秒，0則一直阻塞等待

組合數(shù)據(jù)結(jié)構(gòu)

根據(jù)list的特性，可以組成實現(xiàn)以下常用的數(shù)據(jù)結(jié)構(gòu)

Stack（棧）：LPUSH + LPOP
Queue（隊列）：LPUSH + RPOP
Blocking MQ（阻塞隊列）：LPUSH + BRPOP

redis實現(xiàn)數(shù)據(jù)結(jié)構(gòu)的意義在于分布式環(huán)境的實現(xiàn)

常用場景

緩存有序列表結(jié)構(gòu)
構(gòu)建分布式數(shù)據(jù)結(jié)構(gòu)（棧、隊列等）

3. hash

源碼位置：t_hash.c

存儲結(jié)構(gòu)

redis的hash首先會按緊湊列表存儲（listPack），當(dāng)緊湊列表的長度達(dá)到hash_max_listpack_entries或添加的元素大小超過hash_max_listpack_value之后，會轉(zhuǎn)換為Hash表

// 1.添加hash元素
void hsetCommand(client *c)
void hsetnxCommand(client *c)
// 2.嘗試轉(zhuǎn)換Hash表
// 若緊湊列表的長度達(dá)到hash_max_listpack_entries
// 或添加的元素大小超過hash_max_listpack_value
// 則進(jìn)行轉(zhuǎn)換
void hashTypeTryConversion(robj *o, robj **argv, int start, int end)
// 3.嘗試轉(zhuǎn)換Hash表
void hashTypeConvert(robj *o, int enc)
// 4.轉(zhuǎn)換Hash表
void hashTypeConvertListpack(robj *o, int enc)

以下參數(shù)可在redis.conf配置

hash_max_listpack_value：默認(rèn)64

hash_max_listpack_entries：默認(rèn)512

常用命令

HSET key field value
HSETNX key field value
HMSET key field value [field value ...]
HGET key field
HMGET key field [field ...]
HDEL key field [field ...]
HLEN key
HGETALL key
HINCRBY key field increment

常用場景

對象緩存

4. set

源碼位置：t_set.c

存儲結(jié)構(gòu)

redis的set添加元素時，若存儲對象是整形數(shù)字且集合小于set_max_intset_entries，則存儲為OBJ_ENCODING_INTSET，若集合長度小于set_max_listpack_entries時，存儲為緊湊列表。否則，存儲為Hash表

// 1.添加set元素
void saddCommand(client *c)
// 2.1.創(chuàng)建set表
// 若存儲對象是整形數(shù)字且集合小于set_max_listpack_entries，則存儲為OBJ_ENCODING_INTSET
// 若集合長度小于set_max_listpack_entries時，存儲為緊湊列表
// 否則存儲為Hash表
robj *setTypeCreate(sds value, size_t size_hint)
// 2.2 嘗試轉(zhuǎn)換set表
// 如果編碼是OBJ_ENCODING_LISTPACK（緊湊列表），且集合長度大于set_max_listpack_entries
// 或編碼是OBJ_ENCODING_INTSET（整形集合），且集合長度大于set_max_intset_entries
// 則進(jìn)行轉(zhuǎn)換為Hash表
void setTypeMaybeConvert(robj *set, size_t size_hint)
// 2.3 添加元素
int setTypeAdd(robj *subject, sds value)
int setTypeAddAux(robj *set, char *str, size_t len, int64_t llval, int str_is_sds)
// 2.4 若整形數(shù)組添加元素，長度超過set_max_intset_entries，則轉(zhuǎn)換為Hash表
static void maybeConvertIntset(robj *subject)

以下參數(shù)可在redis.conf配置

set_max_intset_entries：默認(rèn)512

set_max_listpack_entries：默認(rèn)128

常用命令

SADD key member [member ...]
SREM key member [member ...]
SMEMBERS key
SCARD key
SISMEMBERS key member
SRANDMEMBER key [count]
SPOP key [count]
SRANDOMEMBER key [count]
SINTER key [key ...] #交集運(yùn)算
SINTERSTORE destination key [key ...] #將交集結(jié)果存入新集合destination
SUNION key [key ...] #并集運(yùn)算
SUNIONSTORE destination key [key ...] #將并集結(jié)果存入新集合destination
SDIFF key [key ...] #差集運(yùn)算
SDIFFSTORE destination key [key ...] #將差集結(jié)果存入新集合destination

常用場景

緩存無序集合
需要求交集并集差集的場景

5. sortedset

源碼位置：t_zset.c

存儲結(jié)構(gòu)

根據(jù)情況可能創(chuàng)建緊湊列表或跳表

// 1.添加元素
void zaddCommand(client *c)
void zaddGenericCommand(client *c, int flags)
// 2.1 創(chuàng)建元素
// 若集合長度<=zset_max_listpack_entries 并且值的長度<=zset_max_listpack_value，則創(chuàng)建緊湊列表
// 否則創(chuàng)建跳表節(jié)點
robj *zsetTypeCreate(size_t size_hint, size_t val_len_hint)
// 2.2 添加元素
// 若集合是緊湊列表，且集合元素超過zset_max_listpack_entries
// 或當(dāng)前添加的元素長度超過zset_max_listpack_value
// 則將緊湊列表轉(zhuǎn)換為跳表
int zsetAdd(robj *zobj, double score, sds ele, int in_flags, int *out_flags, double *newscore)

以下參數(shù)可在redis.conf配置

zset_max_listpack_entries：默認(rèn)128

zset_max_listpack_value：默認(rèn)64

跳表僅在以下情況轉(zhuǎn)換回壓縮列表

使用命令georadius時，判斷元素長度若小于等于zset_max_listpack_entries，并且最大元素的長度小于等于zset_max_listpack_value

void georadiusGeneric(client *c, int srcKeyIndex, int flags)

使用命令zunion/zinter/zdiff命令（求并集交集差集）時，判斷元素長度若小于等于zset_max_listpack_entries，并且最大元素的長度小于等于zset_max_listpack_value

void zunionInterDiffGenericCommand(client *c, robj *dstkey, int numkeysIndex, int op, int cardinality_only)

常用命令

ZADD key score member [[score member]...]
ZREM key member [member ...]
ZSCORE key member
ZINCRBY key increment member
ZCARD key
ZRANGE key start stop [WITHSCORES]
ZREVRANGE key start stop [WITHSCORES]
ZUNIONSTORE destkey numkeys key [key ...] # 并集計算
ZINTERSTORE destkey numkeys key [key ...] # 交集計算

常用場景

排行榜

底層數(shù)據(jù)結(jié)構(gòu)

RedisObject

源碼位置：server.h

{
   unsigned type:4;//類型 五種對象類型
   unsigned encoding:4;//編碼
   void *ptr;//指向底層實現(xiàn)數(shù)據(jù)結(jié)構(gòu)的指針
   int refcount;//引用計數(shù)
   unsigned lru:24;//記錄最后一次被命令程序訪問的時間
}robj;

type ：表示對象的類型，占4個比特；目前包括REDIS_STRING(字符串)、REDIS_LIST (列表)、REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。
encoding：占4個比特，Redis支持的每種類型，都有至少兩種內(nèi)部編碼，例如對于字符串，有int、embstr、raw三種編碼。通過encoding屬性，Redis可以根據(jù)不同的使用場景來為對象設(shè)置不同的編碼，大大提高了Redis的靈活性和效率。以列表對象為例，有緊湊列表和雙端鏈表兩種編碼方式；如果列表中的元素較少，Redis傾向于使用緊湊列表進(jìn)行存儲，因為緊湊列表占用內(nèi)存更少，而且比雙端鏈表可以更快載入；當(dāng)列表對象元素較多時，緊湊列表就會轉(zhuǎn)化為更適合存儲大量元素的雙端鏈表。
ptr：指針指向具體的數(shù)據(jù)。
refcount：記錄的是該對象被引用的次數(shù)，類型為整型。主要用于對象的引用計數(shù)和內(nèi)存回收。Redis中被多次使用的對象(refcount>1)，稱為共享對象。Redis為了節(jié)省內(nèi)存，當(dāng)有一些對象重復(fù)出現(xiàn)時，新的程序不會創(chuàng)建新的對象，而是仍然使用原來的對象。這個被重復(fù)使用的對象，就是共享對象。目前共享對象僅支持整數(shù)值的字符串對象。共享對象只能是整數(shù)值的字符串對象，但是5種類型都可能使用共享對象。Redis服務(wù)器在初始化時，會創(chuàng)建10000個字符串對象，值分別是0~9999的整數(shù)值；
lru：Redis 對象頭中的 lru 字段，在 LRU 算法下和 LFU 算法下使用方式并不相同。
- 在 LRU 算法中，Redis 對象頭的 24 bits 的 lru 字段是用來記錄 key 的訪問時間戳，因此在 LRU 模式下，Redis可以根據(jù)對象頭中的 lru 字段記錄的值，來比較最后一次 key 的訪問時間長，從而淘汰最久未被使用的 key。
- 在 LFU 算法中，Redis對象頭的 24 bits 的 lru 字段被分成兩段來存儲，高 16bit 存儲 ldt(Last Decrement Time)，低 8bit 存儲 logc(Logistic Counter)。
一個redisObject對象的大小為16字節(jié)：4bit+4bit+24bit+4Byte+8Byte=16Byte

SDS 簡單動態(tài)字符串(Simple Dynamic String)

源碼位置：sds.h

typedef char *sds;
struct __attribute__ ((__packed__)) sdshdr5 { // 對應(yīng)的字符串長度小于 1<<5 32字節(jié)
   unsigned char flags; /* 3 lsb of type, and 5 msb of string length intembstr*/
   char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 { // 對應(yīng)的字符串長度小于 1<<8 256
   uint8_t len; /* used */ //目前字符創(chuàng)的長度 用1字節(jié)存儲
   uint8_t alloc; //已經(jīng)分配的總長度 用1字節(jié)存儲
   unsigned char flags; //flag用3bit來標(biāo)明類型，類型后續(xù)解釋，其余5bit目前沒有使用 embstr raw
   char buf[]; //柔性數(shù)組，以'\0'結(jié)尾
};
struct __attribute__ ((__packed__)) sdshdr16 { // 對應(yīng)的字符串長度小于 1<<16
   uint16_t len; /*已使用長度，用2字節(jié)存儲*/
   uint16_t alloc; /* 總長度，用2字節(jié)存儲*/
   unsigned char flags; /* 3 lsb of type, 5 unused bits */
   char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 { // 對應(yīng)的字符串長度小于 1<<32
   uint32_t len; /*已使用長度，用4字節(jié)存儲*/
   uint32_t alloc; /* 總長度，用4字節(jié)存儲*/
   unsigned char flags;/* 低3位存儲類型, 高5位預(yù)留 */
   char buf[];/*柔性數(shù)組，存放實際內(nèi)容*/
};
struct __attribute__ ((__packed__)) sdshdr64 { // 對應(yīng)的字符串長度小于 1<<64
   uint64_t len; /*已使用長度，用8字節(jié)存儲*/
   uint64_t alloc; /* 總長度，用8字節(jié)存儲*/
   unsigned char flags; /* 低3位存儲類型, 高5位預(yù)留 */
   char buf[];/*柔性數(shù)組，存放實際內(nèi)容*/
};

字符串類型的內(nèi)部編碼有3種

int：8個字節(jié)的長整型。字符串值是整型時，這個值使用long整型表示。
embstr：**<=44字節(jié)的字符串。embstr與raw都使用redisObject和sds保存數(shù)據(jù)，區(qū)別在于，embstr的使用只分配一次內(nèi)存空間（因此redisObject和sds是連續(xù)的），而raw需要分配兩次內(nèi)存空間（分別為redisObject和sds分配空間）。因此與raw相比，embstr的好處在于創(chuàng)建時少分配一次空間，刪除時少釋放一次空間，以及對象的所有數(shù)據(jù)連在一起，尋找方便。而embstr的壞處也很明顯，如果字符串的長度增加需要重新分配內(nèi)存時，整個redisObject和sds都需要重新分配空間**，因此redis中的embstr實現(xiàn)為只讀。
raw：大于44個字節(jié)的字符串

embstr和raw進(jìn)行區(qū)分的長度，是44；是因為redisObject的長度是16字節(jié)，sds的長度是4+字符串長度；因此當(dāng)字符串長度是44時，embstr的長度正好是16+4+44 =64，jemalloc正好可以分配64字節(jié)的內(nèi)存單元。

壓縮列表zipList

ziplist 被設(shè)計成一種內(nèi)存緊湊型的數(shù)據(jù)結(jié)構(gòu)，占用一塊連續(xù)的內(nèi)存空間，不僅可以利用 CPU 緩存，而且會針對不同長度的數(shù)據(jù)，進(jìn)行相應(yīng)編碼，這種方法可以有效地節(jié)省內(nèi)存開銷。

ziplist 是一個特殊雙向鏈表，不像普通的鏈表使用前后指針關(guān)聯(lián)在一起，它是存儲在連續(xù)內(nèi)存上的。

/* 創(chuàng)建一個空的 ziplist. */
unsigned char *ziplistNew(void) {
    unsigned int bytes = ZIPLIST_HEADER_SIZE+ZIPLIST_END_SIZE;
    unsigned char *zl = zmalloc(bytes);
    ZIPLIST_BYTES(zl) = intrev32ifbe(bytes);
    ZIPLIST_TAIL_OFFSET(zl) = intrev32ifbe(ZIPLIST_HEADER_SIZE);
    ZIPLIST_LENGTH(zl) = 0;
    zl[bytes-1] = ZIP_END;
    return zl;
}

zlbytes: 32 位無符號整型，記錄 ziplist 整個結(jié)構(gòu)體的占用空間大小。當(dāng)然了也包括 zlbytes 本身。這個結(jié)構(gòu)有個很大的用處，就是當(dāng)需要修改 ziplist 時候不需要遍歷即可知道其本身的大小。這和SDS中記錄字符串的長度有相似之處。
zltail: 32 位無符號整型, 記錄整個 ziplist 中最后一個 entry 的偏移量。所以在尾部進(jìn)行 POP 操作時候不需要先遍歷一次。
zllen: 16 位無符號整型, 記錄 entry 的數(shù)量，所以只能表示 2^16。但是 Redis 作了特殊的處理：當(dāng)實體數(shù)超過 2^16 ,該值被固定為 2^16 - 1。所以這種時候要知道所有實體的數(shù)量就必須要遍歷整個結(jié)構(gòu)了。
entry: 真正存數(shù)據(jù)的結(jié)構(gòu)。
zlend: 8 位無符號整型, 固定為 255 (0xFF)。為 ziplist 的結(jié)束標(biāo)識。

zipList缺陷

ziplist 在更新或者新增時候，如空間不夠則需要對整個列表進(jìn)行重新分配。當(dāng)新插入的元素較大時，可能會導(dǎo)致后續(xù)元素的 prevlen 占用空間都發(fā)生變化，從而引起「連鎖更新」問題，導(dǎo)致每個元素的空間都要重新分配，造成訪問壓縮列表性能的下降。

ziplist 節(jié)點的 prevlen 屬性會根據(jù)前一個節(jié)點的長度進(jìn)行不同的空間大小分配：

如果前一個節(jié)點的長度小于 254 字節(jié)，那么 prevlen 屬性需要用 1 字節(jié)的空間來保存這個長度值。
如果前一個節(jié)點的長度大于等于 254 字節(jié)，那么 prevlen 屬性需要用 5 字節(jié)的空間來保存這個長度值。

假設(shè)有這樣的一個 ziplist，每個節(jié)點都是等于 253 字節(jié)的。新增了一個大于等于 254 字節(jié)的新節(jié)點，由于之前的節(jié)點 prevlen 長度是 1 個字節(jié)。

為了要記錄新增節(jié)點的長度所以需要對節(jié)點 1 進(jìn)行擴(kuò)展，由于節(jié)點 1 本身就是 253 字節(jié)，再加上擴(kuò)展為 5 字節(jié)的 pervlen 則長度超過了 254 字節(jié)，這時候下一個節(jié)點又要進(jìn)行擴(kuò)展了

zipList特性

ziplist 為了節(jié)省內(nèi)存，采用了緊湊的連續(xù)存儲。所以在修改操作下并不能像一般的鏈表那么容易，需要從新分配新的內(nèi)存，然后復(fù)制到新的空間。
ziplist 是一個雙向鏈表，可以在時間復(fù)雜度為 O(1) 從下頭部、尾部進(jìn)行 pop 或 push。
新增或更新元素可能會出現(xiàn)連鎖更新現(xiàn)象。
不能保存過多的元素，否則查詢效率就會降低。

緊湊列表listPack

Redis7.0之后采用listPack全面替代zipList

在 Redis5.0 出現(xiàn)了 listpack，目的是替代壓縮列表，其最大特點是 listpack 中每個節(jié)點不再包含前一個節(jié)點的長度，壓縮列表每個節(jié)點正因為需要保存前一個節(jié)點的長度字段，就會有連鎖更新的隱患。

unsigned char *lpNew(size_t capacity) {
    unsigned char *lp = lp_malloc(capacity > LP_HDR_SIZE+1 ? capacity : LP_HDR_SIZE+1);
    if (lp == NULL) return NULL;
    lpSetTotalBytes(lp,LP_HDR_SIZE+1);
    lpSetNumElements(lp,0);
    lp[LP_HDR_SIZE] = LP_EOF;
    return lp;
}

listpack 中每個節(jié)點不再包含前一個節(jié)點的長度，避免連鎖更新的隱患發(fā)生。
listpack 相對于 ziplist，沒有了指向末尾節(jié)點地址的偏移量，解決 ziplist 內(nèi)存長度限制的問題。但一個 listpack 最大內(nèi)存使用不能超過 1GB。

跳表

數(shù)組：查詢快，插入刪除慢
鏈表：查詢慢，插入刪除快
跳表：跳表是基于鏈表的一個優(yōu)化，在鏈表的插入刪除快的特性之上，也增加了它的查詢效率。它是將有序鏈表改造為支持折半查找算法，它的插入、刪除、查詢都很快

跳表缺陷：需要額外空間來建立索引層，以空間換時間，因此zset一開始是以緊湊列表存儲，后續(xù)才會轉(zhuǎn)換為跳表

跳表的創(chuàng)建（添加元素時）
1. 當(dāng)前zset不存在時，若添加元素時集合長度達(dá)到zset_max_listpack_entries，或添加的最后一個元素的大小超過zset_max_listpack_value，則直接創(chuàng)建跳表，跳表頭結(jié)點創(chuàng)建最大層數(shù)（ZSKIPLIST_MAXLEVEL：32）的索引，并插入跳表當(dāng)前添加的元素
2. 當(dāng)前zset存在時，判斷若元素長度超過zset_max_listpack_entries，則將緊湊列表轉(zhuǎn)換為跳表，跳表頭結(jié)點創(chuàng)建最大層數(shù)（ZSKIPLIST_MAXLEVEL：32）的索引，然后把其他元素依次插入跳表
跳表的查詢
從起始節(jié)點開始，通過多級索引進(jìn)行折半查找，最終找到需要的數(shù)據(jù)
跳表的插入
先通過折半查找找到節(jié)點對應(yīng)要插入的鏈表位置，然后通過隨機(jī)得到一個要插入的節(jié)點的索引層數(shù)，然后插入節(jié)點，并構(gòu)建對應(yīng)的多級索引
跳表的刪除
先通過折半查找找到要刪除的節(jié)點的鏈表位置，刪除節(jié)點，并刪除對應(yīng)的多級索引

淘汰策略

noeviction（默認(rèn)策略）：不會刪除任何數(shù)據(jù)，拒絕所有寫入操作并返回客戶端錯誤消息（error）OOM command not allowed when used memory，此時 Redis 只響應(yīng)刪和讀操作；
allkeys-lru：從所有 key 中使用 LRU（Least Recently Used）算法進(jìn)行淘汰（LRU 算法：最近最少使用算法）；
allkeys-lfu：從所有 key 中使用 LFU（Least Frequently Used）算法進(jìn)行淘汰（LFU 算法：最不常用算法，根據(jù)使用頻率計算，4.0 版本新增）；
volatile-lru：從設(shè)置了過期時間的 key 中使用 LRU 算法進(jìn)行淘汰；
volatile-lfu：從設(shè)置了過期時間的 key 中使用 LFU 算法進(jìn)行淘汰；
allkeys-random：從所有 key 中隨機(jī)淘汰數(shù)據(jù)；
volatile-random：從設(shè)置了過期時間的 key 中隨機(jī)淘汰數(shù)據(jù)；
volatile-ttl：在設(shè)置了過期時間的key中，淘汰過期時間剩余最短的。

Redis的LRU實現(xiàn)

由于Redis 主要運(yùn)行在單個線程中，它采用的是一種近似的 LRU 算法，而不是傳統(tǒng)的完全 LRU 算法（沒有把所有key組織為鏈表）。這種實現(xiàn)方式在保證性能的同時，仍然能夠有效地識別并淘汰最近最少使用的鍵。當(dāng) Redis 進(jìn)行內(nèi)存淘汰時，會使用隨機(jī)采樣的方式來淘汰數(shù)據(jù)，它是隨機(jī)取 5 個值（此值可配置），然后淘汰最久沒有使用的那個。

Redis的LFU實現(xiàn)

Redis 在訪問 key 時，對 logc進(jìn)行變化：

先按照上次訪問距離當(dāng)前的時長，來對 logc 進(jìn)行衰減；
再按照一定概率增加 logc 的值

redis.conf 提供了兩個配置項，用于調(diào)整 LFU 算法從而控制 logc 的增長和衰減：

lfu-decay-time?用于調(diào)整 logc 的衰減速度，它是一個以分鐘為單位的數(shù)值，默認(rèn)值為1，lfu-decay-time 值越大，衰減越慢；
lfu-log-factor?用于調(diào)整 logc 的增長速度，lfu-log-factor 值越大，logc 增長越慢

刪除策略

redis的key過期刪除策略采用惰性刪除+定期刪除實現(xiàn)：

惰性刪除：不主動刪除過期鍵，每次從數(shù)據(jù)庫訪問 key 時，都檢測 key 是否過期，如果過期則刪除該 key

Redis 的惰性刪除策略由 db.c 文件中的 expireIfNeeded 函數(shù)實現(xiàn)，代碼如下：

int expireIfNeeded(redisDb *db, robj *key) {
    // 判斷 key 是否過期
    if (!keyIsExpired(db,key)) return 0;
    ....
    /* 刪除過期鍵 */
    ....
    // 如果 server.lazyfree_lazy_expire 為 1 表示異步刪除，反之同步刪除；
    return server.lazyfree_lazy_expire ? dbAsyncDelete(db,key) :
                                         dbSyncDelete(db,key);
}

定期刪除：定期刪除策略的做法是，每隔一段時間隨機(jī)從數(shù)據(jù)庫中取出一定數(shù)量的 key 進(jìn)行檢查，并刪除其中的過期key

在 Redis 中，默認(rèn)每秒進(jìn)行 10 次過期檢查一次數(shù)據(jù)庫，此配置可通過 Redis 的配置文件 redis.conf 進(jìn)行配置，配置鍵為 hz 它的默認(rèn)值是 hz 10；定期刪除的實現(xiàn)在 expire.c 文件下的 activeExpireCycle 函數(shù)中，其中隨機(jī)抽查的數(shù)量由 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 定義的，它是寫死在代碼中的，數(shù)值是 20；也就是說，數(shù)據(jù)庫每輪抽查時，會隨機(jī)選擇 20 個 key 判斷是否過期。

管道Pipeline

redis提供pipeline，可以讓客戶端一次發(fā)送一連串的命令給服務(wù)器執(zhí)行，然后再返回執(zhí)行結(jié)果

應(yīng)用場景：
- 需要多次執(zhí)行一連串的redis命令，且命令之間沒有依賴的場景
缺陷：
1. 不保證原子性，pipeline拿到命令只管串行執(zhí)行，不管執(zhí)行成功與否，也沒有回滾機(jī)制
2. pipeline在執(zhí)行過程中無法知道執(zhí)行結(jié)果，只有全部執(zhí)行結(jié)束才會返回全部結(jié)果
3. pipeline也不宜一次性發(fā)送過多命令，盡管節(jié)省了IO，但在redis端也依然會進(jìn)行執(zhí)行隊列順序執(zhí)行

使用示例

/**
 * 一次io獲取個值
 *
 * @param redisKeyEnum
 * @param ids
 * @param clz
 * @param <T>
 * @param <E>
 * @return
 */
public <T, E extends T> List<T> multiGet(RedisKeyEnum redisKeyEnum, List<String> ids, Class<E> clz) {
    ShardRedisConnectionFactory factory = getShardRedisConnectionFactory(redisKeyEnum);
    ShardedJedis shardedJedis = factory.getConnection();
    return execute(factory, shardedJedis, new Supplier<List<T>>() {
        @Override
        public List<T> get() {
            // 1.獲取管道
            ShardedJedisPipeline pipeline = shardedJedis.pipelined();
            List<T> list = new ArrayList<>();
            List<Response<String>> respList = new ArrayList<>();
            for (String id : ids) {
                String key = getKey(redisKeyEnum, id);
                // 2.通過管道執(zhí)行命令
                Response<String> resp = pipeline.get(key);
                respList.add(resp);
            }
            // 3.統(tǒng)一提交命令
            pipeline.sync();
            for (Response<String> resp : respList) {
                // 4.遍歷獲取全部的命令執(zhí)行返回結(jié)果
                String result = resp.get();
                if (result == null) {
                    continue;
                }
                if (clz.equals(String.class)) {
                    list.add((E) result);
                } else {
                    list.add(JsonUtil.json2Obj(result, clz));
                }
            }
            return list;
        }
    });
}

事務(wù)

Redis 事務(wù)的本質(zhì)是一組命令的集合。事務(wù)支持一次執(zhí)行多個命令，一個事務(wù)中所有命令都會被序列化。在事務(wù)執(zhí)行過程，會按照順序串行化執(zhí)行隊列中的命令，其他客戶端提交的命令請求不會插入到事務(wù)執(zhí)行命令序列中。

事務(wù)的命令：

MULTI ：開啟事務(wù)，redis會將后續(xù)的命令逐個放入隊列中，然后使用EXEC命令來原子化執(zhí)行這個命令系列。
EXEC：執(zhí)行事務(wù)中的所有操作命令。
DISCARD：取消事務(wù)，放棄執(zhí)行事務(wù)塊中的所有命令。
WATCH：監(jiān)視一個或多個key,如果事務(wù)在執(zhí)行前，這個key(或多個key)被其他命令修改，則事務(wù)被中斷，不會執(zhí)行事務(wù)中的任何命令。
UNWATCH：取消WATCH對所有key的監(jiān)視。

redis事務(wù)在編譯錯誤可以回滾，而運(yùn)行時錯誤不能回滾，簡單說，redis事務(wù)不支持回滾

Redis的持久化

redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，簡而言之，就是在不同的時間點，將redis存儲的數(shù)據(jù)生成快照并存儲到磁盤等介質(zhì)上；
AOF，則是換了一個角度來實現(xiàn)持久化，那就是將redis執(zhí)行過的所有寫指令記錄下來，在下次redis重新啟動時，只要把這些寫指令從前到后再重復(fù)執(zhí)行一遍，就可以實現(xiàn)數(shù)據(jù)恢復(fù)了。AOF類似MySQL的binlog

其實RDB和AOF兩種方式也可以同時使用，在這種情況下，如果redis重啟的話，則會優(yōu)先采用AOF方式來進(jìn)行數(shù)據(jù)恢復(fù)，這是因為AOF方式的數(shù)據(jù)恢復(fù)完整度更高。

如果你沒有數(shù)據(jù)持久化的需求，也完全可以關(guān)閉RDB和AOF方式，這樣的話，redis將變成一個純內(nèi)存數(shù)據(jù)庫

1. AOF

AOF日志是一種追加式持久化方式，它記錄了每個寫操作命令，以追加的方式將命令寫入AOF文件。通過重新執(zhí)行AOF文件中的命令，可以重建出數(shù)據(jù)在內(nèi)存中的狀態(tài)。AOF日志提供了更精確的持久化，適用于需要更高數(shù)據(jù)安全性和實時性的場景。

優(yōu)點：

AOF日志可以實現(xiàn)更精確的數(shù)據(jù)持久化，每個寫操作都會被記錄。
在AOF文件中，數(shù)據(jù)可以更好地恢復(fù)，因為它保存了所有的寫操作歷史。
AOF日志適用于需要實時恢復(fù)數(shù)據(jù)的場景，如秒級數(shù)據(jù)恢復(fù)要求。

缺點：

AOF日志相對于RDB快照來說，可能會占用更多的磁盤空間，因為它是記錄每個寫操作的文本文件。
AOF日志在恢復(fù)大數(shù)據(jù)集時可能會比RDB快照慢，因為需要逐條執(zhí)行寫操作。

根據(jù)不同的需求，可以選擇RDB快照、AOF日志或兩者結(jié)合使用。你可以根據(jù)數(shù)據(jù)的重要性、恢復(fù)速度要求以及磁盤空間限制來選擇合適的持久化方式。有時候，也可以通過同時使用兩種方式來提供更高的數(shù)據(jù)保護(hù)級別。

2. RDB

RDB快照是一種全量持久化方式，它會周期性地將內(nèi)存中的數(shù)據(jù)以二進(jìn)制格式保存到磁盤上的RDB文件。RDB文件是一個經(jīng)過壓縮的二進(jìn)制文件，包含了數(shù)據(jù)庫在某個時間點的數(shù)據(jù)快照。RDB快照有助于實現(xiàn)緊湊的數(shù)據(jù)存儲，適合用于備份和恢復(fù)。

優(yōu)點：

RDB快照在恢復(fù)大數(shù)據(jù)集時速度較快，因為它是全量的數(shù)據(jù)快照。
由于RDB文件是壓縮的二進(jìn)制文件，它在磁盤上的存儲空間相對較小。
適用于數(shù)據(jù)備份和災(zāi)難恢復(fù)。

缺點：

RDB快照是周期性的全量持久化，可能導(dǎo)致某個時間點之后的數(shù)據(jù)丟失。
在保存快照時，Redis服務(wù)器會阻塞，可能對系統(tǒng)性能造成影響。

發(fā)布訂閱

Redis提供了基于“發(fā)布/訂閱”模式的消息機(jī)制。此種模式下，消息發(fā)布者和訂閱者不進(jìn)行直接通信，發(fā)布者客戶端向指定的頻道（channel）發(fā)布消息，訂閱該頻道的每個客戶端都可以收到該消息。結(jié)構(gòu)如下：

該消息通信模式可用于模塊間的解耦

# 訂閱消息 
subscribe channel [channel ...]
# 發(fā)布消息
publish channel "hello"
# 按模式訂閱頻道
psubscribe pattern [pattern ...]
# 退訂頻道
unsubscribe pattern [pattern ...]
# 按模式退訂頻道
punsubscribe pattern [pattern ...]

Redis發(fā)布訂閱與消息隊列的區(qū)別

消息隊列可以支持多種消息協(xié)議，但 Redis 沒有提供對這些協(xié)議的支持；
消息隊列可以提供持久化功能，但 Redis無法對消息持久化存儲，一旦消息被發(fā)送，如果沒有訂閱者接收，那么消息就會丟失；
消息隊列可以提供消息傳輸保障，當(dāng)客戶端連接超時或事務(wù)回滾等情況發(fā)生時，消息會被重新發(fā)送給客戶端，Redis 沒有提供消息傳輸保障。
發(fā)布訂閱消息量過多過頻繁，也會占用redis的內(nèi)存空間，擠占業(yè)務(wù)邏輯key的空間（可以通過放到不同redis解決）

Redis集群模式

redis集群主要有三種模式：主從復(fù)制，哨兵模式和Cluster

主從復(fù)制

主從復(fù)制模式中包含一個主數(shù)據(jù)庫實例（master）與一個或多個從數(shù)據(jù)庫實例（slave）

工作機(jī)制

slave啟動后，向master發(fā)送SYNC命令，master接收到SYNC命令后通過bgsave保存快照，并使用緩沖區(qū)記錄保存快照這段時間內(nèi)執(zhí)行的寫命令
master將保存的快照文件發(fā)送給slave，并繼續(xù)記錄執(zhí)行的寫命令
slave接收到快照文件后，加載快照文件，載入數(shù)據(jù)
master快照發(fā)送完后開始向slave發(fā)送緩沖區(qū)的寫命令，slave接收命令并執(zhí)行，完成復(fù)制初始化
master每次執(zhí)行一個寫命令都會同步發(fā)送給slave，保持master與slave之間數(shù)據(jù)的一致性

主從復(fù)制配置

replicaof 127.0.0.1 6379 # master的ip，port 
masterauth 123456 # master的密碼 
replica-serve-stale-data no # 如果slave無法與master同步，設(shè)置成slave不可讀，方便監(jiān)控腳本發(fā)現(xiàn)問題

優(yōu)缺點

優(yōu)點：

master能自動將數(shù)據(jù)同步到slave，可以進(jìn)行讀寫分離，分擔(dān)master的讀壓力
master、slave之間的同步是以非阻塞的方式進(jìn)行的，同步期間，客戶端仍然可以提交查詢或更新請求

缺點：

不具備自動容錯與恢復(fù)功能，master或slave的宕機(jī)都可能導(dǎo)致客戶端請求失敗，需要等待機(jī)器重啟或手動切換客戶端IP才能恢復(fù)
master宕機(jī)，如果宕機(jī)前數(shù)據(jù)沒有同步完，則切換IP后會存在數(shù)據(jù)不一致的問題
難以支持在線擴(kuò)容，Redis的容量受限于單機(jī)配置

哨兵模式

主從切換技術(shù)的方法是：當(dāng)主服務(wù)器宕機(jī)后，需要手動把一臺從服務(wù)器切換為主服務(wù)器，這就需要人工干預(yù)，費(fèi)事費(fèi)力，還會造成一段時間內(nèi)服務(wù)不可用。這不是一種推薦的方式，更多時候，我們優(yōu)先考慮哨兵模式。

哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進(jìn)程，作為進(jìn)程，它會獨立運(yùn)行。其原理是哨兵通過發(fā)送命令，等待Redis服務(wù)器響應(yīng)，從而監(jiān)控運(yùn)行的多個Redis實例。

這里的哨兵有兩個作用

通過發(fā)送命令，讓Redis服務(wù)器返回監(jiān)控其運(yùn)行狀態(tài)，包括主服務(wù)器和從服務(wù)器。
當(dāng)哨兵監(jiān)測到master宕機(jī)，會自動將slave切換成master，然后通過發(fā)布訂閱模式通知其他的從服務(wù)器，修改配置文件，讓它們切換主機(jī)。

然而一個哨兵進(jìn)程對Redis服務(wù)器進(jìn)行監(jiān)控，可能會出現(xiàn)問題，為此，我們可以使用多個哨兵進(jìn)行監(jiān)控。各個哨兵之間還會進(jìn)行監(jiān)控，這樣就形成了多哨兵模式。

哨兵配置

主從服務(wù)器配置

# 使得Redis服務(wù)器可以跨網(wǎng)絡(luò)訪問
bind 0.0.0.0
# 設(shè)置密碼
requirepass "123456"
# 指定主服務(wù)器，注意：有關(guān)slaveof的配置只是配置從服務(wù)器，主服務(wù)器不需要配置
slaveof 192.168.11.128 6379
# 主服務(wù)器密碼，注意：有關(guān)slaveof的配置只是配置從服務(wù)器，主服務(wù)器不需要配置
masterauth 123456

配置哨兵
在Redis安裝目錄下有一個sentinel.conf文件，copy一份進(jìn)行修改

# 禁止保護(hù)模式
protected-mode no
# 配置監(jiān)聽的主服務(wù)器，這里sentinel monitor代表監(jiān)控，mymaster代表服務(wù)器的名稱，可以自定義，192.168.11.128代表監(jiān)控的主服務(wù)器，6379代表端口，2代表只有兩個或兩個以上的哨兵認(rèn)為主服務(wù)器不可用的時候，才會進(jìn)行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定義服務(wù)的密碼，mymaster是服務(wù)名稱，123456是Redis服務(wù)器密碼
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

啟動服務(wù)器和哨兵

# 啟動Redis服務(wù)器進(jìn)程
./redis-server ../redis.conf
# 啟動哨兵進(jìn)程
./redis-sentinel ../sentinel.conf

Cluster模式

哨兵模式解決了主從復(fù)制不能自動故障轉(zhuǎn)移，達(dá)不到高可用的問題，但還是存在難以在線擴(kuò)容，Redis容量受限于單機(jī)配置的問題。

Cluster模式實現(xiàn)了Redis的分布式存儲，即每臺節(jié)點存儲不同的內(nèi)容，來解決在線擴(kuò)容的問題

Cluster特點

無中心結(jié)構(gòu)：所有的redis節(jié)點彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬
分布式存儲：Redis Cluster將數(shù)據(jù)分散存儲在多個節(jié)點上，每個節(jié)點負(fù)責(zé)存儲和處理其中的一部分?jǐn)?shù)據(jù)。這種分布式存儲方式允許集群處理更大的數(shù)據(jù)集，并提供更高的性能和可擴(kuò)展性。
數(shù)據(jù)復(fù)制：每個主節(jié)點都有一個或多個從節(jié)點，從節(jié)點會自動復(fù)制主節(jié)點上的數(shù)據(jù)。數(shù)據(jù)復(fù)制可以提供數(shù)據(jù)的冗余備份，并在主節(jié)點故障時自動切換到從節(jié)點，以保證系統(tǒng)的可用性。
自動分片和故障轉(zhuǎn)移：Redis Cluster會自動將數(shù)據(jù)分片到不同的節(jié)點上，同時提供自動化的故障檢測和故障轉(zhuǎn)移機(jī)制。當(dāng)節(jié)點發(fā)生故障或下線時，集群會自動檢測并進(jìn)行相應(yīng)的故障轉(zhuǎn)移操作（投票機(jī)制：節(jié)點的fail是通過集群中超過半數(shù)的節(jié)點檢測失效時才生效），以保持?jǐn)?shù)據(jù)的可用性和一致性。
節(jié)點間通信：Redis Cluster中的節(jié)點之間通過內(nèi)部通信協(xié)議進(jìn)行交互，共同協(xié)作完成數(shù)據(jù)的分片、復(fù)制和故障轉(zhuǎn)移等操作。節(jié)點間通信的協(xié)議和算法確保了數(shù)據(jù)的正確性和一致性。

工作機(jī)制

在Redis的每個節(jié)點上，都有一個插槽（slot），取值范圍為0-16383
當(dāng)我們存取key的時候，Redis會根據(jù)CRC16的算法得出一個結(jié)果，然后把結(jié)果對16384求余數(shù)，這樣每個key都會對應(yīng)一個編號在0-16383之間的哈希槽，通過這個值，去找到對應(yīng)的插槽所對應(yīng)的節(jié)點，然后直接自動跳轉(zhuǎn)到這個對應(yīng)的節(jié)點上進(jìn)行存取操作
為了保證高可用，Cluster模式也引入主從復(fù)制模式，一個主節(jié)點對應(yīng)一個或者多個從節(jié)點，當(dāng)主節(jié)點宕機(jī)的時候，就會啟用從節(jié)點
當(dāng)其它主節(jié)點ping一個主節(jié)點A時，如果半數(shù)以上的主節(jié)點與A通信超時，那么認(rèn)為主節(jié)點A宕機(jī)了。如果主節(jié)點A和它的從節(jié)點都宕機(jī)了，那么該集群就無法再提供服務(wù)了

Cluster模式集群節(jié)點最小配置6個節(jié)點(3主3從，因為需要半數(shù)以上)，其中主節(jié)點提供讀寫操作，從節(jié)點作為備用節(jié)點，不提供請求，只作為故障轉(zhuǎn)移使用。

Cluster部署

redis.conf配置：

port 7100 # 本示例6個節(jié)點端口分別為7100,7200,7300,7400,7500,7600 
daemonize yes # r后臺運(yùn)行 
pidfile /var/run/redis_7100.pid # pidfile文件對應(yīng)7100,7200,7300,7400,7500,7600 
cluster-enabled yes # 開啟集群模式 
masterauth passw0rd # 如果設(shè)置了密碼，需要指定master密碼
cluster-config-file nodes_7100.conf # 集群的配置文件，同樣對應(yīng)7100,7200等六個節(jié)點
cluster-node-timeout 15000 # 請求超時 默認(rèn)15秒，可自行設(shè)置

啟動redis：

[root@dev-server-1 cluster]# redis-server redis_7100.conf
[root@dev-server-1 cluster]# redis-server redis_7200.conf

組成集群：

redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7100 127.0.0.1:7200 127.0.0.1:7300 127.0.0.1:7400 127.0.0.1:7500 127.0.0.1:7600 -a passw0rd

--cluster-replicas：表示副本數(shù)量，也就是從服務(wù)器數(shù)量，因為我們一共6個服務(wù)器，這里設(shè)置1個副本，那么Redis會收到消息，一個主服務(wù)器有一個副本從服務(wù)器，那么會計算得出：三主三從。

Cluster注意點

數(shù)據(jù)分片和哈希槽：Redis Cluster 使用數(shù)據(jù)分片和哈希槽來實現(xiàn)數(shù)據(jù)的分布式存儲。每個節(jié)點負(fù)責(zé)一部分哈希槽，確保數(shù)據(jù)在集群中均勻分布。在設(shè)計應(yīng)用程序時，需要考慮數(shù)據(jù)的分片規(guī)則和哈希槽的分配，以便正確地將數(shù)據(jù)路由到相應(yīng)的節(jié)點。
節(jié)點的故障和擴(kuò)展：Redis Cluster 具有高可用性和可伸縮性。當(dāng)節(jié)點發(fā)生故障或需要擴(kuò)展集群時，需要正確處理節(jié)點的添加和刪除。故障節(jié)點會被自動檢測和替換，而添加節(jié)點需要進(jìn)行集群重新分片的操作。
客戶端的重定向：Redis Cluster 在處理鍵的讀寫操作時可能會返回重定向錯誤（MOVED 或 ASK）。應(yīng)用程序需要正確處理這些錯誤，根據(jù)重定向信息更新路由表，并將操作重定向到正確的節(jié)點上。
數(shù)據(jù)一致性的保證：由于 Redis Cluster 使用異步復(fù)制進(jìn)行數(shù)據(jù)同步，所以在節(jié)點故障和網(wǎng)絡(luò)分區(qū)恢復(fù)期間，可能會發(fā)生數(shù)據(jù)不一致的情況。應(yīng)用程序需要考慮數(shù)據(jù)一致性的問題，并根據(jù)具體業(yè)務(wù)需求采取適當(dāng)?shù)拇胧?/li>
客戶端連接的負(fù)載均衡：在連接 Redis Cluster 時，應(yīng)該使用適當(dāng)?shù)呢?fù)載均衡策略，將請求均勻地分布到集群中的各個節(jié)點上，以避免單個節(jié)點過載或出現(xiàn)熱點訪問。
事務(wù)和原子性操作：Redis Cluster 中的事務(wù)操作只能在單個節(jié)點上執(zhí)行，無法跨越多個節(jié)點。如果需要執(zhí)行跨節(jié)點的原子性操作，可以使用 Lua 腳本來實現(xiàn)。
集群監(jiān)控和管理：對 Redis Cluster 進(jìn)行監(jiān)控和管理是很重要的?？梢允褂?Redis 自帶的命令行工具或第三方監(jiān)控工具來監(jiān)控集群的狀態(tài)、性能指標(biāo)和節(jié)點健康狀況，以及執(zhí)行管理操作，如節(jié)點添加、刪除和重新分片等。

Redis常見問題

當(dāng)使用redis作為數(shù)據(jù)庫的緩存層時，會經(jīng)常遇見這幾種問題，以下是這些問題的描述以及對應(yīng)的解決方案

緩存穿透

概念：請求過來之后，訪問不存在的數(shù)據(jù)，redis中查詢不到，則穿透到數(shù)據(jù)庫進(jìn)行查詢

現(xiàn)象：大量穿透訪問造成redis命中率下降，數(shù)據(jù)庫壓力飆升

解決方案：

空值緩存：如果一個查詢的數(shù)據(jù)返回空，仍然把這個結(jié)果緩存到redis，以緩解數(shù)據(jù)庫的查詢壓力
布隆過濾器：布隆過濾器由一個很長的二進(jìn)制數(shù)組結(jié)合n個hash算法計算出n個數(shù)組下標(biāo)，將這些數(shù)據(jù)下標(biāo)置為1。在查找數(shù)據(jù)時，再次通過n個hash算法計算出數(shù)組下標(biāo)，如果這些下標(biāo)的值為1，表示該值可能存在(存在hash沖突的原因)，如果為0，則表示該值一定不存在。因此，布隆過濾器中存在，數(shù)據(jù)不一定存在，但若布隆過濾器中不存在，則數(shù)據(jù)一定不存在，依靠此特性可以過濾掉一定的空值數(shù)據(jù)

緩存擊穿

概念：請求訪問的key對應(yīng)的數(shù)據(jù)存在，但key在redis中已過期，則訪問擊穿到數(shù)據(jù)庫

現(xiàn)象：若大批請求中訪問的key均過期，那么redis正常運(yùn)行，但數(shù)據(jù)庫的瞬時并發(fā)壓力會飆升

解決方案：

熱點數(shù)據(jù)永不過期：熱點數(shù)據(jù)可以一直在redis中請求到，不會過期，則不會出現(xiàn)緩存擊穿現(xiàn)象
使用互斥鎖：當(dāng)訪問redis的key過期之后，在請求數(shù)據(jù)庫重新加載數(shù)據(jù)之前，先獲取互斥鎖（單進(jìn)程可以synchronized，分布式使用分布式鎖），獲取到鎖的請求加載數(shù)據(jù)并放進(jìn)緩存，沒有獲取到鎖的請求可以進(jìn)行重試，重試之后便能重新獲取到redis中的數(shù)據(jù)

緩存雪崩

概念：同一時間大批量key同時過期，造成瞬時對這些key的請求全部擊穿到數(shù)據(jù)庫；或redis服務(wù)不可用（宕機(jī)）

緩存雪崩與緩存擊穿的區(qū)別在于：緩存擊穿是單個熱點數(shù)據(jù)過期，而緩存雪崩是大批量熱點數(shù)據(jù)過期

現(xiàn)象：大量熱點數(shù)據(jù)的查詢請求會增加數(shù)據(jù)庫瞬時壓力

解決方案：

設(shè)置隨機(jī)過期時間：避免大量key的過期時間過于集中，可以通過隨機(jī)算法均勻分布key的過期時間點
熱點數(shù)據(jù)永不過期：可以和緩存擊穿一樣讓熱點數(shù)據(jù)不過期
搭建高可用redis服務(wù)：針對redis服務(wù)不可用，可以對redis進(jìn)行分布式部署，并實現(xiàn)故障轉(zhuǎn)移（如redis哨兵模式）
控制系統(tǒng)負(fù)載：實現(xiàn)熔斷限流或服務(wù)降級，讓系統(tǒng)負(fù)載在可控范圍內(nèi)

大key問題

概念：redis中存在占用內(nèi)存空間較多的key，其中包含多種情況，如string類型的value值過大，hash類型的所有成員總值過大，zset的成員數(shù)量過大等。大key的具體值的界定，要根據(jù)實際業(yè)務(wù)情況判斷。

現(xiàn)象：大key對業(yè)務(wù)會產(chǎn)生多方面的影響：

redis內(nèi)存占用過高：大key可能導(dǎo)致內(nèi)存空間不足，從而觸發(fā)redis的內(nèi)存淘汰策略。
阻塞其他操作：對某些大key操作可能導(dǎo)致redis實例阻塞，例如使用Del命令刪除key等。
網(wǎng)絡(luò)擁塞：大key在網(wǎng)絡(luò)傳輸中更消耗帶寬，可能造成機(jī)器內(nèi)部網(wǎng)絡(luò)帶寬打滿。
主從同步延遲：大key在redis進(jìn)行主從同步時也更容易導(dǎo)致同步延遲，影響數(shù)據(jù)一致性。

原因：

業(yè)務(wù)設(shè)計不合理：在業(yè)務(wù)設(shè)計上，沒有考慮大數(shù)據(jù)量問題，導(dǎo)致一個key存儲了大量的數(shù)據(jù)
未定期清理數(shù)據(jù)：沒有合適的刪除機(jī)制或過期機(jī)制，造成value不斷增加
業(yè)務(wù)邏輯問題：業(yè)務(wù)邏輯bug導(dǎo)致key的value只增不減

排查：

SCAN命令：通過redis的scan命令逐步遍歷數(shù)據(jù)庫中的所有key，通過比較大小，站到占用內(nèi)存較多的大key
bigkeys參數(shù)：使用redis-cli命令客戶端，連接Redis服務(wù)的時候，加上 —bigkeys 參數(shù)，可以掃描每種數(shù)據(jù)類型數(shù)量最大的key。

redis-cli -h 127.0.0.1 -p 6379 —bigkeys

Redis RDB Tools工具：使用開源工具Redis RDB Tools，分析RDB文件，掃描出Redis大key。

例如：輸出占用內(nèi)存大于1kb，排名前3的keys。

rdb —commond memory —bytes 1024 —largest 3 dump.rbd

Redis云商提供的工具：現(xiàn)在基本使用云商提供的redis實例，其本身也提供一定的方法能快速定位大key

解決方案：

大key拆分：可以根據(jù)實際業(yè)務(wù)場景，拆分多個小key，確保value大小在合理范圍內(nèi)
大key清理：redis4.0之后可以使用unlink命令以非阻塞方式安全的刪除大key
合理設(shè)置過期時間：設(shè)置過期時間可以讓數(shù)據(jù)自動失效清理，一定程度避免大key的長時間存在。
合理設(shè)置淘汰策略：redis中使用合適的淘汰策略，能在redis內(nèi)存不足時，淘汰數(shù)據(jù)，防止大key長時間占用內(nèi)存
數(shù)據(jù)壓縮：使用string類型，可以對value通過壓縮算法進(jìn)行壓縮。可以用gzip，bzip2等常用算法壓縮和解壓。需要注意的是，這種方法會增加CPU的開銷以及處理的響應(yīng)延遲，同時也增加邏輯代碼的復(fù)雜性

熱key問題

概念：redis中某個key的訪問次數(shù)比較多且明顯多于其他key，則這個key被定義為熱key

現(xiàn)象：

Redis的CPU占用過高，效率降低，影響其他業(yè)務(wù)
若熱key請求超出redis處理能力，會造成redis宕機(jī)，請求擊穿到數(shù)據(jù)庫，影響數(shù)據(jù)庫性能

原因：某個熱點數(shù)據(jù)訪問量暴增，如重大的熱搜事件、參與秒殺的商品

排查：

hotkeys參數(shù)：Redis 4.0.3 版本中新增了 hotkeys 參數(shù)，該參數(shù)能夠返回所有 key 的被訪問次數(shù)（使用前提：redis淘汰策略設(shè)置為lfu）

# redis-cli -p 6379 --hotkeys

MONITOR命令：MONITOR 命令是 Redis 提供的一種實時查看 Redis 的所有操作的方式，可以用于臨時監(jiān)控 Redis 實例的操作情況，包括讀寫、刪除等操作。該命令對 Redis 性能的影響比較大，因此禁止長時間開啟 MONITOR（生產(chǎn)環(huán)境中建議謹(jǐn)慎使用該命令）
根據(jù)業(yè)務(wù)情況分析：根據(jù)實際業(yè)務(wù)場景分析，可以提前預(yù)估可能出現(xiàn)的熱key現(xiàn)象，比如秒殺活動的商品數(shù)據(jù)等
云商redis工具：云服務(wù)一般會提供redis的熱key分析工具，合理利用，發(fā)現(xiàn)熱key

解決方案：

熱key拆分：設(shè)計一定的規(guī)則，給熱key增加后綴，變成多個key，結(jié)合Redis Cluster模式，能分散到不同的節(jié)點。會帶來業(yè)務(wù)復(fù)雜度，以及可能產(chǎn)生數(shù)據(jù)一致性問題
二級緩存：在應(yīng)用和redis中間再引入一層緩存層，如本地緩存，來緩解redis壓力
熱key單獨集群部署：針對熱key單獨做集群部署，和其他業(yè)務(wù)key進(jìn)行隔離

更多技術(shù)干貨，歡迎關(guān)注我！

總結(jié)

以上是生活随笔為你收集整理的【Redis】一文掌握Redis原理及常见问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：【电影推荐系统】Spring Boot
下一篇：《左手MongoDB右手Redis》第3