redis快速复习

最新推荐文章于 2024-04-21 10:06:09 发布

孙靖俊

最新推荐文章于 2024-04-21 10:06:09 发布

阅读量230

点赞数 1

分类专栏： # Redis 文章标签： redis

本文链接：https://blog.csdn.net/weixin_42220532/article/details/108561353

版权

Redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

同样作为缓存技术，memcache和redis的区别

memcache只支持key-value类型，不支持主从，不支持分片，不支持数据持久化

redis数据类型丰富，支持主从，支持分片，支持数据持久化
为什么redis这么快

官方提供10w+qps
- 完全基于内存
- 数据类型简单
- 采用单线程模型，主线程是单线程，包括IO事件的处理，IO业务的处理，过期键的处理，复制协调，集群协调。正因为单线程，避免了并发问题，也就是上下文切换，锁的竞争等。在测试中发现，cpu并不是制约redis的瓶颈
redis常用数据类型

string,hash,list,set,zset(sorted set)

string是常用的字符串类型，hash类型类似于常用的对象，list是列表，可以双端添加删除，set表示不重复列表，zset表示带有权值的set
如何从海量数据中查询某一固定前缀的key

redis中有模糊查询key值的命令 keys pattern

但是如果是生产环境，是严禁使用这类型的命令的，因为这种命令遇到海量数据会发生卡顿阻塞住，而redis的处理线程是单线程，所以应该避免这个命令的使用

遇到这类型场景，应该使用scan命令
```
scan cursor [MATCH pattern] [COUNT count]
```
- cursor指游标，表示当前开始查找的位置，开始时应该输入0，调用该命令后会同样返回一个游标，表示下次调用应该输入的游标，执行完毕时返回0
- count表示本次迭代返回的数量，这个数量只是一个大致，并不会严格遵守，不过也满足平常的使用
- 返回数据有两类，第一个就是游标，也就是第一点提到的，第二类是数据，我们需要多次调用该命令来完成查询，但是有可能返回的数据有重复，所以我们需要在上层应用进行去重处理
使用redis实现分布式锁

使用setnx指令来进行设置键和值，和平常的set指令使用方法相同，如果要释放锁，就需要为这个key加上一个过期时间，使用expire指令，但是存在的风险就是，同时使用两个指令，违背了原子性的原则，如果setnx后挂掉了，那么无法expire，也就无法释放锁了

redis提供了新的命令来解决这个问题
```
set key value [EX seconds] [PX milliseconds] [NX|XX]
```
- EX代表设置时间，单位为s，PX同样是时间，精确为毫秒
- NX代表当键不存在时执行操作
- XX代表当键存在时执行操作
如何实现异步队列

在redis中有一种类型List可以作为队列，使用rpush和lpop就可以实现队列的功能

redis还提供了阻塞式的拿取，blpop

实现多客户端监听->pub/sub：主题订阅者模式，发送者(pub)发送消息，接收者(sub)接受消息

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7OhUGhYj-1599973211374)(C:\Users\Sun Jingjun\AppData\Roaming\Typora\typora-user-images\image-20200909172522774.png)]$

这种方式有缺点就是无法保证消息的可靠性，发完后消息就会丢弃
持久化方案

持久化分为RDB和AOF，Redis4.0后采用的是两种混合的模式

RDB方式：

RDB是全量持久化，备份文件为dump.rdb 如下

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vfk0s0LM-1599973211376)(C:\Users\Sun Jingjun\AppData\Roaming\Typora\typora-user-images\image-20200910204947885.png)]$

RDB的持久化策略为：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vc8wjYHl-1599973211376)(C:\Users\Sun Jingjun\AppData\Roaming\Typora\typora-user-images\image-20200910205040608.png)]$

意思为：如果900s内有一条写入指令，则触发一次持久化，300s内有10条上的写入指令则触发一次持久化，60s内有10000条写入指令则触发一次持久化

RDB生成快照的方式有两种：
- SVAE : 阻塞主线程，主线程执行持久化操作
- BGSAVE : fork出子进程执行持久化操作
客户端执行lastsave可以查询上次持久化的时间

触发RDB的方式：1.配置文件中定频率触发 2.主从同步时，主节点触发 3.执行Debug Reload 4.执行shutdown时触发

AOF方式：
- 记录除了查询以外的所有变更状态指令
- 以append的方式追加到AOF文件中
$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-piuSoaXX-1599973211378)(C:\Users\Sun Jingjun\AppData\Roaming\Typora\typora-user-images\image-20200913103526074.png)]$

AOF文件是默认关闭的，改为yes后开启

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ttRyWcvV-1599973211379)(C:\Users\Sun Jingjun\AppData\Roaming\Typora\typora-user-images\image-20200913103700896.png)]$

同步频率，always表示任何命令总是同步，everysec表示每秒同步一次，no表示等待缓冲区被填满后才进行同步

可以使用bgrewrite来进行aof文件的精简重写，原理与bgsave相同，都是fork一个子进程，copy-on-write

恢复数据的过程：先去判断有没有aof文件，如果有，先以aof文件恢复为准，如果没有，则去加载rdb文件

优缺点对比：
- rdb：全量保存，文件小，恢复快，但是无法实时保存数据
- aof：增量保存，可读性高，数据不易丢失，恢复时间长
redis4.0后，RDB-AOF混合持久化：aof文件的前半段是rdb格式，后面增量部分是aof格式
主从同步

在一段时间后，保证master和slave的数据是一致的，也就是弱一致性，也就是最终一致性
- 全量同步：slave发送sync到master，master执行bgsave，启动后台进程保存数据快照，同时保存数据快照期间的增量命令，执行完bgsave后，将数据发送到缓存区，由缓冲区发送到slave，salve使用新的aof文件替换旧的aof文件。完后master将增量命令发送到slave
- 增量同步：master首先进行主从对齐，确认是需要同步的slave机器，然后将增量命令写入缓冲区，发送到slave
哨兵

功能：
1. 监控master是否运行正常
2. 通过api提供故障通知
3. 故障迁移，完成主从切换
一致性hash算法

redis集群之间使用一致性hash算法来决定key落到哪个机器上

一致性hash算法是对2^32进行取模操作，将hash值的空间组织成虚拟环

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kz29z4hx-1599973211381)(C:\Users\Sun Jingjun\AppData\Roaming\Typora\typora-user-images\image-20200913123530538.png)]$

根据顺时针来决定存入到哪个节点，当节点宕机后或者新增加节点时，只需要修改部分key，做到最小化有损

问题：hash环数据倾斜问题——由于节点较少，数据大量存储在某一个节点

解决：增加多个虚拟节点

孙靖俊

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
redis快速复习

同样作为缓存技术，memcache和redis的区别memcache只支持key-value类型，不支持主从，不支持分片，不支持数据持久化redis数据类型丰富，支持主从，支持分片，支持数据持久化为什么redis这么快官方提供10w+qps完全基于内存数据类型简单采用单线程模型，主线程是单线程，包括IO事件的处理，IO业务的处理，过期键的处理，复制协调，集群协调。正因为单线程，避免了并发问题，也就是上下文切换，锁的竞争等。在测试中发现，cpu并不是制约redis的瓶颈redi..
复制链接

扫一扫