FWQ
分析Redis数据持久化、数据备份、数据的故障恢复
分析Redis数据持久化、数据备份、数据的故障恢复 0浏览 收藏 小伙伴们有没有觉得学习数据库很有意思?有意思就对了!今天就给大家带来《分析Redis数据持久化、数据备份、数据的故障恢复》,以下内容将会涉及到Redis、数据、故障,若是在学习中对其中部分知识点有疑问,或许看了本文就能帮到你! 前言 缓存由于其高并发和高性能的特性,已经在项目中被广泛使用。在读取持久化,数据备份,数据的故障恢复方面你究竟了解多少呢? 1.redis持久化的意义—-redis故障恢复 在实际的生产环境中,很可能会遇到redis突然挂掉的情况,比如redis的进程死掉了、电缆被施工队挖了(支付宝例子)等等,总之一定会遇到各种奇葩的现象导致redis死掉,这时候放在redis内存中的数据就会全部丢失,这些数据可能服务很多的系统或者服务,当然,我们可以重新启动redis,重启之后,如果redis没有持久化,redis中的数据就会全部丢失。 如果通过持久化将数据搞一份到磁盘,然后定期的同步和备份到云存储服务上去,那么就可以保证数据不会全部丢失,还是可以恢复一部分数据的。 2.持久化的两大机制(RDB和AOF) RDB:对redis数据执行周期性的持久化 AOF:将每条命令写入日志,以append-only的模式写入一个日志文件中,在redis重启的时候,可以通过回放AOF的写入指令来重新构建整个数据集 是否实用持久化要看具体的业务场景: 如果只是想让redis仅仅作为纯内存的缓存,那么可以禁止RDB和AOF。 故障恢复大致思路: 通过RDB或AOF,都可以将redis内存中的数据持久化到磁盘上来,然后可以将数据备份到阿里云,如果redis挂了,服务器中内存和磁盘的数据就都丢了,这时候可以将阿里云中的备份文件拷贝至指定目录下,然后重启redis,redis就会自动根据持久化数据文件去恢复内存中的数据,继续对外提供服务。如果同时室友了RDB和AOF两种持久化机制,那么在重启的时间建议使用AOF的方式重新构建数据,因为AOF中的数据更加完整。 3.剖析RDB和AOF RDB:早上7点,这个时候redis 中有500条数据,这个时候redis会在一定周期内生成一个RDB快照文件,等到了9点的时候redis中有8000条数据,这个时候又在一定的周期内生成了另一个RDB快照文件,这就是RDB持久化机制。 AOF:redis 中每写入一条指令,就会把这条指令更新到磁盘中的文件中。然而在现代操作系统中,写文件不是直接写磁盘,会先写进os cache,然后在一定时间内再从os cache刷入disk file,对于AOF来说每隔一秒(可配置)调用一次操作系统饿fsync操作强制将os cache中的数据刷入磁盘文件中。但是redis内存中的数据也不是***增长的,它是定期的根据LRU算法清理一些不常用的数据,这样才能保证AOF不会***增长,但是如果LRU的清理速度比不上AOF的膨胀速度的时候,这时候当AOF大到一定程度就会进行AOF rewrite操作。AOF rewrite操作就会基于当时redis内存中的数据来重新构造一个更小的AOF文件,然后将旧的AOF文件删除。 简单的说,假设redis限定了只能存放10G数据,这时候不断的在redis中写入数据,当达到了10G的数据量的时候,这时候根据LRU清理了一些不常用的数据,清理了5G,这时候又写了5G,这时候AOF文件记录了15G的数据相关的写入指令,假如这个时候AOF已经膨胀了,这个时候redis进行AOF…