1.添加redis缓存
2.缓存更新策略(一致性,维护成本)
- 内存淘汰
- 超时剔除
- 主动更新
- 操作缓存和数据库
- 更新数据库时让缓存失效,查询时再更新缓存
- 先操作缓存还是数据库?双删策略,先删除缓存,操作数据库,然后再删缓存
- 缓存穿透
- 将空值缓存,查询时,命中缓存,判断缓存是否为空
- 缓存雪崩
- 缓存击穿
- 加锁
- 逻辑删除
- 缓存工具封装
- stream
- 创建名为users的队列,并向其中发送一个消息,内容是:{name=jack,age=21},并且使用redis自动生成ID
sadd users * name jack age 21 - xlen
- xread
xread count 1 streams users 0 - 消费者组
- 描述:将多个消费者划分到一个组中,监听一个队列
- 特点:
消息分流:队列中的消息会分流给组内的不同消费者,而不是重复消费,从而加快消息处理的速度。
消息标示:消费者组会维护一个标示,记录最后一个被处理的消息,哪怕消费者宕机重启,还会从标示之后读取消息,确保每一个消息都会被消费。
消息确认:消费者获取消息后,消息处于pending的状态,并存入一个pending-list,当处理完成后需要通过xack来确认消息,标记消息为已处理,才会从pending-list移除 - 命令
- 创建
xgroup create key groupName ID [mkstream]
ID:起始ID标示,$表示队列中最后一个消息,0则表示队列中的第一个消息 - 删除指定的消费者组
xgroup destory key groupName - 给指定的消费者组添加消费者
xgroup createconsumer key groupname consumername - 删除消费者组中的指定消费者
xgroup delconsumer key groupName consumername - 从消费者组中读取消息
XREADGROUP GROUP group consumer [CONUNT count] [BLOCK milliseconds] [NOACK] STREAMS key [key …] ID [ID …]
group:消费者组名称
consumer:消费者名称,如果消费者不存在,会自动创建一个消费者
count:本次查询的最大数量
BLOCK milliseconds:当没有消息时最长等待时间
NOACK:无需手动ack,获取到消息后自动确认
STREAMS key:指定队列名称
ID:获取消息的起始ID
“>”:表示从下一个未消费的消息开始
其它:根据指定id从pending-list中获取已经消费但未确认的消息,例如0,是从pending-list中的第一个消息开始 - 确认命令
xack key group ID - 查看pending-list命令
xpending key group - + 10 - sortedSet类型
- 命令:
zadd key score member
zrem key member
zscore key member
zrank key member
zrevrank key member
zcard key
zcount key min max:统计score值在给定范围内的所有元素的个数
zincrby key increment member
zrange key min max:安装score排序后,获取指定排名范围内的元素
zrangebyscore key min max:按照score排序后,获取指定score范围内的元素
zdiff、zinter、zunion:求差集,交集,并集 - 练习:zadd stus 76 Miles 78 Jerry 82 Rose 85 Jack 89 Lucy 92 Amy 95 Tom
1.删除Tom同学
2.获取Amy同学的分数
3.获取Rose同学的排名
4.查询80分以下的有几个学生
5.给Amy同学加2分
6.查出成绩前3名的同学
7.查出成绩80分以下的所有同学
- 命令:
- set类型命令
- 命令
sadd key member
srem key member
scard key
sismember key member
smembers
sinter key1 key2
sdiff key1 key2
sunion key1 key2 - 练习
将下列数据用redis的set集合存储
张三的好友有:李四,王五,赵六
李四的好友有:王五,麻子,二狗
利用set的命令实现下列功能:
1.计算张三的好友有几人
2.计算张三和李四有哪些共同好友
3.查询那些人是张三的好友却不是李四的好友
4.查询张三和李四的好友总共有那些人
5.判断李四是否是张三的好友
6.将李四从张三好友列表中移除
- 命令
- list
- 命令
lpush key element…
lpop key element…
rpush key element…
rpop key element…
lrange key star end
blpop key element…
brpop key element…
- 命令
- GEO数据结构
- 描述
GEO就是Geolocation的简写,代表地理坐标 - 命令
geoadd:添加一个地理空间信息,包含:经度(longitude),纬度(latitude),值(member)
geodist:计算指定的两个点之间的距离并返回
geohash:指定member的坐标转为hash字符串形式并返回
geopos:返回指定member的坐标
georadius:指定圆心,半径,找到该圆内所有的member,并按照与圆心的距离排序后返回,6.2以后已废弃
geosearch:在指定范围内搜索member,并按照与指定点之间的距离排序后返回,范围可以是圆形或矩形。6.2新功能
geosearchstore:与geosearch功能一致,不过可以把结果存储到一个指定的key。6.2新功能
- 描述
- BitMap用法
- 描述
redis中利用string类型数据结构实现BitMap,因此最大上线是512M,转换为bit则是2^32个bit位 - 命令
setbit:向指定位置(offset)存入一个0或1
getbit:向指定位置(offset)获取bit值
bitcount:统计bitmap中值为1的bit位数量
bitfield:操作(查询,修改,自增)BitMap中bit数组中指定位置(offset)的值
bitfield_ro:获取bitmap中bit数组,并以十进制形式返回
bitop:将多个bitmap的结果做位运算(与,或,异或)
bitpos:查找bit数组中指定范围内第一个0或者1出现的位置
- 描述
- HyperLogLog
- 描述
- 命令
- 持久化
- RDB
- 描述:rdb全称redis database backup file(Redis数据备份文件),也叫做redis数据快照,简单来说就是把内存中的所有
数据都记录到磁盘中,当redis实例故障重启后,从磁盘读取快照文件,恢复数据 - 命令
- save
- bgsave
- redis内部触发RDB的机制,可以在redis.conf文件中找到,如下
save 900 1 # 900秒内,如果至少有1个key被修改,则执行bgsave,如果save ""则表示禁用RDB
save 300 10
save 60 10000 - RDB的其它配置也可以在redis.conf文件中配置
rdbcompression yes
dbfilename dump.rdb
dir ./ - 原理:bgsave开始时会fork主进程得到子进程,子进程共享主进程的内存数据,完成fork后读取内存数据并写入RDB文件,子进程写新的RDB文件,替换旧的RDB文件
fork采用的是copy-on-write技术
当主进程执行写操作时,则会拷贝一份数据,执行写操作 - 缺点
rdb执行间隔时间长,两次rdb之间写入数据有丢失的风险
fork子进程,压缩,写出rdb文件都比较耗时
- 描述:rdb全称redis database backup file(Redis数据备份文件),也叫做redis数据快照,简单来说就是把内存中的所有
- AOF
描述
AOF全称Append Only File(追加文件)。redis处理的每一个写命令都会记录在AOF文件,可以看作时命令日志文件
AOF默认是关闭,需要修改redis.conf配置文件来开启AOF
appendonly yes
appendfilename “appendonly.aof”刷盘策略
appendfsync everysec # always everysec noAOF重写机制
因为是记录命令,AOF文件会比RDB文件大的多,而且AOF会记录对同一个key的多次写操作,但只有最后一次写操作才有意义。
通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果
redis.conf配置:# aof文件比上次文件增长超过多少百分比则触发重写 auto-aof-rewrite-percentage 100 # aof文件体积最小多大以上可以触发重写 auto-aof-rewrite-min-size 64m
- RDB
- 创建
- 创建名为users的队列,并向其中发送一个消息,内容是:{name=jack,age=21},并且使用redis自动生成ID
RDB和AOF有确定比较
RDB | AOF | |
---|---|---|
持久化方式 | 定时对整个内存做快照 | 记录每一次执行写的命令 |
数据完整性 | 不完整,两次备份之间会丢失 | 相对完整,取决于刷盘策略 |
文件大小 | 会有压缩,文件体积小 | 记录命令,文件体积很大 |
宕机恢复速度 | 很快 | 慢 |
数据恢复优先级 | 低,因为数据完整性不如AOF | 高,数据完整性比较高 |
系统资源占用情况 | 高,大量的cpu,内存消耗 | 低,主要是磁盘IO,但是AOP重写时会占用cpu和内存资源 |
使用场景 | 可容忍数分钟的数据丢失,追求更快的启动速度 | 对数据安全性要求较高的场景 |