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

数据库

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

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

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

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

高性能之道

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

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

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

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

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

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

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

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

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

rehash

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

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

常用場景

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

INCR作為主鍵的問題

缺陷：若數(shù)據(jù)量大的情況下，大量使用INCR來自增主鍵會讓redis的自增操作頻繁，影響redis的正常使用
優(yōu)化：每臺服務(wù)可以使用INCRBY一次性獲取一百或者一千或者多少個(gè)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元素移除時(shí)

// 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)換雙向鏈表
// 若雙向鏈表中只剩一個(gè)節(jié)點(diǎn)，且是壓縮節(jié)點(diǎn)，則對雙向鏈表轉(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列表頭彈出一個(gè)元素，若沒有元素，則阻塞等待timeout秒，0則一直阻塞等待
BRPOP key [key ...] timeout #從key列表尾彈出一個(gè)元素，若沒有元素，則阻塞等待timeout秒，0則一直阻塞等待

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

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

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

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

常用場景

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

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í)，若存儲對象是整形數(shù)字且集合小于set_max_intset_entries，則存儲為OBJ_ENCODING_INTSET，若集合長度小于set_max_listpack_entries時(shí)，存儲為緊湊列表。否則，存儲為Hash表

// 1.添加set元素
void saddCommand(client *c)
// 2.1.創(chuàng)建set表
// 若存儲對象是整形數(shù)字且集合小于set_max_listpack_entries，則存儲為OBJ_ENCODING_INTSET
// 若集合長度小于set_max_listpack_entries時(shí)，存儲為緊湊列表
// 否則存儲為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é)點(diǎn)
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時(shí)，判斷元素長度若小于等于zset_max_listpack_entries，并且最大元素的長度小于等于zset_max_listpack_value

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

使用命令zunion/zinter/zdiff命令（求并集交集差集）時(shí)，判斷元素長度若小于等于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 ...] # 并集計(jì)算
ZINTERSTORE destkey numkeys key [key ...] # 交集計(jì)算

常用場景

排行榜

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

RedisObject

源碼位置：server.h

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

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

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

int：8個(gè)字節(jié)的長整型。字符串值是整型時(shí)，這個(gè)值使用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í)少分配一次空間，刪除時(shí)少釋放一次空間，以及對象的所有數(shù)據(jù)連在一起，尋找方便。而embstr的壞處也很明顯，如果字符串的長度增加需要重新分配內(nèi)存時(shí)，整個(gè)redisObject和sds都需要重新分配空間**，因此redis中的embstr實(shí)現(xiàn)為只讀。
raw：大于44個(gè)字節(jié)的字符串

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

壓縮列表zipList

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

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

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

zipList缺陷

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

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

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

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

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

zipList特性

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

緊湊列表listPack

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

在 Redis5.0 出現(xiàn)了 listpack，目的是替代壓縮列表，其最大特點(diǎn)是 listpack 中每個(gè)節(jié)點(diǎn)不再包含前一個(gè)節(jié)點(diǎn)的長度，壓縮列表每個(gè)節(jié)點(diǎn)正因?yàn)樾枰４媲耙粋€(gè)節(jié)點(diǎn)的長度字段，就會有連鎖更新的隱患。

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

跳表

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

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

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

淘汰策略

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

Redis的LRU實(shí)現(xiàn)

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

Redis的LFU實(shí)現(xiàn)

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

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

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

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

刪除策略

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

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

Redis 的惰性刪除策略由 db.c 文件中的 expireIfNeeded 函數(shù)實(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);
}

定期刪除：定期刪除策略的做法是，每隔一段時(shí)間隨機(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；定期刪除的實(shí)現(xiàn)在 expire.c 文件下的 activeExpireCycle 函數(shù)中，其中隨機(jī)抽查的數(shù)量由 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 定義的，它是寫死在代碼中的，數(shù)值是 20；也就是說，數(shù)據(jù)庫每輪抽查時(shí)，會隨機(jī)選擇 20 個(gè) 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í)行隊(duì)列順序執(zhí)行

使用示例

/**
 * 一次io獲取個(gè)值
 *
 * @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í)行多個(gè)命令，一個(gè)事務(wù)中所有命令都會被序列化。在事務(wù)執(zhí)行過程，會按照順序串行化執(zhí)行隊(duì)列中的命令，其他客戶端提交的命令請求不會插入到事務(wù)執(zhí)行命令序列中。

事務(wù)的命令：

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

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

Redis的持久化

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

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

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

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

1. AOF

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

優(yōu)點(diǎn)：

AOF日志可以實(shí)現(xiàn)更精確的數(shù)據(jù)持久化，每個(gè)寫操作都會被記錄。
在AOF文件中，數(shù)據(jù)可以更好地恢復(fù)，因?yàn)樗４媪怂械膶懖僮鳉v史。
AOF日志適用于需要實(shí)時(shí)恢復(fù)數(shù)據(jù)的場景，如秒級數(shù)據(jù)恢復(fù)要求。

缺點(diǎn)：

AOF日志相對于RDB快照來說，可能會占用更多的磁盤空間，因?yàn)樗怯涗浢總€(gè)寫操作的文本文件。
AOF日志在恢復(fù)大數(shù)據(jù)集時(shí)可能會比RDB快照慢，因?yàn)樾枰饤l執(zhí)行寫操作。

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

2. RDB

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

發(fā)布訂閱

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

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

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

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

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

Redis集群模式

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

主從復(fù)制

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

工作機(jī)制

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

不具備自動容錯(cuò)與恢復(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)力，還會造成一段時(shí)間內(nèi)服務(wù)不可用。這不是一種推薦的方式，更多時(shí)候，我們優(yōu)先考慮哨兵模式。

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

這里的哨兵有兩個(gè)作用

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

然而一個(gè)哨兵進(jìn)程對Redis服務(wù)器進(jìn)行監(jiān)控，可能會出現(xiàn)問題，為此，我們可以使用多個(gè)哨兵進(jìn)行監(jiān)控。各個(gè)哨兵之間還會進(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安裝目錄下有一個(gè)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代表只有兩個(gè)或兩個(gè)以上的哨兵認(rèn)為主服務(wù)器不可用的時(shí)候，才會進(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模式實(shí)現(xiàn)了Redis的分布式存儲，即每臺節(jié)點(diǎn)存儲不同的內(nèi)容，來解決在線擴(kuò)容的問題

Cluster特點(diǎn)

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

工作機(jī)制

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

Cluster模式集群節(jié)點(diǎn)最小配置6個(gè)節(jié)點(diǎn)(3主3從，因?yàn)樾枰霐?shù)以上)，其中主節(jié)點(diǎn)提供讀寫操作，從節(jié)點(diǎn)作為備用節(jié)點(diǎn)，不提供請求，只作為故障轉(zhuǎn)移使用。

Cluster部署

redis.conf配置：

port 7100 # 本示例6個(gè)節(jié)點(diǎn)端口分別為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等六個(gè)節(jié)點(diǎn)
cluster-node-timeout 15000 # 請求超時(shí) 默認(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ù)量，因?yàn)槲覀円还?個(gè)服務(wù)器，這里設(shè)置1個(gè)副本，那么Redis會收到消息，一個(gè)主服務(wù)器有一個(gè)副本從服務(wù)器，那么會計(jì)算得出：三主三從。

Cluster注意點(diǎn)

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

Redis常見問題

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

緩存穿透

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

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

解決方案：

空值緩存：如果一個(gè)查詢的數(shù)據(jù)返回空，仍然把這個(gè)結(jié)果緩存到redis，以緩解數(shù)據(jù)庫的查詢壓力
布隆過濾器：布隆過濾器由一個(gè)很長的二進(jìn)制數(shù)組結(jié)合n個(gè)hash算法計(jì)算出n個(gè)數(shù)組下標(biāo)，將這些數(shù)據(jù)下標(biāo)置為1。在查找數(shù)據(jù)時(shí)，再次通過n個(gè)hash算法計(jì)算出數(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ù)庫的瞬時(shí)并發(fā)壓力會飆升

解決方案：

熱點(diǎn)數(shù)據(jù)永不過期：熱點(diǎn)數(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ù)

緩存雪崩

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

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

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

解決方案：

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

大key問題

概念：redis中存在占用內(nèi)存空間較多的key，其中包含多種情況，如string類型的value值過大，hash類型的所有成員總值過大，zset的成員數(shù)量過大等。大key的具體值的界定，要根據(jù)實(shí)際業(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實(shí)例阻塞，例如使用Del命令刪除key等。
網(wǎng)絡(luò)擁塞：大key在網(wǎng)絡(luò)傳輸中更消耗帶寬，可能造成機(jī)器內(nèi)部網(wǎng)絡(luò)帶寬打滿。
主從同步延遲：大key在redis進(jìn)行主從同步時(shí)也更容易導(dǎo)致同步延遲，影響數(shù)據(jù)一致性。

原因：

業(yè)務(wù)設(shè)計(jì)不合理：在業(yè)務(wù)設(shè)計(jì)上，沒有考慮大數(shù)據(jù)量問題，導(dǎo)致一個(gè)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ù)的時(shí)候，加上 —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實(shí)例，其本身也提供一定的方法能快速定位大key

解決方案：

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

熱key問題

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

現(xiàn)象：

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

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

排查：

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

# redis-cli -p 6379 --hotkeys

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

解決方案：

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

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

總結(jié)

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

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

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

日韩av黄I国产麻豆传媒I国产91av视频在线观看I日韩一区二区三区在线看I美女国产在线I麻豆视频国产在线观看I成人黄色短片

数据库

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

高性能之道

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

rehash

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

1. string

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

常用命令

常用場景

INCR作為主鍵的問題

2. list

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

常用命令

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

常用場景

3. hash

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

常用命令

常用場景

4. set

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

常用命令

常用場景

5. sortedset

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

常用命令

常用場景

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

RedisObject

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

壓縮列表zipList

zipList缺陷

zipList特性

緊湊列表listPack

跳表

淘汰策略

Redis的LRU實(shí)現(xiàn)

Redis的LFU實(shí)現(xiàn)

刪除策略

管道Pipeline

使用示例

事務(wù)

Redis的持久化

1. AOF

2. RDB

發(fā)布訂閱

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

Redis集群模式

主從復(fù)制

工作機(jī)制

主從復(fù)制配置

優(yōu)缺點(diǎn)

哨兵模式

哨兵配置

Cluster模式

工作機(jī)制

Cluster部署

Cluster注意點(diǎn)

Redis常見問題

緩存穿透

緩存擊穿

緩存雪崩

大key問題

熱key問題

總結(jié)