Redis的五种数据结构及持久化

一、Redis数据结构及应用场景

1.字符串string

键值对：key-value
字符串常用操作
SET key value //存入字符串键值对
MSET key value [key value …] //批量存储字符串键值对
SETNX key value //存入一个不存在的字符串键值对
GET key //获取一个字符串键值
MGET key [key …] //批量获取字符串键值
DEL key [key …] //删除一个键
EXPIRE key seconds //设置一个键的过期时间(秒)原子加减
INCR key //将key中储存的数字值加1
DECR key //将key中储存的数字值减1
INCRBY key increment //将key所储存的值加上increment
DECRBY key decrement //将key所储存的值减去decrement

2.哈希hash

对象缓存
HMSET user 1:name zhangsan 1:balance 1888
HMGET user 1:name 1:balance
HMSET food 1:apple 20 1:banana 18
优点
1）同类数据归类整合储存，方便数据管理

3.list集合

List常用操作
LPUSH key value [value …] //将一个或多个值value插入到key列表的表头(最左边)
RPUSH key value [value …] //将一个或多个值value插入到key列表的表尾(最右边)
LPOP key //移除并返回key列表的头元素
RPOP key //移除并返回key列表的尾元素
应用场景
队列、栈

4.set集合

Set常用操作
SADD key member [member …] //往集合key中存入元素，元素存在则忽略，若key不存在则新建
SREM key member [member …] //从集合key中删除元素
SMEMBERS key //获取集合key中所有元素
SCARD key //获取集合key的元素个数
集合算法
交集、差集、合集
应用场景
抽奖、微博、微信关注模型

5.有序集合Zset

ZSet常用操作
ZADD key score member [[score member]…] //往有序集合key中加入带分值元素
ZREM key member [member …] //从有序集合key中删除元素
ZSCORE key member //返回有序集合key中元素member的分值
ZINCRBY key increment member //为有序集合key中元素member的分值加上increment
ZCARD key //返回有序集合key中元素个数
ZRANGE key start stop [WITHSCORES] //正序获取有序集合key从start下标到stop下标的元素
ZREVRANGE key start stop [WITHSCORES] //倒序获取有序集合key从start下标到stop下标的元素
Zset集合操作
ZUNIONSTORE destkey numkeys key [key …] //并集计算
ZINTERSTORE destkey numkeys key [key …] //交集计算

二、Redis持久化

因为Redis是将数据保存在内存中，为了防止Redis宕机后，恢复数据，则需要对数据的持久化。

1.RDB快照

将Redis某个时刻的数据以二进制文件的形式进行保存。
在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
而进行保存的方式又分为两种：
1.save
save的方式是由主线程来执行，所以会阻塞Redis的其他命令
2.bgsave
bgsave的方式是由主线程fork的子线程执行，因此不会阻塞Redis的其他命令

2.AOF

AOF持久化：将Redis上执行的每条修改数据的指令记录进文件appendonly.aof中，需要恢复数据时，按照文件中记录的命令执行一遍，就能恢复数据。

3.混合持久化

RDB快照持久化方式：因为是每段时间进行一次快照，因此会丢失部分数据
AOF持久化：会将Redis中数据的修改指令全部记录，再全部执行。导致记录文件大，恢复数据耗时长的缺点。
针对上面的问题，再Redis4.0提出了混合持久化方式。具体方案如下：
如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一 起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。 于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。