文档章节

Redis数据持久化

乐搏学院
 乐搏学院
发布于 2017/04/17 13:43
字数 2143
阅读 12
收藏 0

Redis是个支持持久化的内存数据库,redis需要经常将内存中的数据同步到磁盘来保证持久化。

 

1、RDB方式(Snapshotting默认快照方式):

1.1)配置:

1

2

3

save 900 1       #在900秒(15分钟)之后,如果至少有1个key发生变化,则dump内存快照。

save 300 10      #在300秒(5分钟)之后,如果至少有10个key发生变化,则dump内存快照。

save 60 10000    #在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照。

 

1.2)工作原理:

 

1.2.1)Redis使用fork函数复制一份当前进程(父进程)的副本(子进程);

1.2.2)父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件;

1.2.3)当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此一次快照操作完成。

 

1.3)查看dump.rdb:

1

2

3

4

127.0.0.1:7000> config get dir

1) "dir"

2) "/usr/local/redis/db"

127.0.0.1:7000>

 

1.4)优点:

1.4.1)RDB是个非常紧凑的文件,保存了redis在某个时间点上的数据集,使得我们可以通过定时备份RDB文件来实现Redis数据库备份和灾难恢复,也可以将其传送到其他的数据中心用于保存。

1.4.2)RDB可以最大化redis的性能,执行RDB持久化时只需要fork一个子进程,并由子进程进行持久化工作,父进程不需要处理任何磁盘I/O操作。

1.4.3)RDB在恢复大数据集时比AOF要快,启动效率要高许多。

1.4.4)RDB文件是经过压缩(可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式,所以占用的空间会小于内存中的数据大小,更加利于传输。

 

1.5)缺点:

1.5.1)每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步增数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。

1.5.2)快照方式是在一定间隔时间做一次的,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改,有一些数据丢失的风险。

1.5.2)client的save或者bgsave命令通知redis做一次快照持久化不推荐。

1

2

3

127.0.0.1:7000> save

OK

127.0.0.1:7000>

原因:save操作是在主线程中保存快照的,由于redis是用一个主线程来处理所有 client的请求,这种方式会阻塞所有client请求。所以不推荐使用。

 

2、Append-only file(缩写aof)的方式:

2.1)配置

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

appendonly yes  

#开启aof

appendfilename "appendonly.aof"  

#名字

# appendfsync always   

# 每次执行写入都会执行同步,最安全也最慢

appendfsync everysec   

# 每秒执行一次同步操作

# appendfsync no 

#不主动进行同步操作,而是完全交由操作系统来做(即每30秒一次),最快也最不安全。

#配置写入AOF文件后,要求系统刷新硬盘缓存的机制

auto-aof-rewrite-percentage 100  

# 当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF文件大小为依据

auto-aof-rewrite-min-size 64mb   

# 允许重写的最小AOF文件大小

2.2)工作原理:

 

2.2.1)redis调用fork ,现在有父子两个进程

2.2.2)子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令

2.2.3)父进程继续处理client请求,除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。

2.2.4.)当子进程把快照内容写入已命令方式写到临时文件中后,子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。

2.2.5)现在父进程可以使用临时文件替换老的aof文件,并重命名,后面收到的写命令也开始往新的aof文件中追加。

 

2.3)查看aof

1

2

3

4

5

6

7

8

9

127.0.0.1:7000> config get dir

1) "dir"

2) "/usr/local/redis/db"

127.0.0.1:7000>

[root@redis1 db]# ll

总用量 8

-rw-r--r-- 1 root root 146 2月   1 08:36 appendonly.aof

-rw-r--r-- 1 root root  74 2月   1 09:20 dump.rdb

[root@redis1 db]#

2.4)优点:

2.4.1)该机制可以带来更高的数据安全性,即数据持久性。

2.4.2)由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

2.4.3)如果日志过大,Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

2.4.4) AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,也可以通过该文件完成数据的重建。

 

2.5:缺点:

2.5.1)对于相同数量的数据集而言,AOF文件通常要大于RDB文件,持久化文件会变的越来越大。

2.5.2) 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。

 

3、其它

虚拟内存方式和diskstore方式。:(不建议,而且虚拟内存据说2.4版本后弃用,diskstore也不常用)

相关配置

1

2

3

4

5

6

7

8

9

10

11

12

13

持久化文件会变的越来越大。

vm-enabled yes          

#开启vm功能

vm-swap-file /tmp/redis.swap   

#交换出来的value保存的文件路径/tmp/redis.swap

vm-max-memory 1000000  

#redis使用的最大内存上限,超过上限后redis开始交换value到磁盘文件中

vm-page-size 32        

#每个页面的大小32个字节

vm-pages 134217728     

#最多使用在文件中使用多少页面,交换文件的大小 = vm-page-size * vm-pages

vm-max-threads 4       

#用于执行value对象换入换出的工作线程数量,0表示不使用工作线程

 

总结:

1、Redis允许同时开启AOF和RDB,既保证了数据安全又使得进行备份等操作十分容易。重新启动Redis后Redis会使用AOF文件来恢复数据,因为AOF方式的持久化可能丢失的数据更少。

 

 

2、读写分离 通过复制可以实现读写分离以提高服务器的负载能力。在常见的场景中,读的频率大于写,当单机的Redis无法应付大量的读请求时(尤其是较耗资源的请求,比如SORT命令等)可以通过复制功能建立多个从数据库,主数据库只进行写操作,而从数据库负责读操作。

 

3、从数据库持久化 持久化通常相对比较耗时,为了提高性能,可以通过复制功能建立一个(或若干个)从数据库,并在从数据库中启用持久化,同时在主数据库禁用持久化。当从数据库崩溃时重启后主数据库会自动将数据同步过来,所以无需担心数据丢失。而当主数据库崩溃时,需要在从数据库中使用SLAVEOF NO ONE命令将从数据库提升成主数据库继续服务,并在原来的主数据库启动后使用SLAVEOF命令将其设置成新的主数据库的从数据库,即可将数据同步回来。

如有不妥,欢迎指正!

 

登录乐搏学院官网http://www.learnbo.com/

或关注我们的官方微博微信,还有更多惊喜哦~

本文出自 “永不放弃!任志远” 博客,转载请与作者联系!

© 著作权归作者所有