redis

作者: AGEGG | 来源:发表于2020-04-13 21:48 被阅读0次

Memcash和redis的区别

Memcash:代码层次类似Hash

支持简单数据类型
不支持数据持久化存储
不支持主从
不支持分片

redis

数据类型丰富
支持数据磁盘持久化储存
支持主从
支持分片

redis为什么能这么快

10万+QPS
1.完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
2.数据结构简单，对数据操作也简单
3.采用单线程，单线程也能处理高并发请求，想多核也可启动多实例
4.使用多路I/O复用模型，非阻塞IO

多路I/O复用模型

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

image.png

Redis采用的I/O多路复用函数：epoll/kqueue/evport/select?
1.因地制宜
2.优先选择时间复杂度为O(1)的多路复用函数作为底层实现
3.以时间复杂度为O(n)的select作为保底
4.基于react设计模式监听I/O事件

redis 数据类型

image.png

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

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

image.png

Redis实现分布式锁

分布式锁需要解决的问题

1.互斥性
2.安全性
3.死锁
4.容错

setnx key value :如果key不存在，则创建并赋值
时间复杂度： O(1)
返回值：设置成功，返回1；设置失败，返回0

expire key seconds
设置key的生存时间，当key过期时(生存时间为0)，会被自动删除
缺点：原子性得不到满足，挂掉后会死锁

image.png

set uid 11426 ex 10 nx

image.png

使用Redis做异步队列

使用List作为队列，rpush生产消息，lpop消费消息
缺点：没有等待队列有值就直接消费
弥补：可以通过在应用层引入Sleep机制去调用LPOP重试

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

image.png
缺点：只能供一个消费者消费

pub/sub 主题订阅者模式
发送者(pub)发送消息，订阅者(sub)接受消息
订阅者可以订阅任意数量的频道

image.png

pub/sub 缺点：
消息的发布是无状态的，无法保证可达

redis做持久化

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

redis.conf  找到save，大概218行
save 900 1           900s内有一条写入执行执行一次快照
save 300 10         300s内有10条写入执行一次快照
save 60 10000     60s内有1万写入，执行一次快照

//当备份进程出错时，主进程停止进行新的写入操作，保护持久化数据一致性问题
stop-writes-on-bgsave-err yes
//备份时，将rdb文件进行压缩后进行保存(建议no，cpu比硬盘更值钱)
rdbcompression yes
//同时若要禁用rbd配置，也可以在上面添加  save ""

image.png

文件在 src/dump.rdb
lastsave 查看最后save的时间

image.png

缺点：
内存数据全量同步，数据量大会由于I/O而严重影响性能
可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据

AOF(Append-Only_File)持久化：保存写状态

记录下除了查询以外的所有变更数据库状态的指令
以append的形式追加保存在AOF文件中(增量)

redis.conf
//改为yes 开启
appendonly no
//文件名 
appendfilename "appendonly.aof"
//always 一旦缓存区发生变化 everysec 每秒执行 no 缓存满执行 推荐默认的everysec 
appendfsync everysec