Redis核心知识
2021-07-29 19:07:22 0 举报AI智能生成
登录查看完整内容
redis核心知识整理
作者其他创作
大纲/内容
支持简单数据类型
不支持数据持久化存储
不支持主从
不支持分片
Memcache：代码层次类似hash
数据类型丰富
支持数据磁盘持久化存储
支持主从
支持分片
Redis
Memcache和Redis的区别
100000+QPS（官方数据）
完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
数据结构简单，对数据操作也简单
采用单线程，单线程也能处理高并发请求，想多核也可启动多实例
使用多路I/O复用模型，非阻塞IO
为什么Redis能这么快？
一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射
Select系统调用
epoll
kqueue
evport
select
Redis采用的I/O多路复用函数
因地制宜
优先选择时间复杂度为O(1)的I/O多路复用函数作为底层实现
以时间复杂度为O(n)的select作为保底
基于React设计模式监听I/O事件
具体是用哪个函数？
多路I/O复用模型
Redis简介
最基本的数据类型，二进制安全
String
String元素组成的字典，适合存储对象
Hash
列表，按照String元素插入顺序排序
List
String元素组成的无序集合，通过哈希表实现，不允许重复
Set
通过分数来为集合中的成员进行从小到大的排序
Sorted Set
用于计数的HyperLogLog
用于支持存储地理位置信息的Geo
Redis常用数据类型
1.简单动态字符串
2.链表
3.字典
4.跳跃表
5.整数集合
6.压缩列表
7.对象
底层数据类型基础
摸清数据规模，即问清楚边界
留意细节
KEYS指令一次性返回所有匹配的key
键的数量过大会使服务卡顿
KEYS pattern：查找所有符合给定模式pattern的key
使用keys对线上的业务的影响
基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
以0作为游标开始一次新的迭代，知道命令返回游标0完成一次遍历
不保证每次执行都返回某个给定数量的元素，支持模糊查询
一次返回的数量不可控，只能是大概率符合count参数
SCAN cursor [MATCH pattern]{COUNT count}
返回的数据可能会有重复的问题，自己写的程序要注意去重
SCAN指令
从海量Key里查询出某一固定前缀的Key
互斥性
安全性
死锁
容错
分布式锁需要解决的问题
时间复杂度：O(1)
返回值：设置成功，返回1；设置失败，返回0
SETNX key value：如果key不存在。则创建并复制
设置key的生存时间，当key过期时(生存时间为0)，会被自动删除
缺点：原子性得不到满足
EXPIRE key seconds
如何解决SETNX长期有效的问题
EX second:设置键的过期时间为second秒
PX millisecond:设置键的过期时间为millisecond毫秒
NX:只在键不存在时，才对键进行设置操作
XX:只在键已经存在时，才对键进行设置操作
SET操作成功完成时，返回OK，否则返回nil
SET key value [EX seconds] [PX milliseconds] [NX|XX]
能不能解决呢？
解放方案：在设置key的过期时间的时候，给每个key加上随机值
集中过期，由于清楚大量的key很好使，会出现短暂的卡顿现象
大量key同时过期的注意事项
如何通过Redis实现
如何通过Redis实现分布式锁
缺点：没有等待队列里有值就直接消费
弥补：可以通过在应用层引入Sleep机制去调用LPOP重试
使用List作为队列，RPUSH生产消息，LPOP消费消息
缺点：只能供一个消费者消费
BLPOP key [key...] timeout:阻塞直到队列有消息或超时
发送者(pub)发送消息，订阅者（sub）接收消息
订阅者可以订阅任意数量的频道
消息的发布是无状态的，无法保证可达
缺点
pub/sub：主体订阅者模式
如何使用Redis做异步队列
900s写入一次触发一次
save 900 1
300秒写入10次触发一次
save 300 10
60秒写入10000次触发一次
save 60 10000
当备份进程出错的时候，主进程停止写入操作
stop-writes-on-bgsave-error yes
rdb文件压缩开关，建议关闭，redis属于cpu密集型，开启会影响redis性能
rdbcompression no
禁用rdb配置
save ""
配置信息
SAVE:阻塞Redis的服务器进程，直到RDB文件被创建完毕
BGSAVE:Fork出一个子进程来创建RDB文件，不阻塞服务器进程
lastsave：查询上次备份的 时间戳
根据 redis.conf配置里的SAVE m n 定时触发(用的是BGSAVE)
主从复制时，主节点自动触发
执行Debug Reload
执行Shutdown且没有开启AOF持久化
自动化触发RDB持久化的方式
分支主题
如果有多个调用者同时要求相同资源(如内存或磁盘上的数据存储)，他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变
Copy-on-Write
系统调用fork（）：创建进程，实现了Copy-on-write
BGSAVE原理
内存数据的全量同步，数据量大会由于I/O而严重影响性能
可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据
RDB(快照)持久化：保存某个时间点的全量数据快照
持久化方式之RDB
记录下除了查询以外的所有变更数据库状态的指令
以append的形式追加保存到AOF文件中(增量)
默认是关闭的
控制aof开关
appendonly yes
aof文件名
appendfilename "appendonly.aof"
一旦缓冲区的内容发生变化就执行一次
always
默认
将缓冲区内容每隔一秒执行一次
everysec
将缓冲区内容备份交由操作系统管理，一般是缓冲区被写满时进行备份
no
appendsync always/eyerysec/no
子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
主进程持续将新的变动同时写到内存和原来的AOF里
主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动
使用新的AOF文件替换掉旧的AOF文件
原理
日志重写解决AOF文件大小不断增大的问题(rewrite)
AOF(Append-Only-File)持久化:保存写状态
RDB和AOF文件共存情况下的恢复流程
Redis数据的恢复
RDB优点:全量数据快照，文件小，恢复快
RDB缺点:无法保存最近一次快照之后的数据
RDB
AOF优点:可读性高，适合保存增量数据，数据不易丢失
AOF缺点：文件体积大，恢复时间长
AOF
RDB和AOF的优缺点
Redis3.0提供的默认方式
BGSAVE做镜像全量持久化，AOF做增量持久化
RDB-AOF混合持久化方式
持久化之AOF
Pipeline和linux管道类似
Redis基于请求/响应模型，单个请求处理需要一一应答
Pipline批量执行指令，节省多次IO往返的时间
有顺序依赖的指令建议分批发送
使用Pipeline的好处
Salve发送sync命令到Master
Master启动一个后台进程，将Redis中的数据快照保存到文件中
Master将保存数据快照期间接收到的写命令缓存起来
Master完成写文件操作后，将文件发送给salve
Master将这期间收集的增量写命令发送给salve端
全同步过程
Master接收到用户的操作指令，判断是否需要传播到slave
将操作记录追加到aof文件
1:对齐主从库
2.响应缓存写入命令
将操作传播到其他slave
将缓存中的数据发送给slave
增量同步过程
主从同步原理
Redis的同步机制
监控:检查主从服务器是否运行正常
提醒:通过API向管理员或者其他应用程序发送故障通知
自动故障迁移:主从切换
解决主从同步Master宕机后的主从切换问题
每个节点都随机地与对方通信，最终所有节点的状态达成一致
种子节点定期随机向其他节点发送节点列表以及需要传播的消息
不保证信息一定会传递给所有节点，但是最终会趋于一致
在杂乱无章中寻求一致
流言协议Gossip
至少需要三个节点
部署架构
异步复制
脑裂
主备切换数据丢失场景
min-slaves-to-write：1
min-slaves-max-lag：10
解决
至少有一个slave与master同步延时不能超过10s
sdown主观宕机
odown客观宕机
sdown和odown
哨兵集群的自动发现机制
slave配置自动纠正
判断跟master断开时长，如果超过down-after-milliseconds的10倍则不适合为master
按照slave优先级进行排序，slave priority月底，优先级就越高
如果slave priority相同，那么看offset，offset越靠后优先级越高
如果offset相同那么选择run id比较小的那么slave
选举算法
核心原理
Redis Sentinel(哨兵)
分片：按照某种规则去划分数据，分散存储在多个节点上
常规的按照哈希划分无法事先节点的动态增减
如何从海量数据里快速找到所需？
一致性哈希算法:对2^32取模。将哈希值空间组织成虚拟的圆环
将数据key使用相同的函数Hash计算出哈希值
新增服务器
Hash环的数据倾斜问题
通常会设置32可能会更大
引入虚拟节点解决数据倾斜问题
算法
数据分片算法
slave自动化迁移实现更强高可用
当前集群的状态
集群中各节点所负责的 slots信息，及其migrate状态
集群中各节点的master-slave状态
集群中各节点的存活状态及怀疑Fail状态
节点维护的信息
MEET：通过「cluster meet ip port」命令，已有集群的节点会向新的节点发送邀请，加入现有集群，然后新节点就会开始与其他节点进行通信；
PING：节点按照配置的时间间隔向集群中其他节点发送 ping 消息，消息中带有自己的状态，还有自己维护的集群元数据，和部分其他节点的元数据；
PONG: 节点用于回应 PING 和 MEET 的消息，结构和 PING 消息类似，也包含自己的状态和其他信息，也可以用于信息广播和更新；
FAIL: 节点 PING 不通某节点后，会向集群所有节点广播该节点挂掉的消息。其他节点收到消息后标记已下线。
节点间消息类型
gossip通信
数据更新压力分散，元数据的更新比较分散，不是集中某一个节点，更新请求比较分散，而且有不同节点处理，有一定的延时，降低了并发压力
优点
数据更新延迟，可能导致集群的感知有一定的滞后
gossip通信协议
Redis集群（redis cluser）原理
0 条评论
回复 删除
下一页
