Redis 数据类型和持久化

27`

已于 2023-02-15 18:16:55 修改

阅读量117

点赞数

文章标签： redis 缓存数据库

于 2023-02-15 18:01:59 首次发布

本文链接：https://blog.csdn.net/qq_36236705/article/details/129045379

版权

一、数据类型

字符串（String）

String是redis最基本的类型，一个key对应一个value。

String类型是二进制安全的，意思是redis的string可以包含任何数据，比如jpg图片或者序列化的对象。

String类型是redis最基本的数据类型，一个redis中字符串value最多可以是512M

List列表

Redis中的List其实就是双端链表

使用List结构，我们可以轻松地实现最新消息排队功能（比如新浪微博的TimeLine）。List的另一个应用就是消息队列，可以利用List的 PUSH 操作，将任务存放在List中，然后工作线程再用 POP 操作将任务取出进行执行。
Redis还提供了操作List中某一段的api，你可以直接查询，删除List中某一段的元素。

        使用列表的技巧
                lpush+lpop=Stack(栈)
                lpush+rpop=Queue（队列）
                lpush+ltrim=Capped Collection（有限集合）
                lpush+brpop=Message Queue（消息队列）

set 集合

Redis 的 Set 是 String 类型的无序集合。

集合成员是**不可重复的**
Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)
使用场景

标签（tag）,给用户添加标签，或者用户给消息添加标签，这样有同一标签或者类似标签的可以给推荐关注的事或者关注的人。
点赞，或点踩，收藏等，可以放到set中实现

Hash散列

Redis hash 是一个 string 类型的 field(字段) 和 value(属性) 的映射表，hash 特别适合用于存储对象。

一个hash可以存多个key-value，类似一个对象的多个字段和属性

使用场景：

缓存：能直观，相比string更节省空间，的维护缓存信息，如用户信息，视频信息等。

Zset有序集合

Redis 有序集合和集合一样基本一致

区别：

**每个元素都会关联一个 double 类型的权重参数(score)，**使得集合中的元素能够按score进行有序排列。
特点：

有序集合的成员是唯一的,但分数(score)却可以重复。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
使用场景：

排行榜：有序集合经典使用场景。例如小说视频等网站需要对用户上传的小说视频做排行榜，榜单可以按照用户关注数，更新时间，字数等打分，做排行。
成绩排行：比如一个存储全班同学成绩的sorted set，其集合value可以是同学的学号，而score就可以是其考试得分，形成了按成绩排序。
权重分配：可以用sorted set来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行

详细使用方法请参考这个地址: Redis 字符串(String) | 菜鸟教程

二、Redis 两种持久化方式

1、RDB

Redis会定期保存数据快照至一个RBD文件中华，并在启动时自动加载RDB文件,恢复之前保存的数据,可以在配置文件中配置Redis进行快照保存的时机:

        save [seconds] [changes]

        意为在[seconds]秒内如果发生了[changes]次数据修改，则进行一次RDB快照保存，例如：

         save 60 100

会让Redis每60秒检查一次数据变更情况，如果发生了100次或以上的数据变更，则进行RDB快照保存。可以配置多条save指令，让Redis执行多级的快照保存策略。Redis默认开启RDB快照。

RDB方案优点

        对性能影响最小,如前文所述,Redis在保存RBD快照时会Fork出子进程进行,几乎不能影响Redis处理客户端请求的效率。
        每次快照会生成一个完整的数据快照文件,所以可以辅以其他手段保存多个时间点的快照(例如吧每天0点的快照备份至其他存储媒介中)，作为非常可靠的灾难恢复手段
        使用RDB文件进行数据恢复比使用AOF要快很多
        RDB方案缺点

快照是定期生成的，所以在Redis crash（崩溃）时或多或少会丢失一部分数据。

如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力。

2、AOF

采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。AOF默认是关闭的，如要开启，进行如下配置：

appendonly yes

AOF提供了三种fsync配置，always/everysec/no，通过配置项[appendfsync]指定：

appendfsync no：不进行fsync，将flush文件的时机交给OS（操作系统）决定，速度最快
appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢
appendfsync everysec：折中的做法，交由后台线程每秒fsync一次

随着AOF不断地记录写操作日志，因为所有的操作都会记录，所以必定会出现一些无用的日志。大量无用的日志会让AOF文件过大，也会让数据恢复的时间过长。不过Redis提供了AOF rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。
AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
上面两行配置的含义是，Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewrite。同时如果增长的大小没有达到64mb，则不会进行rewrite。
AOF优点：

最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据

AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。

AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。