Redis持久化实现及使用选择

末蓝、 2022-01-15 01:29 199阅读 0赞

# Redis #

这个引用一下官文

> Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

也就是我们常说的NoSQL数据库的一种，和Memcached一样，是一种基于内存的非关系型数据库。看到基于内存就知道至少知道了它的一个优点，快。当然也是因为基于内存的，所以才写了这篇文章，持久化，不然其中存储的数据丢失了怎么办。虽然这说的很片面了，不过本质是这样，我们有很多的理由需要对`Redis`中的数据做做持久化。

# Redis为什么要持久化 #

因为Redis运行在内存中，数据都是缓存在内存中。（以下部分文字为引用）

*  数据既然存储在内存中，那么为了避免进程退出导致数据的永久丢失，需要定期将Redis中的数据以某种形式（数据或命令）从内存保存到硬盘。当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。  
    所以，为了让数据能够长期保存，就要将 Redis 放在缓存中的数据做持久化存储。

另外我们经常会听到，我们这个架构XX需要满足高可用性。什么是高可用呢？

*  在Web服务器中，高可用是指服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服务（99.9%、99.99%、99.999%等等）。  
    但是在Redis语境中，高可用的含义似乎要宽泛一些，除了保证提供正常服务（如主从分离、快速容灾技术等），还需要考虑数据容量的扩展、数据安全不会丢失等。
 *  在Redis中，实现高可用的技术主要包括持久化、复制、哨兵和集群。持久化呢，恰好是最简单的高可用方法，有时甚至不被归为高可用的手段，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。但是它同样重要。

# 持久化选项 #

`Redis`提供了两种不同的持久化方法来将数据存储到硬盘里。一种方法是**快照法**（`RDB`），它可以将存在于某一时刻的所有数据都写入硬盘里面。  
另一种方法叫**只追加文件法**（`append-only file,AOF`）,它会在执行写命令的时候，将被执行的命令复制到硬盘里面，这两种持久化方法既可以同时使用，也可以单独使用，也可以都不使用，选择哪种还要根据数据源以及实际应用决定。

##### 1.快照持久化 - RDB #####

Redis 通过创建快照来获得存储再内存里面的某个时间节点上的数据副本，创建以后，可以对快照备份，可以迅速将这部分数据在当前服务器重启后使用或者在其他服务器使用。  
这东西说的通俗点就和我们玩的单机游戏保存进度一样，我玩到第4关了，点击了保存进度，下次来玩的时候重载进度，直接从第4关开始。不过假如你玩到第4关了，点击保存了进度，又继续玩到第6关了，忘记保存进度退出了，不好意思，下次你来的时候重载进度也只能从第4关开始。这也是`RDB`持久化的一个缺点，后续会说明。  
先来看下配置文件，做个小实验吧，这长篇大论的文字，估计直接右上角X了。  
当前是windows环境，不过配置文件一样的，你在Linux同样。  
配资质文件

save 900 1
    save 300 10 
    save 1 1
    dbfilename dump.rdb
    dir ./

解释一下上面的这些配置：

*  save 900 1  
    `自动触发配置，表示当m秒内发生n次变化时，会触发bgsave。这个配置就是当900秒内触发了1次写操作的时候，就会自动创建快照，达到持久化目的，另外几个save同理，可配置一个或多个。如果你配置了多个save，当任意一个设置的条件被满足的时候，Redis就会执行一次bgsave命令`
 *  dbfilename dump.rdb  
    `RDB持久化后存放的文件名称`
 *  dir ./  
    `持久化文件存放的位置`  
    先来说下`bgsave`命令

##### 1.1 BGSAVE 和 SAVE #####

当通过BGSAVE命令创建快照的时候，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入磁盘，而父进程继续处理请求。  
SAVE命令也可以进行快照，但是SAVE不常用，因为SAVE命令执行的时候，Redis服务器在快照创建完之前是不处理任何请求的。这也并不是说SAVE就没用，存在就有道理，如果你没有足够的内存区执行BGSAVE的话，或者等待快照创建完Redis再做相应也没事的话，可以选择SAVE。  
注意：**BGSAVE在创建子进程的时候，会出现停顿，数据量小的话肯定看不出，如果数据量很大的时候，你可以接受SAVE命令的话，就是在快照创建完之前阻塞Redis，用SAVE命令速度会提升很多。**

##### 1.2实验 #####

上面conf文件中我专门配置了一个

save 1 1 //表示一秒内有一次写入就触发BGSAVE创建快照持久化

上面提过我实在windows上测试，和linux同理  
先说一下：当前时间为：**2019/6/15/21/47**，来看下Redis文件夹下的dump.rdb文件  
![在这里插入图片描述][20190615214902767.jpg]  
我们看到当前文件最后更新时间是：**2019/6/15/21/48**  
我们执行一条String 写入：  
![在这里插入图片描述][20190615214543846.jpg]  
我们立刻来看下RDB文件  
![在这里插入图片描述][20190615214948822.jpg]  
最后时间已经更新为：**2019/6/15/21/49**，这是因为我们的配置的原因。  
你也可以通过命令直接执行快照创建：  
`BGSAVE命令:`  
![在这里插入图片描述][20190615215128135.jpg]  
看下文件最后更新时间：  
![在这里插入图片描述][20190615215201852.jpg]  
同样的，你使用`SAVE命令`也可以执行快照创建，关于这两个命令创建快照的区别，上面已经做了详细的说明了。  
![在这里插入图片描述][20190615215311578.jpg]  
文件更新图片我就不再展示了，你可以自己测试一下。  
`说明：dump.rdb这个文件是无法查看的，打开后你会发现都是一些类似于乱码的东西`  
RDB总结：通过开头介绍的那个单机游戏保存关卡进度和以上的配置及几个小例子，可以很明显的看出一个RDB快照法进行持久化的一个缺点，就是容易丢失数据，因为我们的快照创建都是在达到某一个条件后才去在执行创建的，这就意味着有个时间间隔，我设置的`save 1 1`是为了测试使用，如果你这样配置，那么你的Redis服务可能不断的出现卡顿，因为fork子进程同样需要时间。那么，如果可以接受RDB方法带来的持久化所带来的数据丢失，那么RDB方法是一个不错的方法。但是很多时候我们不能接受如900秒，3600秒时间段的丢失的数据，那么这个RDB方法就不能被接受了，你可以试试另一个持久化方法，AOF。

##### 2.只追加文件法-AOF #####

AOF法的介绍上面已经提过了，我们直接来看下配置文件

appendonly yes //开启AOF持久化
    appendfilename "appendonly.aof" 
    //持久化方式：
    # appendfsync always 
    appendfsync everysec 
    # appendfsync no 
    dir ./

解释一下上面的这些配置：

*  appendfilename “appendonly.aof”  
    `保存的AOF文件名称`
 *  appendfsync always  
    `总是同步持久化 实时记录，性能比较差`
 *  appendfsync everysec  
    `每秒持久化一次`
 *  appendfsync no  
    `Redis不对AOF文件执行显式操作，将由操作系统决定何时对AOF文件执行同步持久化（并不是不进行AOF持久化）`
 *  dir ./  
    `持久化文件存放的位置，和RDB一条命令`  
    在这里要注意一点：如果你使用的是固态硬盘，尽量不要开启`appendfsync always`,因为开启这个选项，Redis每次只写入一条命令，而不是如其他的`appendfsync`选项，一次可以写入多个Redis命令，这样不断的写入会引发严重的写入放大问题（write amplification）问题，某些情况下可能会严重减少固态硬盘的寿命。所以，考虑到写入性能和磁盘寿命问题，无论你是不是SSD，尽量使用`appendfsync everysec`选项。同样，也不推荐使用`appendfsync no`选项。

##### 2.1实验 #####

同样来个小测试，按照上面配置AOF持久化已经开启了，并且为每秒中异步追加持久化一次。先来看下这个`appendonly.aof`文件  
![在这里插入图片描述][20190616222136727.jpg]  
`如果你执行一条命令，就会看到该文件更新。这里提一下，如果你是在windows环境下，发现你的某条命令执行后并没有产生aof文件，那么请你执行以下两条命令：`

redis-cli config set appendonly yes
    redis-cli config set save ""

##### 2.2重写压缩AOF文件 #####

由于AOF持久化方法的原因，虽然这种方法在发生一些情况后丢失数据比较少，但是因为记录了每一条命令，Redis运行很久后，AOF文件可能会很大，占用很多的硬盘空间，还有一点很重要，如果重启了Redis，AOF文件体积又非常大，那么恢复起来时间将会很长。  
为了解决这个问题，Redis中有一条命令：

BGREWRITEAOF

这条命令就是通过移除AOF文件中冗余的命令来重写AOF文件，减小文件大小。并且执行该命令的时候和`BGSAVE`一样，Redis会fork一个子进程来执行。  
同样的，这个压缩也可以通过配置来实现：

auto-aof-rewrite-percentage 100 //100为参数
    auto-aof-rewrite-min-size 16mb //16mb为参数

上面两条配置的意思就是：  
如果AOF文件的大小超过16MB，也就是16兆以后，并且AOF文件的体积比上一次重写后的体积大了至少一倍以上（这的100参数，就是100%，一倍的意思），Redis将会开辟子进程执行`BGREWRITEAOF`命令。

# 总结 #

上面两种是Redis持久化的两种方法，不过无论你是采用了哪一种持久化方法，都应该将持久化以后的文件进行额外备份，避免出现存放持久化文件的服务器出现问题导致数据丢失。  
关于使用哪一种持久化方法，这个应该根据实际业务来考虑，还是上面提过的，根据需要，你可以开启RDB持久化或者AOF持久化，或者两种持久化方法都不开启。

[20190615214902767.jpg]: /images/20220114/ec7acdd6d0784a22a2622b9641c9776e.png
[20190615214543846.jpg]: /images/20220114/52a21d97b63940c2ad258cd65f6a051b.png
[20190615214948822.jpg]: /images/20220114/b2bd84662a784cebb30209b80b1f15aa.png
[20190615215128135.jpg]: /images/20220114/aa27c987dd5e4e9d899e05638caa870b.png
[20190615215201852.jpg]: /images/20220114/3d6ede425d1e4610a011f74014a0392f.png
[20190615215311578.jpg]: /images/20220114/7b834172092546aba946a5af7d7b89f7.png
[20190616222136727.jpg]: /images/20220114/e4812cef5f9d47aa8687009eee14267c.png