修🐶的家

总有一条蜿蜒在童话镇里七彩的河

  menu
50 文章
0 浏览
0 当前访客
ღゝ◡╹)ノ❤️

Redis

1. Redis为什么这么快

1、完全基于内存,绝大部分请求是纯粹的内存操作,非常快速。数据存在内存中,类似于 HashMap,HashMap 的优势就是查找和操作的时间复杂度都是O(1);

2、数据结构简单,对数据操作也简单,Redis 中的数据结构是专门进行设计的;

3、采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗 CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现死锁而导致的性能消耗;

4、使用多路 I/O 复用模型,非阻塞 IO;

5、使用底层模型不同,它们之间底层实现方式以及与客户端之间通信的应用协议不一样,Redis 直接自己构建了 VM 机制 ,因为一般的系统调用系统函数的话,会浪费一定的时间去移动和请求;

2. Redis的基本数据类型

数据类型可以存储的值操作应用场景
STRING字符串、整数或者浮点数对整个字符串或者字符串的其中一部分执行操作
对整数和浮点数执行自增或者自减操作
做简单的键值对缓存
LIST列表从两端压入或者弹出元素
对单个或者多个元素进行修剪,
只保留一个范围内的元素
存储一些列表型的数据结构,类似粉丝列表、文章的评论列表之类的数据
SET无序集合添加、获取、移除单个元素
检查一个元素是否存在于集合中
计算交集、并集、差集
从集合里面随机获取元素
交集、并集、差集的操作,比如交集,可以把两个人的粉丝列表整一个交集
HASH包含键值对的无序散列表添加、获取、移除单个键值对
获取所有键值对
检查某个键是否存在
结构化的数据,比如一个对象
ZSET有序集合添加、获取、删除元素
根据分值范围或者成员来获取元素
计算一个键的排名
去重但可以排序,如获取排名前几名的用户

3. Zset的底层实现

跳表。https://www.jianshu.com/p/dc252b5efca6

4. 如何保证数据库和Redis的数据一致性?

更新的时候,先更新数据库,然后再删除缓存。

读的时候,先读缓存;如果没有的话,就读数据库,同时将数据放入缓存,并返回响应。

如果先更新了数据库,删除缓存的时候失败了怎么办?那么数据库中是新数据,缓存中是老数据,数据出现不一致了。

改进方案:

先删除缓存,后更新数据库。因为即使后面更新数据库失败了,缓存是空的,读的时候会从数据库中重新拉,虽然都是旧数据,但数据是一致的。

所以方案就变成了:

更新的时候,先删除缓存,然后再更新数据库。

读的时候,先读缓存;如果没有的话,就读数据库,同时将数据放入缓存,并返回响应。

到这里是不是问题就得到了彻底的解决了呢?其实并没有,在高并发的场景下,会出现这样的情况:数据发生了变更,先删除了缓存,然后去修改数据库。此时还没来得及修改,一个请求过来了,去读缓存,发现缓存空了,去读数据库,读到了准备修改前的旧数据,并且把旧数据放到了缓存。随后,数据变更程序完成了数据库的修改。那么完了,这个时候发生数据不一致了......

使用队列

遇到这种情况,可以用队列的去解决这个问,创建几个队列,如20个,根据商品的ID去做hash值,然后对队列个数取摸,当有数据更新请求时,先把它丢到队列里去,当更新完后在从队列里去除,如果在更新的过程中,遇到以上场景,先去缓存里看下有没有数据,如果没有,可以先去队列里看是否有相同商品ID在做更新,如果有也把查询的请求发送到队列里去,然后同步等待缓存更新完成。

这里有一个优化点,如果发现队列里有一个查询请求了,那么就不要放新的查询操作进去了,用一个while(true)循环去查询缓存,循环个200MS左右,如果缓存里还没有则直接取数据库的旧数据,一般情况下是可以取到的。

5.redis了解吗

Redis 是一个开源的使用ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库

6. redis持久化机制

持久化就是把内存的数据写到磁盘中去,防止服务宕机了内存数据丢失。

Redis 提供两种持久化机制 RDB(默认) 和 AOF 机制:

RDB:是Redis DataBase缩写快照

RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中,对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

截屏2023052923.50.25.png

优点:

· 1、只有一个文件 dump.rdb,方便持久化。

· 2、容灾性好,一个文件可以保存到安全的磁盘。

· 3、性能最大化,fork 子进程来完成写操作,让主进程继续处理命令,所以是 IO 最大化。使用单独子进程来进行持久化,主进程不会进行任何 IO 操作,保证了 redis 的高性能

· 4.相对于数据集大时,比 AOF 的启动效率更高。

缺点:

· 1、数据安全性低。RDB 是间隔一段时间进行持久化,如果持久化之间 redis 发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)

AOF(Append-only file)持久化方式: 是指所有的命令行记录以 redis 命令请求协议的格式完全持久化存储)保存为 aof 文件。

AOF:持久化

AOF持久化(即Append Only File持久化),则是将Redis执行的每次写命令记录到单独的日志文件中,当重启Redis会重新将持久化的日志中文件恢复数据。

当两种方式同时开启时,数据恢复Redis会优先选择AOF恢复。

截屏2023052923.50.42.png

优点:

· 1、数据安全,aof 持久化可以配置 appendfsync 属性,有 always,每进行一次 命令操作就记录到 aof 文件中一次。

设置为always时,会极大消弱Redis的性能,因为这种模式下每次write后都会调用fsync(Linux为调用fdatasync)。

如果设置为no,则write后不会有fsync调用,由操作系统自动调度刷磁盘,性能是最好的。

everysec为最多每秒调用一次fsync,这种模式性能并不是很糟糕,一般也不会产生毛刺,这归功于Redis引入了BIO线程,所有fsync操作都异步交给了BIO线程。

· 2、通过 append 模式写文件,即使中途服务器宕机,可以通过 redis-check-aof 工具解决数据一致性问题。

· 3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前(文件过大时会对命令进行合并重写),可以删除其中的某些命令(比如误操作的 flushall))

缺点:

· 1、AOF 文件比 RDB 文件大,且恢复速度慢。

· 2、数据集大的时候,比 rdb 启动效率低。

优缺点是什么?

· AOF文件比RDB更新频率高,优先使用AOF还原数据。

· AOF比RDB更安全也更大

· RDB性能比AOF好

· 如果两个都配了优先加载AOF

7. redis是单线程的么

· Redis 确实是单线程模型,指的是执行 Redis 命令的核心模块是单线程的,而不是整个 Redis 实例就一个线程,Redis 其他模块还有各自模块的线程的。一般来说 Redis 的瓶颈并不在 CPU,而在内存和网络。如果要使用 CPU 多核,可以搭建多个 Redis 实例来解决。

· Theaded IO 指的是在网络 IO 处理方面上了多线程,如网络数据的读写和协议解析等,需要注意的是,执行命令的核心模块还是单线程的。

8. 哨兵作用

哨兵是redis集群架构中非常重要的一个组件,主要功能如下:

· 集群监控:负责监控redis master和slave进程是否正常工作

· 消息通知:如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员

· 故障转移:如果master node挂掉了,会自动转移到slave node上

· 配置中心:如果故障转移发生了,通知client客户端新的master地址

9. 问哨兵一般几个节点?为什么奇数个

选举

10. redis一次性获取多条消息的命令

mget,pipeline,lua

11. redis缓存雪崩和缓存击穿、缓存穿透

· 缓存穿透:key对应的数据在数据源并不存在,每次针对此key的请求从缓存获取不到,请求都会到数据源,从而可能压垮数据源。比如用一个不存在的用户id获取用户信息,不论缓存还是数据库都没有,若黑客利用此漏洞进行攻击可能压垮数据库。

解决方案:如果一个查询返回的数据为空(不管是数据不存在,还是系统故障),我 们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

· 缓存击穿:key对应的数据存在,但在redis中过期,此时若有大量并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案:SETNX

setnx方式

后来发现有setnx的原子操作命令,锁存在不能设置值,返回0;锁不存在,则设置锁,返回1;

加锁:jedis.setnx(lock, 1)

并发处理:

while(jedis.setnx(lock,1)==0){

Thread.sleep(300);
}

执行业务代码;

jedis.del(lock);

释放锁:执行完业务代码之后,释放redis锁,jedis.del(lock)

问题:当进程执行出现问题,锁未释放,则其他进程永远处于阻塞状态,出现死锁。

防止死锁:加锁时带上时间戳,setnx(lock, 时间戳+超时时间)

while(jedis.setnx(lock,now+超时时间)==0){

if(jedis.get(lock)<now){

jedis.del(lock);

jedis.setnx(lock,now+超时时间);

break;
}else{

Thread.sleep(300);
}
}

执行业务代码;

jedis.del(lock);
· 缓存雪崩:当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,也会给后端系统(比如DB)带来很大压力。

解决方案:在原有的失效时间基础上增加一个随机值

12.Redis集群最大节点个数是多少?

16384个

13. redis 主从复制的核心原理

当启动一个 slave node 的时候,它会发送一个 PSYNC 命令给 master node。

如果这是 slave node 初次连接到 master node,那么会触发一次全量复制。此时 master 会启动一个后台线程,开始生成一份 RDB 快照文件,同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB文件生成完毕后, master会将这个RDB发送给 slave,slave 会先写入本地磁盘,然后再从本地磁盘加载到内存中,接着 master 会将内存中缓存的写命令发送到 slave,slave 也会同步这些数据。slave node 如果跟 master node 有网络故障,断开了连接,会自动重连,连接之后 master node 仅会复制给 slave 部分缺少的数据。

截屏2023052923.51.03.png

缺点

所有的slave节点数据的复制和同步都由master节点来处理,会照成master节点压力太大,使用主从从结构来解决

13.Redis事务的概念

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

总结说:redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

· WATCH 命令是一个乐观锁,可以为 Redis 事务提供 check-and-set (CAS)行为。 可以监控一个或多个键,一旦其中有一个键被修改(或删除),之后的事务就不会执行,监控一直持续到EXEC命令。

· MULTI命令用于开启一个事务,它总是返回OK。 MULTI执行之后,客户端可以继续向服务器发送任意多条命令,这些命令不会立即被执行,而是被放到一个队列中,当EXEC命令被调用时,所有队列中的命令才会被执行。

· EXEC:执行所有事务块内的命令。返回事务块内所有命令的返回值,按命令执行的先后顺序排列。 当操作被打断时,返回空值 nil 。

14. Redis对过期的数据怎么处理呢?

除了缓存服务器自带的缓存失效策略之外(Redis默认的有6中策略可供选择),我们还可以根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种:

定时去清理过期的缓存;

当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。

15.Redis淘汰策略

1. volatile-lru:从设置过期时间的数据集(server.db[i].expires)中挑选出最近最少使用的数据淘汰。没有设置过期时间的key不会被淘汰,这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失。

2. volatile-ttl:除了淘汰机制采用LRU,策略基本上与volatile-lru相似,从设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰,ttl值越小越优先被淘汰。

3. volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰。当内存达到限制无法写入非过期时间的数据集时,可以通过该淘汰策略在主键空间中随机移除某个key。

4. allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰,该策略要淘汰的key面向的是全体key集合,而非过期的key集合。

5. allkeys-random:从数据集(server.db[i].dict)中选择任意数据淘汰。

6. no-enviction:禁止驱逐数据,也就是当内存不足以容纳新入数据时,新写入操作就会报错,请求可以继续进行,线上任务也不能持续进行,采用no-enviction策略可以保证数据不被丢失,这也是系统默认的一种淘汰策略。

16. 基本数据类型

Redis中的一个对象的结构体表示如下:

/*

  • Redis 对象

*/

typedef struct redisObject {

// 类型

unsigned type:4;

// 不使用(对齐位)

unsigned notused:2;

// 编码方式

unsigned encoding:4;

// LRU 时间(相对于 server.lruclock)

unsigned lru:22;

// 引用计数

int refcount;

// 指向对象的值

void *ptr;
} robj;

type表示了该对象的对象类型,即上面五个中的一个。但为了提高存储效率与程序执行效率,每种对象的底层数据结构实现都可能不止一种。encoding就表示了对象底层所使用的编码。

Redis对象底层数据结构

底层数据结构共有八种,如下表所示:

编码常量 编码所对应的底层数据结构

REDIS_ENCODING_INT long 类型的整数

REDIS_ENCODING_EMBSTR embstr 编码的简单动态字符串

REDIS_ENCODING_RAW 简单动态字符串

REDIS_ENCODING_HT 字典

REDIS_ENCODING_LINKEDLIST 双端链表

REDIS_ENCODING_ZIPLIST 压缩列表

REDIS_ENCODING_INTSET 整数集合

REDIS_ENCODING_SKIPLIST 跳跃表和字典

字符串对象

字符串对象的编码可以是int、raw或者embstr。

如果一个字符串的内容可以转换为long,那么该字符串就会被转换成为long类型,对象的ptr就会指向该long,并且对象类型也用int类型表示。

普通的字符串有两种,embstr和raw。embstr应该是Redis 3.0新增的数据结构,在2.8中是没有的。如果字符串对象的长度小于39字节,就用embstr对象。否则用传统的raw对象。可以从下面这段代码看出:

#define REDIS_ENCODING_EMBSTR_SIZE_LIMIT 39

robj *createStringObject(char *ptr, size_t len) {

if (len <= REDIS_ENCODING_EMBSTR_SIZE_LIMIT)

return createEmbeddedStringObject(ptr,len);
else

return createRawStringObject(ptr,len);
}

embstr的好处有如下几点:

embstr的创建只需分配一次内存,而raw为两次(一次为sds分配对象,另一次为objet分配对象,embstr省去了第一次)。

相对地,释放内存的次数也由两次变为一次。

embstr的objet和sds放在一起,更好地利用缓存带来的优势。

需要注意的是,redis并未提供任何修改embstr的方式,即embstr是只读的形式。对embstr的修改实际上是先转换为raw再进行修改。

列表对象

列表对象的编码可以是ziplist或者linkedlist。

ziplist是一种压缩链表,它的好处是更能节省内存空间,因为它所存储的内容都是在连续的内存区域当中的。当列表对象元素不大,每个元素也不大的时候,就采用ziplist存储。但当数据量过大时就ziplist就不是那么好用了。因为为了保证他存储内容在内存中的连续性,插入的复杂度是O(N),即每次插入都会重新进行realloc。如下图所示,对象结构中ptr所指向的就是一个ziplist。整个ziplist只需要malloc一次,它们在内存中是一块连续的区域。

linkedlist是一种双向链表。它的结构比较简单,节点中存放pre和next两个指针,还有节点相关的信息。当每增加一个node的时候,就需要重新malloc一块内存。

哈希对象

哈希对象的底层实现可以是ziplist或者hashtable。

ziplist中的哈希对象是按照key1,value1,key2,value2这样的顺序存放来存储的。当对象数目不多且内容不大时,这种方式效率是很高的。

hashtable的是由dict这个结构来实现的

typedef struct dict {

dictType *type;

void *privdata;

dictht ht[2];

long rehashidx; /* rehashing not in progress if rehashidx == -1 */

int iterators; /* number of iterators currently running */
} dict;

dict是一个字典,其中的指针dicht ht[2] 指向了两个哈希表

typedef struct dictht {

dictEntry **table;

unsigned long size;

unsigned long sizemask;

unsigned long used;
} dictht;

dicht[0] 是用于真正存放数据,dicht[1]一般在哈希表元素过多进行rehash的时候用于中转数据。

dictht中的table用语真正存放元素了,每个key/value对用一个dictEntry表示,放在dictEntry数组中。

集合对象

集合对象的编码可以是intset或者hashtable。

intset是一个整数集合,里面存的为某种同一类型的整数,支持如下三种长度的整数:

#define INTSET_ENC_INT16 (sizeof(int16_t))

#define INTSET_ENC_INT32 (sizeof(int32_t))

#define INTSET_ENC_INT64 (sizeof(int64_t))

intset是一个有序集合,查找元素的复杂度为O(logN),但插入时不一定为O(logN),因为有可能涉及到升级操作。比如当集合里全是int16_t型的整数,这时要插入一个int32_t,那么为了维持集合中数据类型的一致,那么所有的数据都会被转换成int32_t类型,涉及到内存的重新分配,这时插入的复杂度就为O(N)了。是intset不支持降级操作。

有序集合对象

有序集合的编码可能两种,一种是ziplist,另一种是skiplist与dict的结合。

ziplist作为集合和作为哈希对象是一样的,member和score顺序存放。按照score从小到大顺序排列。它的结构不再复述。

skiplist是一种跳跃表,它实现了有序集合中的快速查找,在大多数情况下它的速度都可以和平衡树差不多。但它的实现比较简单,可以作为平衡树的替代品。它的结构比较特殊。下面分别是跳跃表skiplist和它内部的节点skiplistNode的结构体:

/*

  • 跳跃表

*/

typedef struct zskiplist {

// 头节点,尾节点

struct zskiplistNode *header, *tail;

// 节点数量

unsigned long length;

// 目前表内节点的最大层数

int level;
} zskiplist;

/* ZSETs use a specialized version of Skiplists */

/*

  • 跳跃表节点

*/

typedef struct zskiplistNode {

// member 对象

robj *obj;

// 分值

double score;

// 后退指针

struct zskiplistNode *backward;

// 层

struct zskiplistLevel {

// 前进指针

struct zskiplistNode *forward;

// 这个层跨越的节点数量

unsigned int span;
} level[];
} zskiplistNode;

head和tail分别指向头节点和尾节点,然后每个skiplistNode里面的结构又是分层的(即level数组)

每一列都代表一个节点,保存了member和score,按score从小到大排序。每个节点有不同的层数,这个层数是在生成节点的时候随机生成的数值。每一层都是一个指向后面某个节点的指针。这种结构使得跳跃表可以跨越很多节点来快速访问。

前面说到了,有序集合ZSET是有跳跃表和hashtable共同形成的。

typedef struct zset {

// 字典

dict *dict;

// 跳跃表

zskiplist *zsl;
} zset;

为什么要用这种结构呢。试想如果单一用hashtable,那可以快速查找、添加和删除元素,但没法保持集合的有序性。如果单一用skiplist,有序性可以得到保障,但查找的速度太慢O(logN)。

pub/sub:

功能是订阅发布功能,可以用作简单的消息队列。

Pipeline:

可以批量执行一组指令,一次性返回全部结果,可以减少频繁的请求应答。

Lua:

Redis支持提交Lua脚本来执行一系列的功能。

17.redis容灾策略

基本的redis的容灾策略为
1 采用master-slave方式 
2 为了得到好的读写性能,master不做任何的持久化 
3 slave同时开启RDB和AOF来进行持久化,保证数据的安全性 
4 当master挂掉后,修改slave为master 
5 恢复原master数据,修改原先master为slave,启动slave 
6 若master与slave都挂掉后,调用命令通过aof和RDB进行恢复 
恢复时要先确保恢复文件都正确了,才能启动主库;也可以先启动slave,将master与slave对调

18.布隆过滤器使用场景

比如有如下几个需求:

①、原本有10亿个号码,现在又来了10万个号码,要快速准确判断这10万个号码是否在10亿个号码库中?

  解决办法一:将10亿个号码存入数据库中,进行数据库查询,准确性有了,但是速度会比较慢。

解决办法二:将10亿号码放入内存中,比如Redis缓存中,这里我们算一下占用内存大小:10亿*8字节=8GB,通过内存查询,准确性和速度都有了,但是大约8gb的内存空间,挺浪费内存空间的。

19.布隆过滤器详解

带着上面的几个疑问,我们来看看到底什么是布隆过滤器。

  布隆过滤器:一种数据结构,是由一串很长的二进制向量组成,可以将其看成一个二进制数组。既然是二进制,那么里面存放的不是0,就是1,但是初始默认值都是0。

  如下所示:

截屏2023052923.51.28.png

  ①、添加数据

  介绍概念的时候,我们说可以将布隆过滤器看成一个容器,那么如何向布隆过滤器中添加一个数据呢?

  如下图所示:当要向布隆过滤器中添加一个元素key时,我们通过多个hash函数,算出一个值,然后将这个值所在的方格