Redis核心知识思维导图模板_ProcessOn思维导图、流程图

Redis简介

Memcache和Redis的区别

Memcache：代码层次类似hash

支持简单数据类型

不支持数据持久化存储

不支持主从

不支持分片

Redis

数据类型丰富

支持数据磁盘持久化存储

支持主从

支持分片

为什么Redis能这么快？

100000+QPS（官方数据）

完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高

数据结构简单，对数据操作也简单

采用单线程，单线程也能处理高并发请求，想多核也可启动多实例

使用多路I/O复用模型，非阻塞IO

多路I/O复用模型

Fd:File Descriptor,文件描述符

一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射

Select系统调用

Redis采用的I/O多路复用函数

epoll

kqueue

evport

select

Redis常用数据类型

String

最基本的数据类型，二进制安全

Hash

String元素组成的字典，适合存储对象

List

列表，按照String元素插入顺序排序

Set

String元素组成的无序集合，通过哈希表实现，不允许重复

Sorted Set

通过分数来为集合中的成员进行从小到大的排序

用于计数的HyperLogLog

用于支持存储地理位置信息的Geo

从海量Key里查询出某一固定前缀的Key

留意细节

摸清数据规模，即问清楚边界

使用keys对线上的业务的影响

KEYS pattern：查找所有符合给定模式pattern的key

KEYS指令一次性返回所有匹配的key

键的数量过大会使服务卡顿

SCAN指令

SCAN cursor [MATCH pattern]{COUNT count}

基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程

以0作为游标开始一次新的迭代，知道命令返回游标0完成一次遍历

不保证每次执行都返回某个给定数量的元素，支持模糊查询

一次返回的数量不可控，只能是大概率符合count参数

如何通过Redis实现分布式锁

分布式锁需要解决的问题

互斥性

安全性

死锁

容错

如何通过Redis实现

SETNX key value：如果key不存在。则创建并复制

时间复杂度：O(1)

返回值：设置成功，返回1；设置失败，返回0

如何解决SETNX长期有效的问题

EXPIRE key seconds

设置key的生存时间，当key过期时(生存时间为0)，会被自动删除

缺点：原子性得不到满足

能不能解决呢？

SET key value [EX seconds] [PX milliseconds] [NX|XX]

EX second:设置键的过期时间为second秒

PX millisecond:设置键的过期时间为millisecond毫秒

NX:只在键不存在时，才对键进行设置操作

XX:只在键已经存在时，才对键进行设置操作

SET操作成功完成时，返回OK，否则返回nil

大量key同时过期的注意事项

集中过期，由于清楚大量的key很好使，会出现短暂的卡顿现象

解放方案：在设置key的过期时间的时候，给每个key加上随机值

如何使用Redis做异步队列

使用List作为队列，RPUSH生产消息，LPOP消费消息

缺点：没有等待队列里有值就直接消费

弥补：可以通过在应用层引入Sleep机制去调用LPOP重试

BLPOP key [key...] timeout:阻塞直到队列有消息或超时

缺点：只能供一个消费者消费

pub/sub：主体订阅者模式

发送者(pub)发送消息，订阅者（sub）接收消息

订阅者可以订阅任意数量的频道

缺点

消息的发布是无状态的，无法保证可达

持久化方式之RDB

RDB(快照)持久化：保存某个时间点的全量数据快照

配置信息

save 900 1

900s写入一次触发一次

save 300 10

300秒写入10次触发一次

save 60 10000

60秒写入10000次触发一次

stop-writes-on-bgsave-error yes

当备份进程出错的时候，主进程停止写入操作

rdbcompression no

rdb文件压缩开关，建议关闭，redis属于cpu密集型，开启会影响redis性能

save &quot;&quot;

禁用rdb配置

SAVE:阻塞Redis的服务器进程，直到RDB文件被创建完毕

BGSAVE:Fork出一个子进程来创建RDB文件，不阻塞服务器进程

lastsave：查询上次备份的时间戳

自动化触发RDB持久化的方式

根据 redis.conf配置里的SAVE m n 定时触发(用的是BGSAVE)

主从复制时，主节点自动触发

执行Debug Reload

执行Shutdown且没有开启AOF持久化

BGSAVE原理

分支主题

系统调用fork（）：创建进程，实现了Copy-on-write

Copy-on-Write

如果有多个调用者同时要求相同资源(如内存或磁盘上的数据存储)，他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变

缺点

内存数据的全量同步，数据量大会由于I/O而严重影响性能

可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据

持久化之AOF

AOF(Append-Only-File)持久化:保存写状态

记录下除了查询以外的所有变更数据库状态的指令

以append的形式追加保存到AOF文件中(增量)

配置信息

默认是关闭的

appendonly yes

控制aof开关

appendfilename &quot;appendonly.aof&quot;

aof文件名

appendsync always/eyerysec/no

always

一旦缓冲区的内容发生变化就执行一次

everysec

将缓冲区内容每隔一秒执行一次

默认

no

将缓冲区内容备份交由操作系统管理，一般是缓冲区被写满时进行备份

日志重写解决AOF文件大小不断增大的问题(rewrite)

原理

调用fork（）,创建一个子进程

子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件

主进程持续将新的变动同时写到内存和原来的AOF里

主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动

使用新的AOF文件替换掉旧的AOF文件

Redis数据的恢复

RDB和AOF文件共存情况下的恢复流程

分支主题

RDB和AOF的优缺点

RDB

RDB优点:全量数据快照，文件小，恢复快

RDB缺点:无法保存最近一次快照之后的数据

AOF

AOF优点:可读性高，适合保存增量数据，数据不易丢失

AOF缺点：文件体积大，恢复时间长

RDB-AOF混合持久化方式

Redis3.0提供的默认方式

BGSAVE做镜像全量持久化，AOF做增量持久化

原理

分支主题

使用Pipeline的好处

Pipeline和linux管道类似

Redis基于请求/响应模型，单个请求处理需要一一应答

Pipline批量执行指令，节省多次IO往返的时间

有顺序依赖的指令建议分批发送

Redis的同步机制

主从同步原理

全同步过程

Salve发送sync命令到Master

Master启动一个后台进程，将Redis中的数据快照保存到文件中

Master将保存数据快照期间接收到的写命令缓存起来

Master完成写文件操作后，将文件发送给salve

使用新的AOF文件替换掉旧的AOF文件

Master将这期间收集的增量写命令发送给salve端

增量同步过程

Master接收到用户的操作指令，判断是否需要传播到slave

将操作记录追加到aof文件

将操作传播到其他slave

1:对齐主从库

2.响应缓存写入命令

将缓存中的数据发送给slave

Redis Sentinel(哨兵)

解决主从同步Master宕机后的主从切换问题

监控:检查主从服务器是否运行正常

提醒:通过API向管理员或者其他应用程序发送故障通知

自动故障迁移:主从切换

流言协议Gossip

在杂乱无章中寻求一致

每个节点都随机地与对方通信，最终所有节点的状态达成一致

种子节点定期随机向其他节点发送节点列表以及需要传播的消息

不保证信息一定会传递给所有节点，但是最终会趋于一致

部署架构

至少需要三个节点

主备切换数据丢失场景

异步复制

脑裂

核心原理

sdown和odown

sdown主观宕机

odown客观宕机

哨兵集群的自动发现机制

slave配置自动纠正

选举算法

判断跟master断开时长，如果超过down-after-milliseconds的10倍则不适合为master

按照slave优先级进行排序，slave priority月底，优先级就越高

如果slave priority相同，那么看offset，offset越靠后优先级越高

如果offset相同那么选择run id比较小的那么slave

Redis集群（redis cluser）原理

数据分片算法

如何从海量数据里快速找到所需？

分片：按照某种规则去划分数据，分散存储在多个节点上

常规的按照哈希划分无法事先节点的动态增减

算法

一致性哈希算法:对2^32取模。将哈希值空间组织成虚拟的圆环

分支主题

将数据key使用相同的函数Hash计算出哈希值

分支主题

新增服务器

分支主题

Hash环的数据倾斜问题

分支主题

引入虚拟节点解决数据倾斜问题

通常会设置32可能会更大

分支主题

slave自动化迁移实现更强高可用

gossip通信协议<br>

原理

节点维护的信息

当前集群的状态

集群中各节点所负责的 slots信息，及其migrate状态

集群中各节点的master-slave状态

集群中各节点的存活状态及怀疑Fail状态

节点间消息类型

MEET：通过「cluster meet ip port」命令，已有集群的节点会向新的节点发送邀请，加入现有集群，然后新节点就会开始与其他节点进行通信；

PING：节点按照配置的时间间隔向集群中其他节点发送 ping 消息，消息中带有自己的状态，还有自己维护的集群元数据，和部分其他节点的元数据；

PONG: 节点用于回应 PING 和 MEET 的消息，结构和 PING 消息类似，也包含自己的状态和其他信息，也可以用于信息广播和更新；

FAIL: 节点 PING 不通某节点后，会向集群所有节点广播该节点挂掉的消息。其他节点收到消息后标记已下线。

优点

数据更新压力分散，元数据的更新比较分散，不是集中某一个节点，更新请求比较分散，而且有不同节点处理，有一定的延时，降低了并发压力

缺点

数据更新延迟，可能导致集群的感知有一定的滞后