• 欢迎访问显哥博客,本网站纯属学习技术,绝无商业用途,欢迎小伙伴们共同学习!研究技术!QQ:52249909 加我QQ
  • 世界75亿人,这么小的概率,能认识你,是我一生的幸运,不妨加个QQ接触一下:52249909 加我QQ

Redis持久化与数据类型【显哥出品,必为精品】

Redis lixian 1年前 (2020-07-04) 386次浏览 0个评论 扫描二维码
文章目录[隐藏]

一、持久化概念

1.什么是持久化

持久化:就是将内存中的数据,写入到磁盘上,并且永久存在的。

2.Redis持久化模式

1.RDB模式
2.AOF模式

3.RDB模式

可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。
1)工作模式


1)默认情况下,Redis保存数据集快照到磁盘,名为dump.rdb的二进制文件。你可以设置让Redis在N秒内至少有M次数据集改动时保存数据集,或者你也可以手动调用SAVE或者BGSAVE命令。

2)在上文中我们已经在配置文件中做过对应的配置:
例如,这个配置会让Redis在每个60秒内至少有1000次键改动时自动转储数据集到磁盘:
save 60 1000

3)当 Redis 需要保存 dump.rdb 文件时,服务器执行以下操作:

Redis 调用 fork() ,同时拥有父进程和子进程。
子进程将数据集写入到一个临时的 RDB 文件中。当子进程完成对新 RDB 文件的写入时, Redis 用新RDB 文件替换原来的 RDB 文件,并删除旧的 RDB 文件。
4)这种方式使得 Redis 可以从写时复制机制中获益。


2)配置RDB持久化

[root@db01 redis]# vim /service/redis/6379/redis.conf 
bind 127.0.0.1 172.16.1.51
port 6379
daemonize yes
pidfile /service/redis/6379/redis_6379.pid
loglevel notice
logfile "/service/redis/6379/redis.log"
#requirepass 123

#持久化数据文件存储位置
dir /etc/redis/6379
#rdb持久化数据文件名
dbfilename dump.rdb
#900秒(15分钟)内有1个更改
save 900 1
#300秒(5分钟)内有10个更改
save 300 10
#60秒(1分钟)内有10000个更改
save 60 10000

3)RDB持久化优点


1)RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。例如,你可能想要每小时归档最近24小时的RDB文件,每天保存近30天的RDB快照。这允许你很容易的恢复不同版本的数据集以容灾。
2)RDB非常适合于灾难恢复,作为一个紧凑的单一文件,可以被传输到远程的数据中心。
3)RDB最大化了Redis的性能,因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程,由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。
4)RDB在重启保存了大数据集的实例时比AOF要快。

4)RDB持久化缺点
1)当你需要在Redis停止工作(例如停电)时最小化数据丢失,RDB可能不太好。你可以配置不同的保存点(save point)来保存RDB文件(例如,至少5分钟和对数据集100次写之后,但是你可以有多个保存点)。然而,你通常每隔5分钟或更久创建一个RDB快照,所以一旦Redis因为任何原因没有正确关闭而停止工作,你就得做好最近几分钟数据丢失的准备了。

2)RDB需要经常调用fork()子进程来持久化到磁盘。如果数据集很大的话,fork()比较耗时,结果就是,当数据集非常大并且CPU性能不够强大的话,Redis会停止服务客户端几毫秒甚至一秒。AOF也需要fork(),但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。
5)总结
优点:速度快,适合于用作备份,主从复制也是基于RDB持久化功能实现的。
缺点:会有数据丢失、导致服务停止几秒

4.AOF模式

AOF(append only file)只追加文件,记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾。

1)配置AOF持久化
[root@db01 6379]# vim redis.conf 
bind 127.0.0.1 172.16.1.51
port 6379
daemonize yes
pidfile /service/redis/6379/redis_6379.pid
loglevel notice
logfile "/service/redis/6379/redis.log"

#是否打开AOF日志功能
appendonly yes/no
#每一条命令都立即同步到AOF(以下三条选一个,最好always)
appendfsync always
#每秒写一次
appendfsync everysec
#写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到AOF
appendfsync no

2)AOF优点


1)使用AOF Redis会更具有可持久性(durable):你可以有很多不同的fsync策略:没有fsync,每秒fsync,每次请求时fsync。使用默认的每秒fsync策略,写性能也仍然很不错(fsync是由后台线程完成的,主线程继续努力地执行写请求),即便故障你也就仅仅只损失一秒钟的写数据。
2)AOF日志是一个追加文件,所以不需要定位,在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof工具也可以很轻易的修复。
3)当AOF文件变得很大时,Redis会自动在后台进行重写。重写是绝对安全的,因为Redis继续往旧的文件中追加,使用创建当前数据集所需的最小操作集合来创建一个全新的文件,一旦第二个文件创建完毕,Redis就会切换这两个文件,并开始往新文件追加。
4)AOF文件里面包含一个接一个的操作,以易于理解和解析的格式存储。你也可以轻易的导出一个AOF文件。例如,即使你不小心错误地使用FLUSHALL命令清空一切,如果此时并没有执行重写,你仍然可以保存你的数据集,你只要停止服务器,删除最后一条命令,然后重启Redis就可以。

3)AOF持久化缺点

1)对同样的数据集,AOF文件通常要大于等价的RDB文件。
2)AOF可能比RDB慢,这取决于准确的fsync策略。通常fsync设置为每秒一次的话性能仍然很高,如果关闭fsync,即使在很高的负载下也和RDB一样的快。不过,即使在很大的写负载情况下,RDB还是能提供能好的最大延迟保证。
3)在过去,我们经历了一些针对特殊命令(例如,像BRPOPLPUSH这样的阻塞命令)的罕见bug,导致在数据加载时无法恢复到保存时的样子。这些bug很罕见,我们也在测试套件中进行了测试,自动随机创造复杂的数据集,然后加载它们以检查一切是否正常,但是,这类bug几乎不可能出现在RDB持久化中。为了说得更清楚一点:Redis AOF是通过递增地更新一个已经存在的状态,像MySQL或者MongoDB一样,而RDB快照是一次又一次地从头开始创造一切,概念上更健壮。
但是
1)要注意Redis每次重写AOF时都是以当前数据集中的真实数据从头开始,相对于一直追加的AOF文件(或者一次重写读取老的AOF文件而不是读内存中的数据)对bug的免疫力更强。
2)我们还没有收到一份用户在真实世界中检测到崩溃的报告。

4)AOF持久化优缺点总结
优点:可以最大程度保证数据不丢失
缺点:日志记录量级比较大

5.RDB与AOF

1)应该用哪一个


1)一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性, 你应该同时使用两种持久化功能。

2)如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。

3)有很多用户单独使用AOF,但是我们并不鼓励这样,因为时常进行RDB快照非常方便于数据库备份,启动速度也较之快,还避免了AOF引擎的bug。

4)个人感触:在企业中,通常都使用RDB来做持久化,因为一般redis是在做MySQL的缓存,就算缓存数据丢失,真实的数据还是在MySQL中,之所以用缓存是为了速度,性能而考虑,所以还是建议使用RDB持久化,相对来说会好一些,除非专门用redis来做一个key:value的数据库,而且数据很重要,那么可以考虑使用AOF

2)AOF重写


1)因为 AOF 的运作方式是不断地将命令追加到文件的末尾,所以随着写入命令的不断增加, AOF 文件的体积也变得越来越大。
举个例子,如果你对一个计数器调用了 100 次 INCR ,那么仅仅是为了保存这个计数器的当前值, AOF 文件就需要使用 100 条记录。然而在实际上,只使用一条 SET 命令已经足以保存计数器的当前值了,其余 99 条记录实际上都是多余的。

2)为了处理这种情况, Redis 支持一种有趣的特性:可以在不断服务客户端的情况下,对 AOF 文件进行重建。执行 BGREWRITEAOF 命令, Redis 将生产一个新的 AOF 文件,这个文件包含重建当前数据集所需的最少命令。

3)执行持久化


1)在版本号大于等于 2.4 的 Redis 中, BGSAVE 执行的过程中,不可以执行 BGRWRITEAOF 。 反过来说,在 BGRWRITEAOF 执行的过程中,也不可以执行 BGSAVE 。
2)这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。如果 BGSAVE 正在执行,并且用户显示地调用 BGRWRITEAOF 命令,那么服务器将向用户回复一个 OK 状态,并告知用户, BGRWRITEAOF 已经被预定执行; 一旦 BGSAVE 执行完毕, BGRWRITEAOF 就会正式开始。
3)当 Redis 启动时,如果 RDB 持久化和 AOF 持久化都被打开了,那么程序会优先使用 AOF 文件来恢复数据集,因为 AOF 文件所保存的数据通常是最完整的。

4)备份策略

1)Redis 对于数据备份是非常友好的,因为你可以在服务器运行的时候对 RDB 文件进行复制: RDB 文件一旦被创建,就不会进行任何修改。

2)当服务器要创建一个新的 RDB 文件时,它先将文件的内容保存在一个临时文件里面,当临时文件写入完毕时,程序才使用临时文件替换原来的 RDB 文件。

3)这也就是说,无论何时, 复制 RDB 文件都是绝对安全的。



以下是我们的建议:
1)创建一个定期任务(cron job), 每小时将一个 RDB 文件备份到一个文件夹, 并且每天将一个 RDB 文件备份到另一个文件夹。

2)确保快照的备份都带有相应的日期和时间信息, 每次执行定期任务脚本时, 使用 find 命令来删除过期的快照: 比如说, 你可以保留最近 48 小时内的每小时快照, 还可以保留最近一两个月的每日快照。

3)至少每天一次, 将 RDB 备份到你的数据中心之外, 或者至少是备份到你运行 Redis 服务器的物理机器之外。

5)RDB持久化高级配置

#编辑配置文件
[root@db01 redis]# vim /service/redis/6379/redis.conf
#后台备份进程出错时,主进程停不停止写入? 主进程不停止容易造成数据不一致
stop-writes-on-bgsave-error yes
#导出的rdb文件是否压缩 如果rdb的大小很大的话建议这么做
rdbcompression yes 
#导入rbd恢复时数据时,要不要检验rdb的完整性 验证版本是不是一致
rdbchecksum yes

6)AOF持久化高级配置

#编辑配置文件
[root@db01 redis]# vim /service/redis/6379/redis.conf
#正在导出rdb快照的过程中,要不要停止同步aof
no-appendfsync-on-rewrite yes/no
#aof文件大小比起上次重写时的大小,增长率100%时重写,缺点:业务开始的时候,会重复重写多次
auto-aof-rewrite-percentage 100
#aof文件,至少超过64M时,重写
auto-aof-rewrite-min-size 64mb

7)持久化命令

#RDB手动持久化
	save
	bgsave
	
#AOF手动重写命令
	BGREWRITEAOF

二、Redis数据类型

1.strings(字符)类型

1)添加数据
#添加一个KEY
127.0.0.1:6379> set k1 v1
OK

#添加多个key
127.0.0.1:6379> mset k2 v2 k3 v3 k4 v4
OK

#先查看再修改
127.0.0.1:6379> GETSET k1 v11111
"v1"
127.0.0.1:6379> GETSET k1 v22222
"v11111"

#递增(计数器)
127.0.0.1:6379> set num 1
OK
127.0.0.1:6379> INCR num
(integer) 2
。。。
127.0.0.1:6379> INCR num
(integer) 10
127.0.0.1:6379> INCRBY num 1000
(integer) 1010

#递减
127.0.0.1:6379> DECR num
(integer) 12009
127.0.0.1:6379> DECRBY num 1000
(integer) 11009
2)查询数据
#查看key
127.0.0.1:6379> get k1
"v1"

#查看key长度
127.0.0.1:6379> get num
"10009"
127.0.0.1:6379> STRLEN num
(integer) 5

#查看指定长度的内容
127.0.0.1:6379> GETRANGE num 0 3
"1000"
127.0.0.1:6379> GETRANGE num 0 2
"100"
127.0.0.1:6379> GETRANGE num 0 4
"10009"
127.0.0.1:6379> GETRANGE num 0 -1
"10009"

#查看生存时间
127.0.0.1:6379> TTL num
"-1"

#查看多个值
127.0.0.1:6379> mget k1 k2 k3 k4
1) "v1"
2) "v2"
3) "v3"
4) "v4"
3)修改数据
#修改key
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> set k1 v10000
OK
127.0.0.1:6379> get k1
"v10000"

#修改某一位置的值
127.0.0.1:6379> get k1
"v10000"
127.0.0.1:6379> SETRANGE k1 1 2
(integer) 6
127.0.0.1:6379> get k1
"v20000"

#追加数据到key
127.0.0.1:6379> APPEND k1 123142453
(integer) 15
127.0.0.1:6379> get k1
"v20000123142453"
127.0.0.1:6379> 
4)删除数据
127.0.0.1:6379> del k1
(integer) 1

127.0.0.1:6379> del EX num k3 k4
(integer) 4

2.Hash类型

1)添加数据
#设置单列数据
127.0.0.1:6379> hset teacher id 1
(integer) 1
127.0.0.1:6379> hset teacher name qls
(integer) 1

#设置多列
127.0.0.1:6379> hmset teacher id 1 name qls sex nv age 78
OK
2)查看数据
#查看key所有数据
127.0.0.1:6379> HGETALL teacher
1) "id"
2) "1"
3) "name"
4) "qls"
5) "sex"
6) "nv"
7) "age"
8) "78"

#查看指定列数据
127.0.0.1:6379> HGET teacher name
"qls"
127.0.0.1:6379> HGET teacher id
"1"

#查看指定多列数据
127.0.0.1:6379> HMGET teacher id name sex
1) "1"
2) "qls"
3) "nv"
3)修改数据
#修改某一列的值
127.0.0.1:6379> HSET teacher id 2
(integer) 0
127.0.0.1:6379> HGETALL teacher
1) "id"
2) "2"
3) "name"
4) "qls"
5) "sex"
6) "nv"
7) "age"
8) "78"

#修改hash类型递增
127.0.0.1:6379> HGETALL teacher
1) "id"
2) "2"
3) "name"
4) "qls"
127.0.0.1:6379> HINCRBY teacher id 1
(integer) 3
127.0.0.1:6379> HGETALL teacher
1) "id"
2) "3"
3) "name"
4) "qls"
4)删除数据
#删除key中的某一列
127.0.0.1:6379> HGETALL teacher
1) "id"
2) "5"
3) "name"
4) "qls"
5) "sex"
6) "nv"
7) "age"
8) "78"
127.0.0.1:6379> hdel teacher id name
(integer) 2
127.0.0.1:6379> HGETALL teacher
1) "sex"
2) "nv"
3) "age"
4) "78"

#删除key
127.0.0.1:6379> del teacher
(integer) 1
5)查看数据是什么类型
127.0.0.1:6379> type k2
string
127.0.0.1:6379> type student
hash

本站博主 , 版权所有丨如未注明 , 均为原创
转载请注明原文链接:Redis持久化与数据类型【显哥出品,必为精品】
喜欢 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到