Redis是基于内存数据库，操作效率高，提供丰富的数据结构（Redis底层对数据结构还做了优化），可用作数据库，缓存，消息中间件等。如今广泛用于互联网大厂，面试必考点之一，本文从数据结构，到集群，到常见问题逐步深入了解Redis，看完再也不怕面试官提问！

高性能之道

1. 单线程模型

2. 基于内存操作

3. epoll多路复用模型

4. 高效的数据存储结构

redis的单线程指的是数据处理使用的单线程，实际上它主要包含

1. IO线程：处理网络消息收发

2. 主线程：处理数据读写操作，包括事务、Lua脚本等

3. 持久化线程：执行RDB或AOF时，使用持久化线程处理，避免主线程的阻塞

4. 过期键清理线程：用于定期清理过期键

至于redis为什么使用单线程处理数据，是因为redis基于内存操作，并且有高效的数据类型，它的性能瓶颈并不在CPU计算，主要在于网络IO，而网络IO在后来的版本中也被独立出来了IO线程，因此它能快速处理数据，单线程反而避免了多线程所带来的并发和资源争抢的问题

全局数据存储

Redis底层存储基于全局Hash表，存储结构和Java的HashMap类似（数组+链表方式）

全局数据存储

rehash

Redis 默认使用了两个全局哈希表：哈希表 1 和哈希表 2。一开始，当你刚插入数据时，默认使用哈希表 1，此时的哈希表 2 并没有被分配空间。随着数据逐步增多，Redis 开始执行 rehash

1. 给哈希表 2 分配更大的空间，例如是当前哈希表 1 大小的两倍；

2. 把哈希表 1 中的数据重新进行打散映射到hash表2中；这个过程采用渐进式hash 即拷贝数据时，Redis 仍然正常处理客户端请求，每处理一个请求时，从哈希表 1 中的第一个索引位置开始，顺带着将这个索引位置上的所有 entries 拷贝到哈希表 2 中；等处理下一个请求时，再顺带拷贝哈希表 1 中的下一个索引位置的 entries

3. 释放哈希表 1 的空间。

数据类型

查看存储编码类型：object encoding key

1. string

string是最常用的类型，它的底层存储结构是SDS

string

存储结构

redis的string分三种情况对对象编码，目的是为了节省内存空间：

robj *tryObjectEncodingEx(robj *o, int try_trim)

1. if: value长度小于20字节且可以转换为整数（long类型），编码为OBJ_ENCODING_INT，其中若数字在0到10000之间，还可以使用内存共享的数字对象

2. else if: 若value长度小于OBJ_ENCODING_EMBSTR_SIZE_LIMIT（44字节），编码为OBJ_ENCODING_EMBSTR

3. 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

常用场景

• 简单键值对

• 自增计数器

INCR作为主键的问题

• 缺陷：若数据量大的情况下，大量使用INCR来自增主键会让redis的自增操作频繁，影响redis的正常使用

• 优化：每台服务可以使用INCRBY一次性获取一百或者一千或者多少个id段来慢慢分配，这样能大量减少redis的incr命令所带来的消耗

2. list

list

存储结构

redis的list首先会按紧凑列表存储（listPack），当紧凑列表的长度达到list_max_listpack_size之后，会转换为双向链表

// 1.LPUSH/RPUSH/LPUSHX/RPUSHX这些命令的统一入口
void pushGenericCommand(client *c, int where, int xx)
// 2.追加元素，并尝试转换紧凑列表
void listTypeTryConversionAppend(robj *o, robj **argv, 
int start, int end, beforeConvertCB fn, void *data)
// 3.尝试转换紧凑列表
static void listTypeTryConversionRaw(robj *o, list_conv_type lct,
 robj **argv, int start, int end, beforeConvertCB fn, void *data)
// 4.尝试转换紧凑列表
// 若紧凑列表的长度达到list_max_listpack_size之后，则转换
static void listTypeTryConvertQuicklist(robj *o, int
 shrinking, beforeConvertCB fn, void *data)

当redis进行list元素移除时

// 1.移除list元素的统一入口
void listElementsRemoved(client *c, robj *key, int where,
 robj *o, long count, int signal, int *deleted)
// 2.尝试转换
void listTypeTryConversion(robj *o, list_conv_type lct, beforeConvertCB fn, void *data)
// 3.尝试转换
static void listTypeTryConversionRaw(robj *o, list_conv_type 
lct, robj **argv, int start, int end, beforeConvertCB fn, void *data)
// 4.尝试转换双向链表
// 若双向链表中只剩一个节点，且是压缩节点，则对双向链表转换为紧凑列表
static void listTypeTryConvertQuicklist(robj *o, int 
shrinking, beforeConvertCB fn, void *data)

以下参数可在redis.conf配置

常用命令

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则一直阻塞等待

组合数据结构

组合数据结构

根据list的特性，可以组成实现以下常用的数据结构

• Stack（栈）：LPUSH + LPOP

• Queue（队列）：LPUSH + RPOP

• Blocking MQ（阻塞队列）：LPUSH + BRPOP

redis实现数据结构的意义在于分布式环境的实现

常用场景

• 缓存有序列表结构

• 构建分布式数据结构（栈、队列等）

3. hash

hash

存储结构

redis的hash首先会按紧凑列表存储（listPack），当紧凑列表的长度达到hash_max_listpack_entries或添加的元素大小超过hash_max_listpack_value之后，会转换为Hash表

// 1.添加hash元素
void hsetCommand(client *c)
void hsetnxCommand(client *c)
// 2.尝试转换Hash表
// 若紧凑列表的长度达到hash_max_listpack_entries
// 或添加的元素大小超过hash_max_listpack_value
// 则进行转换
void hashTypeTryConversion(robj *o, robj **argv, int start, int end)
// 3.尝试转换Hash表
void hashTypeConvert(robj *o, int enc)
// 4.转换Hash表
void hashTypeConvertListpack(robj *o, int enc)

以下参数可在redis.conf配置

常用命令

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

set

存储结构

1. redis的set添加元素时，若存储对象是整形数字且集合小于set_max_intset_entries，则存储为OBJ_ENCODING_INTSET，若集合长度小于set_max_listpack_entries时，存储为紧凑列表。否则，存储为Hash表

// 1.添加set元素
void saddCommand(client *c)
// 2.1.创建set表
// 若存储对象是整形数字且集合小于set_max_listpack_entries，则存储为OBJ_ENCODING_INTSET
// 若集合长度小于set_max_listpack_entries时，存储为紧凑列表
// 否则存储为Hash表
robj *setTypeCreate(sds value, size_t size_hint)
// 2.2 尝试转换set表
// 如果编码是OBJ_ENCODING_LISTPACK（紧凑列表），且集合长度大于set_max_listpack_entries
// 或编码是OBJ_ENCODING_INTSET（整形集合），且集合长度大于set_max_intset_entries
// 则进行转换为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 若整形数组添加元素，长度超过set_max_intset_entries，则转换为Hash表
static void maybeConvertIntset(robj *subject)

以下参数可在redis.conf配置

常用命令

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 ...] #交集运算
SINTERSTORE destination key [key ...] #将交集结果存入新集合destination
SUNION key [key ...] #并集运算
SUNIONSTORE destination key [key ...] #将并集结果存入新集合destination
SDIFF key [key ...] #差集运算
SDIFFSTORE destination key [key ...] #将差集结果存入新集合destination

常用场景

• 缓存无序集合

• 需要求交集并集差集的场景

5. sorted set

sortedset

存储结构

根据情况可能创建紧凑列表或跳表

// 1.添加元素
void zaddCommand(client *c)
void zaddGenericCommand(client *c, int flags)
// 2.1 创建元素
// 若集合长度<=zset_max_listpack_entries 并且值的长度<=zset_max_listpack_value，则创建紧凑列表
// 否则创建跳表节点
robj *zsetTypeCreate(size_t size_hint, size_t val_len_hint)
// 2.2 添加元素
// 若集合是紧凑列表，且集合元素超过zset_max_listpack_entries
// 或当前添加的元素长度超过zset_max_listpack_value
// 则将紧凑列表转换为跳表
int zsetAdd(robj *zobj, double score, sds ele, int in_flags, int *out_flags, double *newscore)

以下参数可在redis.conf配置

跳表仅在以下情况转换回压缩列表

1. 使用命令georadius时，判断

元素长度若小于等于zset_max_listpack_entries，并且最大元素的长度小于等于zset_max_listpack_value

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

1. 使用命令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 ...] # 交集计算

常用场景

• 排行榜

底层数据结构

RedisObject

源码位置：server.h

{
   unsigned type:4;//类型 五种对象类型
   unsigned encoding:4;//编码
   void *ptr;//指向底层实现数据结构的指针
   int refcount;//引用计数
   unsigned lru:24;//记录最后一次被命令程序访问的时间
}robj;

• type ：表示对象的类型，占4个比特；目前包括REDIS_STRING(字符串)、REDIS_LIST (列表)、REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。

• encoding：占4个比特，Redis支持的每种类型，都有至少两种内部编码，例如对于字符串，有int、embstr、raw三种编码。通过encoding属性，Redis可以根据不同的使用场景来为对象设置不同的编码，大大提高了Redis的灵活性和效率。以列表对象为例，有紧凑列表和双端链表两种编码方式；如果列表中的元素较少，Redis倾向于使用紧凑列表进行存储，因为紧凑列表占用内存更少，而且比双端链表可以更快载入；当列表对象元素较多时，紧凑列表就会转化为更适合存储大量元素的双端链表。

• ptr：指针指向具体的数据。

• refcount：记录的是该对象被引用的次数，类型为整型。主要用于对象的引用计数和内存回收。Redis中被多次使用的对象(refcount>1)，称为共享对象。Redis为了节省内存，当有一些对象重复出现时，新的程序不会创建新的对象，而是仍然使用原来的对象。这个被重复使用的对象，就是共享对象。目前共享对象仅支持整数值的字符串对象。共享对象只能是整数值的字符串对象，但是5种类型都可能使用共享对象。Redis服务器在初始化时，会创建10000个字符串对象，值分别是0~9999的整数值；

• lru：Redis 对象头中的 lru 字段，在 LRU 算法下和 LFU 算法下使用方式并不相同。

• 在 LRU 算法中，Redis 对象头的 24 bits 的 lru 字段是用来记录 key 的访问时间戳，因此在 LRU 模式下，Redis可以根据对象头中的 lru 字段记录的值，来比较最后一次 key 的访问时间长，从而淘汰最久未被使用的 key。

• 在 LFU 算法中，Redis对象头的 24 bits 的 lru 字段被分成两段来存储，高 16bit 存储 ldt(Last Decrement Time)，低 8bit 存储 logc(Logistic Counter)。

• 一个redisObject对象的大小为16字节：4bit+4bit+24bit+4Byte+8Byte=16Byte

SDS 简单动态字符串(Simple Dynamic String)

typedef char *sds;
struct __attribute__ ((__packed__)) sdshdr5 { // 对应的字符串长度小于 1<<5 32字节
   unsigned char flags; /* 3 lsb of type, and 5 msb of string length intembstr*/
   char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 { // 对应的字符串长度小于 1<<8 256
   uint8_t len; /* used */ //目前字符创的长度 用1字节存储
   uint8_t alloc; //已经分配的总长度 用1字节存储
   unsigned char flags; //flag用3bit来标明类型，类型后续解释，其余5bit目前没有使用 embstr raw
   char buf[]; //柔性数组，以'\0'结尾
};
struct __attribute__ ((__packed__)) sdshdr16 { // 对应的字符串长度小于 1<<16
   uint16_t len; /*已使用长度，用2字节存储*/
   uint16_t alloc; /* 总长度，用2字节存储*/
   unsigned char flags; /* 3 lsb of type, 5 unused bits */
   char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 { // 对应的字符串长度小于 1<<32
   uint32_t len; /*已使用长度，用4字节存储*/
   uint32_t alloc; /* 总长度，用4字节存储*/
   unsigned char flags;/* 低3位存储类型, 高5位预留 */
   char buf[];/*柔性数组，存放实际内容*/
};
struct __attribute__ ((__packed__)) sdshdr64 { // 对应的字符串长度小于 1<<64
   uint64_t len; /*已使用长度，用8字节存储*/
   uint64_t alloc; /* 总长度，用8字节存储*/
   unsigned char flags; /* 低3位存储类型, 高5位预留 */
   char buf[];/*柔性数组，存放实际内容*/
};

字符串类型的内部编码有3种

• int：8个字节的长整型。字符串值是整型时，这个值使用long整型表示。

• embstr：**<=44字节的字符串。embstr与raw都使用redisObject和sds保存数据，区别在于，embstr的使用只分配一次内存空间（因此redisObject和sds是连续的），而raw需要分配两次内存空间（分别为redisObject和sds分配空间）。因此与raw相比，embstr的好处在于创建时少分配一次空间，删除时少释放一次空间，以及对象的所有数据连在一起，寻找方便。而embstr的坏处也很明显，如果字符串的长度增加需要重新分配内存时，整个redisObject和sds都需要重新分配空间**，因此redis中的embstr实现为只读。

• raw：大于44个字节的字符串

embstr和raw进行区分的长度，是44；是因为redisObject的长度是16字节，sds的长度是4+字符串长度；因此当字符串长度是44时，embstr的长度正好是16+4+44 =64，jemalloc正好可以分配64字节的内存单元。

压缩列表zipList

ziplist 被设计成一种内存紧凑型的数据结构，占用一块连续的内存空间，不仅可以利用 CPU 缓存，而且会针对不同长度的数据，进行相应编码，这种方法可以有效地节省内存开销。

ziplist 是一个特殊双向链表，不像普通的链表使用前后指针关联在一起，它是存储在连续内存上的。

/* 创建一个空的 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;
}

ziplist

1. zlbytes: 32 位无符号整型，记录 ziplist 整个结构体的占用空间大小。当然了也包括 zlbytes 本身。这个结构有个很大的用处，就是当需要修改 ziplist 时候不需要遍历即可知道其本身的大小。这和SDS中记录字符串的长度有相似之处。

2. zltail: 32 位无符号整型, 记录整个 ziplist 中最后一个 entry 的偏移量。所以在尾部进行 POP 操作时候不需要先遍历一次。

3. zllen: 16 位无符号整型, 记录 entry 的数量， 所以只能表示 2^16。但是 Redis 作了特殊的处理：当实体数超过 2^16 ,该值被固定为 2^16 - 1。所以这种时候要知道所有实体的数量就必须要遍历整个结构了。

4. entry: 真正存数据的结构。

5. zlend: 8 位无符号整型, 固定为 255 (0xFF)。为 ziplist 的结束标识。

zipList缺陷

ziplist 在更新或者新增时候，如空间不够则需要对整个列表进行重新分配。当新插入的元素较大时，可能会导致后续元素的 prevlen 占用空间都发生变化，从而引起「连锁更新」问题，导致每个元素的空间都要重新分配，造成访问压缩列表性能的下降。

ziplist 节点的 prevlen 属性会根据前一个节点的长度进行不同的空间大小分配：

• 如果前一个节点的长度小于 254 字节，那么 prevlen 属性需要用 1 字节的空间来保存这个长度值。

• 如果前一个节点的长度大于等于 254 字节，那么 prevlen 属性需要用 5 字节的空间来保存这个长度值。

假设有这样的一个 ziplist，每个节点都是等于 253 字节的。新增了一个大于等于 254 字节的新节点，由于之前的节点 prevlen 长度是 1 个字节。

为了要记录新增节点的长度所以需要对节点 1 进行扩展，由于节点 1 本身就是 253 字节，再加上扩展为 5 字节的 pervlen 则长度超过了 254 字节，这时候下一个节点又要进行扩展了

zipList

zipList特性

1. ziplist 为了节省内存，采用了紧凑的连续存储。所以在修改操作下并不能像一般的链表那么容易，需要从新分配新的内存，然后复制到新的空间。

2. ziplist 是一个双向链表，可以在时间复杂度为 O(1) 从下头部、尾部进行 pop 或 push。

3. 新增或更新元素可能会出现连锁更新现象。

4. 不能保存过多的元素，否则查询效率就会降低。

紧凑列表listPack

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

在 Redis5.0 出现了 listpack，目的是替代压缩列表，其最大特点是 listpack 中每个节点不再包含前一个节点的长度，压缩列表每个节点正因为需要保存前一个节点的长度字段，就会有连锁更新的隐患。

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

1. listpack 中每个节点不再包含前一个节点的长度，避免连锁更新的隐患发生。

2. listpack 相对于 ziplist，没有了指向末尾节点地址的偏移量，解决 ziplist 内存长度限制的问题。但一个 listpack 最大内存使用不能超过 1GB。

跳表

数组：查询快，插入删除慢 链表：查询慢，插入删除快 跳表：跳表是基于链表的一个优化，在链表的插入删除快的特性之上，也增加了它的查询效率。它是将有序链表改造为支持折半查找算法，它的插入、删除、查询都很快

跳表

跳表缺陷：需要额外空间来建立索引层，以空间换时间，因此zset一开始是以紧凑列表存储，后续才会转换为跳表

• 跳表的创建（添加元素时）

1. 当前zset不存在时，若添加元素时集合长度达到zset_max_listpack_entries，或添加的最后一个元素的大小超过zset_max_listpack_value，则直接创建跳表，跳表头结点创建最大层数（ZSKIPLIST_MAXLEVEL：32）的索引，并插入跳表当前添加的元素

2. 当前zset存在时，判断若元素长度超过zset_max_listpack_entries，则将紧凑列表转换为跳表，跳表头结点创建最大层数（ZSKIPLIST_MAXLEVEL：32）的索引，然后把其他元素依次插入跳表

• 跳表的查询 从起始节点开始，通过多级索引进行折半查找，最终找到需要的数据

• 跳表的插入 先通过折半查找找到节点对应要插入的链表位置，然后通过随机得到一个要插入的节点的索引层数，然后插入节点，并构建对应的多级索引

• 跳表的删除 先通过折半查找找到要删除的节点的链表位置，删除节点，并删除对应的多级索引

淘汰策略

1. noeviction（默认策略）：不会删除任何数据，拒绝所有写入操作并返回客户端错误消息（error）OOM command not allowed when used memory，此时 Redis 只响应删和读操作；

2. allkeys-lru：从所有 key 中使用 LRU（Least Recently Used）算法进行淘汰（LRU 算法：最近最少使用算法）；

3. allkeys-lfu：从所有 key 中使用 LFU（Least Frequently Used）算法进行淘汰（LFU 算法：最不常用算法，根据使用频率计算，4.0 版本新增）；

4. volatile-lru：从设置了过期时间的 key 中使用 LRU 算法进行淘汰；

5. volatile-lfu：从设置了过期时间的 key 中使用 LFU 算法进行淘汰；

6. allkeys-random：从所有 key 中随机淘汰数据；

7. volatile-random：从设置了过期时间的 key 中随机淘汰数据；

8. volatile-ttl：在设置了过期时间的key中，淘汰过期时间剩余最短的。

Redis的LRU实现

由于Redis 主要运行在单个线程中，它采用的是一种近似的 LRU 算法，而不是传统的完全 LRU 算法（没有把所有key组织为链表）。这种实现方式在保证性能的同时，仍然能够有效地识别并淘汰最近最少使用的键。当 Redis 进行内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值（此值可配置），然后淘汰最久没有使用的那个。

edis的LFU实现

Redis 在访问 key 时，对 logc进行变化：

• 先按照上次访问距离当前的时长，来对 logc 进行衰减；

• 再按照一定概率增加 logc 的值

redis.conf 提供了两个配置项，用于调整 LFU 算法从而控制 logc 的增长和衰减：

• lfu-decay-time 用于调整 logc 的衰减速度，它是一个以分钟为单位的数值，默认值为1，lfu-decay-time 值越大，衰减越慢；

• lfu-log-factor 用于调整 logc 的增长速度，lfu-log-factor 值越大，logc 增长越慢

删除策略

redis的key过期删除策略采用惰性删除+定期删除实现：

• 惰性删除：不主动删除过期键，每次从数据库访问 key 时，都检测 key 是否过期，如果过期则删除该 key

Redis 的惰性删除策略由 db.c 文件中的 expireIfNeeded 函数实现，代码如下：

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);
}

• 定期删除：定期删除策略的做法是，每隔一段时间随机从数据库中取出一定数量的 key 进行检查，并删除其中的过期key

在 Redis 中，默认每秒进行 10 次过期检查一次数据库，此配置可通过 Redis 的配置文件 redis.conf 进行配置，配置键为 hz 它的默认值是 hz 10；定期删除的实现在 expire.c 文件下的 activeExpireCycle 函数中，其中随机抽查的数量由 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 定义的，它是写死在代码中的，数值是 20；也就是说，数据库每轮抽查时，会随机选择 20 个 key 判断是否过期。

管道Pipeline

redis提供pipeline，可以让客户端一次发送一连串的命令给服务器执行，然后再返回执行结果

• 应用场景：

• 需要多次执行一连串的redis命令，且命令之间没有依赖的场景

• 缺陷：

1. 不保证原子性，pipeline拿到命令只管串行执行，不管执行成功与否，也没有回滚机制

2. pipeline在执行过程中无法知道执行结果，只有全部执行结束才会返回全部结果

3. pipeline也不宜一次性发送过多命令，尽管节省了IO，但在redis端也依然会进行执行队列顺序执行

使用示例

/**
 * 一次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.通过管道执行命令
                Response<String> resp = pipeline.get(key);
                respList.add(resp);
            }
            // 3.统一提交命令
            pipeline.sync();
            for (Response<String> resp : respList) {
                // 4.遍历获取全部的命令执行返回结果
                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;
        }
    });
}

事务

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

事务的命令：

• MULTI ：开启事务，redis会将后续的命令逐个放入队列中，然后使用EXEC命令来原子化执行这个命令系列。

• EXEC：执行事务中的所有操作命令。

• DISCARD：取消事务，放弃执行事务块中的所有命令。

• WATCH：监视一个或多个key,如果事务在执行前，这个key(或多个key)被其他命令修改，则事务被中断，不会执行事务中的任何命令。

• UNWATCH：取消WATCH对所有key的监视。

redis事务在编译错误可以回滚，而运行时错误不能回滚，简单说，redis事务不支持回滚

Redis的持久化

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

• RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；

• AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。AOF类似MySQL的binlog

其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。

如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库

1. AOF

AOF日志是一种追加式持久化方式，它记录了每个写操作命令，以追加的方式将命令写入AOF文件。通过重新执行AOF文件中的命令，可以重建出数据在内存中的状态。AOF日志提供了更精确的持久化，适用于需要更高数据安全性和实时性的场景。

优点：

• AOF日志可以实现更精确的数据持久化，每个写操作都会被记录。

• 在AOF文件中，数据可以更好地恢复，因为它保存了所有的写操作历史。

• AOF日志适用于需要实时恢复数据的场景，如秒级数据恢复要求。

缺点：

• AOF日志相对于RDB快照来说，可能会占用更多的磁盘空间，因为它是记录每个写操作的文本文件。

• AOF日志在恢复大数据集时可能会比RDB快照慢，因为需要逐条执行写操作。

根据不同的需求，可以选择RDB快照、AOF日志或两者结合使用。你可以根据数据的重要性、恢复速度要求以及磁盘空间限制来选择合适的持久化方式。有时候，也可以通过同时使用两种方式来提供更高的数据保护级别。

2. RDB

RDB快照是一种全量持久化方式，它会周期性地将内存中的数据以二进制格式保存到磁盘上的RDB文件。RDB文件是一个经过压缩的二进制文件，包含了数据库在某个时间点的数据快照。RDB快照有助于实现紧凑的数据存储，适合用于备份和恢复。

优点：

• RDB快照在恢复大数据集时速度较快，因为它是全量的数据快照。

• 由于RDB文件是压缩的二进制文件，它在磁盘上的存储空间相对较小。

• 适用于数据备份和灾难恢复。

缺点：

• RDB快照是周期性的全量持久化，可能导致某个时间点之后的数据丢失。

• 在保存快照时，Redis服务器会阻塞，可能对系统性能造成影响。

发布订阅

Redis提供了基于“发布/订阅”模式的消息机制。此种模式下，消息发布者和订阅者不进行直接通信，发布者客户端向指定的频道（channel） 发布消息，订阅该频道的每个客户端都可以收到该消息。结构如下：

发布订阅

该消息通信模式可用于模块间的解耦

# 订阅消息 
subscribe channel [channel ...]
# 发布消息
publish channel "hello"
# 按模式订阅频道
psubscribe pattern [pattern ...]
# 退订频道
unsubscribe pattern [pattern ...]
# 按模式退订频道
punsubscribe pattern [pattern ...]

Redis发布订阅与消息队列的区别

1. 消息队列可以支持多种消息协议，但 Redis 没有提供对这些协议的支持；

2. 消息队列可以提供持久化功能，但 Redis无法对消息持久化存储，一旦消息被发送，如果没有订阅者接收，那么消息就会丢失；

3. 消息队列可以提供消息传输保障，当客户端连接超时或事务回滚等情况发生时，消息会被重新发送给客户端，Redis 没有提供消息传输保障。

4. 发布订阅消息量过多过频繁，也会占用redis的内存空间，挤占业务逻辑key的空间（可以通过放到不同redis解决）

Redis集群模式

redis集群主要有三种模式：主从复制，哨兵模式和Cluster

主从复制

主从复制模式中包含一个主数据库实例（master）与一个或多个从数据库实例（slave）

主从复制

工作机制

1. slave启动后，向master发送SYNC命令，master接收到SYNC命令后通过bgsave保存快照，并使用缓冲区记录保存快照这段时间内执行的写命令

2. master将保存的快照文件发送给slave，并继续记录执行的写命令

3. slave接收到快照文件后，加载快照文件，载入数据

4. master快照发送完后开始向slave发送缓冲区的写命令，slave接收命令并执行，完成复制初始化

5. master每次执行一个写命令都会同步发送给slave，保持master与slave之间数据的一致性

主从复制配置

replicaof 127.0.0.1 6379 # master的ip，port 
masterauth 123456 # master的密码 
replica-serve-stale-data no # 如果slave无法与master同步，设置成slave不可读，方便监控脚本发现问题

优缺点

优点：

1. master能自动将数据同步到slave，可以进行读写分离，分担master的读压力

2. master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求

缺点：

1. 不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复

2. master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题

3. 难以支持在线扩容，Redis的容量受限于单机配置

哨兵模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

哨兵模式

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

哨兵模式

哨兵配置

1.主从服务器配置

# 使得Redis服务器可以跨网络访问
bind 0.0.0.0
# 设置密码
requirepass "123456"
# 指定主服务器，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置
slaveof 192.168.11.128 6379
# 主服务器密码，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置
masterauth 123456

2.配置哨兵 在Redis安装目录下有一个sentinel.conf文件，copy一份进行修改

# 禁止保护模式
protected-mode no
# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，
可以自定义，192.168.11.128代表监控的主服务器，6379代表端口，2
代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

3.启动服务器和哨兵

# 启动Redis服务器进程
./redis-server ../redis.conf
# 启动哨兵进程
./redis-sentinel ../sentinel.conf

Cluster模式

哨兵模式解决了主从复制不能自动故障转移，达不到高可用的问题，但还是存在难以在线扩容，Redis容量受限于单机配置的问题。

Cluster模式实现了Redis的分布式存储，即每台节点存储不同的内容，来解决在线扩容的问题

Cluster模式

Cluster特点

1. 无中心结构：所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽

2. 分布式存储：Redis Cluster将数据分散存储在多个节点上，每个节点负责存储和处理其中的一部分数据。这种分布式存储方式允许集群处理更大的数据集，并提供更高的性能和可扩展性。

3. 数据复制：每个主节点都有一个或多个从节点，从节点会自动复制主节点上的数据。数据复制可以提供数据的冗余备份，并在主节点故障时自动切换到从节点，以保证系统的可用性。

4. 自动分片和故障转移：Redis Cluster会自动将数据分片到不同的节点上，同时提供自动化的故障检测和故障转移机制。当节点发生故障或下线时，集群会自动检测并进行相应的故障转移操作（投票机制：节点的fail是通过集群中超过半数的节点检测失效时才生效），以保持数据的可用性和一致性。

5. 节点间通信：Redis Cluster中的节点之间通过内部通信协议进行交互，共同协作完成数据的分片、复制和故障转移等操作。节点间通信的协议和算法确保了数据的正确性和一致性。

工作机制

1. 在Redis的每个节点上，都有一个插槽（slot），取值范围为0-16383

2. 当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作

3. 为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点

4. 当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了

Cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

Cluster部署

redis.conf配置：

port 7100 # 本示例6个节点端口分别为7100,7200,7300,7400,7500,7600 
daemonize yes # r后台运行 
pidfile /var/run/redis_7100.pid # pidfile文件对应7100,7200,7300,7400,7500,7600 
cluster-enabled yes # 开启集群模式 
masterauth passw0rd # 如果设置了密码，需要指定master密码
cluster-config-file nodes_7100.conf # 集群的配置文件，同样对应7100,7200等六个节点
cluster-node-timeout 15000 # 请求超时 默认15秒，可自行设置 

启动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：表示副本数量，也就是从服务器数量，因为我们一共6个服务器，这里设置1个副本，那么Redis会收到消息，一个主服务器有一个副本从服务器，那么会计算得出：三主三从。

Cluster注意点

• 数据分片和哈希槽：Redis Cluster 使用数据分片和哈希槽来实现数据的分布式存储。每个节点负责一部分哈希槽，确保数据在集群中均匀分布。在设计应用程序时，需要考虑数据的分片规则和哈希槽的分配，以便正确地将数据路由到相应的节点。

• 节点的故障和扩展：Redis Cluster 具有高可用性和可伸缩性。当节点发生故障或需要扩展集群时，需要正确处理节点的添加和删除。故障节点会被自动检测和替换，而添加节点需要进行集群重新分片的操作。

• 客户端的重定向：Redis Cluster 在处理键的读写操作时可能会返回重定向错误（MOVED 或 ASK）。应用程序需要正确处理这些错误，根据重定向信息更新路由表，并将操作重定向到正确的节点上。

• 数据一致性的保证：由于 Redis Cluster 使用异步复制进行数据同步，所以在节点故障和网络分区恢复期间，可能会发生数据不一致的情况。应用程序需要考虑数据一致性的问题，并根据具体业务需求采取适当的措施。

• 客户端连接的负载均衡：在连接 Redis Cluster 时，应该使用适当的负载均衡策略，将请求均匀地分布到集群中的各个节点上，以避免单个节点过载或出现热点访问。

• 事务和原子性操作：Redis Cluster 中的事务操作只能在单个节点上执行，无法跨越多个节点。如果需要执行跨节点的原子性操作，可以使用 Lua 脚本来实现。

• 集群监控和管理：对 Redis Cluster 进行监控和管理是很重要的。可以使用 Redis 自带的命令行工具或第三方监控工具来监控集群的状态、性能指标和节点健康状况，以及执行管理操作，如节点添加、删除和重新分片等。

Redis常见问题

当使用redis作为数据库的缓存层时，会经常遇见这几种问题，以下是这些问题的描述以及对应的解决方案

缓存穿透

概念：请求过来之后，访问不存在的数据，redis中查询不到，则穿透到数据库进行查询

现象：大量穿透访问造成redis命中率下降，数据库压力飙升

解决方案：

1. 空值缓存：如果一个查询的数据返回空，仍然把这个结果缓存到redis，以缓解数据库的查询压力

2. 布隆过滤器：布隆过滤器由一个很长的二进制数组结合n个hash算法计算出n个数组下标，将这些数据下标置为1。在查找数据时，再次通过n个hash算法计算出数组下标，如果这些下标的值为1，表示该值可能存在(存在hash冲突的原因)，如果为0，则表示该值一定不存在。因此，布隆过滤器中存在，数据不一定存在，但若布隆过滤器中不存在，则数据一定不存在，依靠此特性可以过滤掉一定的空值数据

缓存击穿

概念：请求访问的key对应的数据存在，但key在redis中已过期，则访问击穿到数据库

现象：若大批请求中访问的key均过期，那么redis正常运行，但数据库的瞬时并发压力会飙升

解决方案：

1. 热点数据永不过期：热点数据可以一直在redis中请求到，不会过期，则不会出现缓存击穿现象

2. 使用互斥锁：当访问redis的key过期之后，在请求数据库重新加载数据之前，先获取互斥锁（单进程可以synchronized，分布式使用分布式锁），获取到锁的请求加载数据并放进缓存，没有获取到锁的请求可以进行重试，重试之后便能重新获取到redis中的数据

缓存雪崩

概念：同一时间大批量key同时过期，造成瞬时对这些key的请求全部击穿到数据库；或redis服务不可用（宕机）

缓存雪崩与缓存击穿的区别在于：缓存击穿是单个热点数据过期，而缓存雪崩是大批量热点数据过期

现象：大量热点数据的查询请求会增加数据库瞬时压力

解决方案：

1. 设置随机过期时间：避免大量key的过期时间过于集中，可以通过随机算法均匀分布key的过期时间点

2. 热点数据永不过期：可以和缓存击穿一样让热点数据不过期

3. 搭建高可用redis服务：针对redis服务不可用，可以对redis进行分布式部署，并实现故障转移（如redis哨兵模式）

4. 控制系统负载：实现熔断限流或服务降级，让系统负载在可控范围内

大key问题

概念：redis中存在占用内存空间较多的key，其中包含多种情况，如string类型的value值过大，hash类型的所有成员总值过大，zset的成员数量过大等。大key的具体值的界定，要根据实际业务情况判断。

现象：大key对业务会产生多方面的影响：

1. redis内存占用过高：大key可能导致内存空间不足，从而触发redis的内存淘汰策略。

2. 阻塞其他操作：对某些大key操作可能导致redis实例阻塞，例如使用Del命令删除key等。

3. 网络拥塞：大key在网络传输中更消耗带宽，可能造成机器内部网络带宽打满。

4. 主从同步延迟：大key在redis进行主从同步时也更容易导致同步延迟，影响数据一致性。

原因：

1. 业务设计不合理：在业务设计上，没有考虑大数据量问题，导致一个key存储了大量的数据

2. 未定期清理数据：没有合适的删除机制或过期机制，造成value不断增加

3. 业务逻辑问题：业务逻辑bug导致key的value只增不减

排查：

1. SCAN命令：通过redis的scan命令逐步遍历数据库中的所有key，通过比较大小，站到占用内存较多的大key

2. bigkeys参数：使用redis-cli命令客户端，连接Redis服务的时候，加上 —bigkeys 参数，可以扫描每种数据类型数量最大的key。

redis-cli -h 127.0.0.1 -p 6379 —bigkeys

1. Redis RDB Tools工具：使用开源工具Redis RDB Tools，分析RDB文件，扫描出Redis大key。

例如：输出占用内存大于1kb，排名前3的keys。

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

1. Redis云商提供的工具：现在基本使用云商提供的redis实例，其本身也提供一定的方法能快速定位大key

解决方案：

1. 大key拆分：可以根据实际业务场景，拆分多个小key，确保value大小在合理范围内

2. 大key清理：redis4.0之后可以使用unlink命令以非阻塞方式安全的删除大key

3. 合理设置过期时间：设置过期时间可以让数据自动失效清理，一定程度避免大key的长时间存在。

4. 合理设置淘汰策略：redis中使用合适的淘汰策略，能在redis内存不足时，淘汰数据，防止大key长时间占用内存

5. 数据压缩：使用string类型，可以对value通过压缩算法进行压缩。可以用gzip，bzip2等常用算法压缩和解压。需要注意的是，这种方法会增加CPU的开销以及处理的响应延迟，同时也增加逻辑代码的复杂性

热key问题

概念：redis中某个key的访问次数比较多且明显多于其他key，则这个key被定义为热key

现象：

1. Redis的CPU占用过高，效率降低，影响其他业务

2. 若热key请求超出redis处理能力，会造成redis宕机，请求击穿到数据库，影响数据库性能

原因：某个热点数据访问量暴增，如重大的热搜事件、参与秒杀的商品

排查：

1. hotkeys参数：Redis 4.0.3 版本中新增了 hotkeys 参数，该参数能够返回所有 key 的被访问次数（使用前提：redis淘汰策略设置为lfu）

redis-cli -p 6379 --hotkeys

1. MONITOR命令：MONITOR 命令是 Redis 提供的一种实时查看 Redis 的所有操作的方式，可以用于临时监控 Redis 实例的操作情况，包括读写、删除等操作。*该命令对 Redis 性能的影响比较大，因此禁止长时间开启 MONITOR（生产环境中建议谨慎使用该命令）*

2. 根据业务情况分析：根据实际业务场景分析，可以提前预估可能出现的热key现象，比如秒杀活动的商品数据等

3. 云商redis工具：云服务一般会提供redis的热key分析工具，合理利用，发现热key

解决方案：

1. 热key拆分：设计一定的规则，给热key增加后缀，变成多个key，结合Redis Cluster模式，能分散到不同的节点。会带来业务复杂度，以及可能产生数据一致性问题

2. 二级缓存：在应用和redis中间再引入一层缓存层，如本地缓存，来缓解redis压力

3. 热key单独集群部署：针对热key单独做集群部署，和其他业务key进行隔离