redis知识图谱
2021-07-24 15:07:03 0 举报AI智能生成
redis整体框架介绍
作者其他创作
大纲/内容
setnx： 不存在时 再设置
mset: 批量设置 mset k1 a k2 b
mget: 批量获取 k1 k2
append: 追加 append k1 " world"
getrange k1 5 -1 代表取第五位开始到最后一位得字符串
这里有一个正负向索引的概念
getRange : 获取value中的第几位到第几位 getrange key1 1 2
setRange: 替换某一个key中的某几位字符串 setRange k1 5 "MSB" 代表从第五个位置开始 设置为MSB
strlen 获取字符串的长度
getset: 先响应回去一个old值 ，再覆盖一个新值
字符类型
incr
incr by
decr
decr by
适用场景：抢购 秒杀
integer类型
setbit key offset(bit位置) value
bitpos key bit start end 查找bit值0或者1 在字节当中出现的二进制的位置
bitop and/or newkey k1 k2 对k1 k2的二进制进行与或操作 得到的值赋给newkey
方案：将用户的ID 作为key 第几天的天数做为bit的位数 0/1表示登录的状态
设置：setbit yj 355 1
统计：bitcount yj -2 -1 代表查询的是 yj在最后16天的登录次数
优点 ：每个用户只需要46B 1000千万 用户的登录数据只需要400多M
使用场景：用户系统，统计用户的登录次数 随机的时间窗口
保存 setbit 20210705 5 0 (5 代表第5号用户)
统计方案： 1、bitop or destkey 20210705 20210706 2、bitcount destkey 0 -1
使用场景2：618做活动 登录的人即可领取一份礼物，仓库应该备多少货？ 此时需要提前计算活跃用户
bitmap
api: type (可以使用object encoding k1 对k1的value进行格式化 如果k1的值设置的是99 则type的值 会是int)
string
设置zs的name是张三
set zs::name 张三
基于上边这种需求，设计出更为合理的hash结构
设置单个key的属性
hset key key1 value
批量设置属性
hmset key key1 a key2 b key3 c
取出key1中的key属性
hget key1 key
取出key1中的a b c 对应的值
hmget key1 a b c
取出key1中的所有的key
hkeys key1
取出key1中的所有的values
hvalues key1
取出key1中的所有的键值对
hgetall key1
对key1中的age 做自增0.5的操作
hincrbyfloat key1 age 0.5
hash
从左边逐个添加元素 可多个
lpush
从右边逐个添加元素 可多个
rpush
弹出左边第一个元素
lpop\t
弹出右边第一个元素
rpop
基于首尾操作的方式 可将redis视为栈操作 也可视为队列操作
取出list中的某几位元素
lrange key start end
取出list中第几位的元素
lindex key index
设置list中的第几位的值
lset key index value
从左至右移出num个元素value
lrem key num value
代表在list中的第6位元素后插入要一个a
linsert key after 6 a
代表在list中的最后一个元素前插入一个a
linsert key before -1 a
一直阻塞获取key中的第一个元素 获取到元素后 会结束
注意：如果有多个客户端阻塞获取某个list时 最开始阻塞的 会最开始获取到 其他的客户端按照开始阻塞的顺序依次获取
单播队列 FIFO
blpop key timout
删除start右侧 end左侧的元素（两端的元素）
ltrim key start end
list
sadd
获取一个set集合中的元素个数
scard
移出某个元素（可多个\t）
srem\t
获取所有的元素
smembers
取两个集合中相同的元素
sinner k1 k2
取出相同的元素后 将相同的元素放到目标key中
sinnerstore destkey k1 k2
取两个集合中的合集
sunion k1 k2
随机取出set集合中的几个元素
count为正数时 取出的元素个数不能超过集合本身
count为负数时 取出的元素个数一定=count 但会取出重复的数据
如果为0 时 不反回数据
可以使用的场景：抽奖
srundmember k1 count
随机弹出一个元素
使用场景：抽奖 一次抽出一个奖 且抽中的人 不能再参与抽奖
spop
set
有序的set集合：按分值进行排序
物理内存上 是按照 左小右大的方式进行排序
如 zrange k1 0 -1 取出所有的元素。
zrange k1 start end withscores
zrange k1 start end
按照给定的分值取元素
zrangebyscore k1 startscore endscore
元素的排名
zrank k1 apple
根据元素取出分值
zscore k1 apple
按照反向取出元素
zrevrange
将apple对应的元素分值+2.5
使用场景：歌曲动态实时排名
zincrby k1 2.5 apple
对两个集合相同的key做相加操作 并放到新的key中
后边的聚合的用法是 如max是取两个集合中的相同key的最大值
zuniostore newkey 2 k1 k2 weights k1的权重 k2的权重(aggregate sum/min/max默认是相加)
在添加元素时 会随机造层
排序的实现是skip：跳跃表
zset
支持的数据类型
BIO（blocking 阻塞IO） ： 内核 kernel
NIO(同步非阻塞): 在用户空间中采用循环遍历的方式 获取结果问题如下：如果用户取1000个数据，需要与redis内核交互1000次 成本太高了
为了解决这个问题，创建出共享空间 采用索引位置进行标记 获取， mmap epoll
发展路程
IO多路复用
linux内核提供的一种调用方式
epoll
命令：nc localhost 6379
复杂使用：echo -e 'set k1 2 \ incr k1 \ get k1' | nc localhost 6379
管道
返回错误
删除最少使用的key
删除设置了过期时间最少使用的key
随机删除key
随机删除设置了过期时间的key
在设置了过期时间的集合中 删除马上要过期的key
LFU：最少使用的次数
LRU：长时间内没有使用
LFU 与LRU的区别
内存淘汰机制
当客户端访问时 判断有没有过期
主动删除
当客户端没有访问时 ，过期的key 采用 1、每隔10秒抓取20个key进行抽查 2、删除过期的key 3、如果有对于25%的key过期 则重复1步骤
被动删除
过期的key删除策略
机制
命令：publish channel message
命令：subscribe channel
注意：只有消费者启动后 生产者发的消息才会被接收 否则会丢失
发布订阅：pub|sub
开启事务：multi
提交事务：exec
中断事务：discard
如果两个线程同时对1个key进行事务操作，一个线程执行后的结果对另外一个线程造成提交失败的影响时 使用watch可以提前监控k值 发现key已经被删除时 会取消事务 并中断执行
watch 可以实现乐观锁、CAS的操作
事务
定义：查询redis中本来没有的数据 导致所有的查询全部都打到数据库上
解决缓存穿透的问题
实现原理：将系统中的数据 通过映射函数映射到bitmap中 标记为1，没有的数据 不标记。请求的数据进到redis后先判断元素是否被标记为1 ，为0的 则被拦截
其他的过滤器：counting bloom 升级版的布隆过滤器 布谷鸟过滤器
语法：BF.add k1 adc 在添加k1元素的过滤元素
语法：BF.EXISTS K1 abc 判断abc 在不在k1的过滤器里边
redis_bloom 布隆过滤器
modules
其他机制
基础
管道：前一个命令的输出 作为后一个命令的输入
管道会触发创建子进程
echo $$ | more 打印当前的进程id 管道 （会打印出父进程的ID）echo $BASHPID | more 打印当前的进程id 管道（会打印出子进程的ID）说明：$$ 的级别比 | 高
常规：看不到
进阶：可以看到 使用export 关键字修饰一下
父进程的数据 子进程是否可以看到？
看不到 同样的父进程修改 子进程也看不到
被export修饰的父进程中的变量，子进程修改数据 父进程是否可以看到？
linux的父子进程
linux基础常识补充：
引出问题：在快照持久化时 是否能看到新修改的数据？
fork的机制：copy-on-write 写时复制
1、准时开辟一个子进程（fork）
2、开辟完子进程后 ，将redis中的所有的数据（类似于栈中的对象）复制一份出来
3、在复制的过程中 子进程的指针不会变化 指向的还是原父进程的内存地址 此时当父进程发生写时 会将原指针指向新的内存地址 不会影响已经fork出来的子进程的数据
4、在复制完成后 子进程才会将数据从内存中 读取出来后落地到磁盘中
快照过程
阻塞服务 进行快照
场景：如停机维护时进行阻塞save
save 900 1save 300 10save 60 10000
save second change 在固定的时间段内 或者多少次操作后进行快照保存
save
非阻塞 后台fork进行快照
bgsave
方法
永远只有一个dump.rdb(需要运维辅助保存策略 如每天转出一份)
丢失数据相对来说比较多一点
弊端
优点：恢复速度快
快照：RDB
定义：将操作记录追加到文件中\t
丢失数据少
优点
体量无限大，恢复速度较慢
弊端
4.0之后的版本，AOF会包含RDB的全量，增加记录新的写操作
备注：当同时开启了AOF 与 RDB ，恢复时只会使用aof
删除抵消的命令
合并重复的命令
最终也是一个纯指令的文件
整合命令
4.0之前
将老的数据 rdb到aof当中 ，将增量的数据以指令的形式append到aof文件中
最终是一个rdb 与aof的整合体
重写
4.0之后
持久化方案
优化：
AOF
持久化
没有数据类型
缺点：返回的value需要手动解码，server的网卡 IO会成为瓶颈
memcache
参与业务 客户端可以访问到任何一个节点
原理：通过发布订阅的方式发现其他的哨兵
解决问题：解决主从复制下的人工处理故障的问题
哨兵机制
主从
只有主节点参与业务
主备
每一个节点又是一个单节点
读写分离
一般对主机做ha高可用
场景：数据可以分类 交集不多
按照业务逻辑拆分
场景：数据没办法再拆分
按照算法拆分
数据拆分
各种集群架构
consistency 一致性
availabilitity 可用性
partition tolerons 分区容错性
cap理论
集群
redis
0 条评论
回复 删除
下一页
