其实redis就是一种高级的以键值对模式存储数据的数据库，而它的益处就是他能够反对数据的长久化，其实redis之所以会有这样的长处，次要是因为，redis的数据都是寄存在内存中的，如果不配置长久化，那么在redis进行重启的时候，就会造成数据的失落，于是redis开启了数据的长久化性能，将所有的数据保留到磁盘中，当redis重启之后，就能够间接从磁盘中复原数据，所以redis的长久化性能，次要就是为了避免服务器宕机而造成的数据失落。
redis也提供了两种不同的长久化形式：
第一种是：RDB长久化，RDB是Redis DataBase的缩写，redis默认的长久化形式，简略来讲就是将redis在内存中的数据库记录依照指定的工夫转存到磁盘当中，其实就是肯定工夫距离内对你的数据进行一个快照存储，在默认的状况下，redis在实现快照存储后就会将这些数据保留在一个dump.rdb的文件中，当redis运行的时候，RDB就会将内存中的数据集存储到磁盘当中，在redis进行重启的时候，就能够通过载入RDB文件到RDB程序进行数据的同步复原。
长处：因为服务区在执行保留dump.rdb文件时，首先须要redis去调用forks()时，就会同时领有父过程和子过程，而子过程其实就是将这些数据写入到一个长期的RDB文件当中，当子过程实现写入后，redis就会用一个新的RDB文件替换掉旧的RDB文件，并且将旧的RDB文件删除，所以因为这样的工作形式，RDB长久化形式就只有一个dump.rdb文件，十分不便长久化，而且由子过程实现写的操作，让主过程能够持续解决命令，这样能够使得IO最大化，应用独自的子过程来进行长久化，主过程就不会进行任何的IO操作，这样能够保障redis的高性能。
毛病：因为RDB是依照指定的工夫每隔一段时间就要进行一次长久化，如果在长久化的过程中redis产生故障，那么仍然会产生数据失落，所以个别都在数据要求不太谨严的时候应用这种形式。
第二种：AOF长久化，AOF是Append Only File的缩写，默认AOF是不开启的，须要在redis.conf配置文件中手动开启，这种长久化形式就是将redis执行的每一次命令记录到独自的日志文件当中，当还原数据时，只须要将这些备份的指令再从新执行一遍即可。redis的配置文件中存在三种不同的AOF长久化形式，别离是：
appendfsync always：每次有数据批改产生时都会写入AOF文件，这样会重大升高Redis的速度
appendfsync everysec：每秒钟同步一次，将多个写命令同步到硬盘
appendfsync no：让操作系统决定何时进行同步
而且因为AOF长久化对日志文件的写入操作采纳的是append模式，应用这种模式的益处就是，即便在写入的过程中呈现宕机景象，也不会毁坏日志文件中曾经存在的内容，然而如果咱们本次操作只写入了一半数据就呈现了零碎解体问题，也不必放心，在redis下一次启动之前，咱们能够通过redis-check-aof工具来帮忙解决这种数据一致性的问题。
长处：数据安全，因为AOF有写回策略机制，比方：always，意思就是能够在每个执行命令执行完之后，立即同步的将日志写回磁盘，而且AOF长久化快，可能缩小数据失落的量，在配置了everysec的状况下最多只会失落秒级数据。
毛病：在等同数据量的状况下，AOF文件的大小要比RDB文件大很多，如果应用它进行内存的复原须要肯定的工夫。
针对以上论述，在抉择长久化形式上，一般来说，如果想要达到足以媲美关系型数据库的数据安全性，那么就应该同时应用两种长久化性能（redis4.0开始反对RDB和AOF混合长久化），在这种状况下，当redis重启的时候就会优先载入AOF文件来复原原始数据，因为通常这种状况下，AOF文件保留数据集要比RDB文件保留数据集更加残缺，如果你十分关怀你的数据，然而依然能够接受一些放弃在分钟之内的数据失落，那么你能够只抉择应用RDB长久化，因为它能够更快，然而会有一些分钟之内的数据失落是它的毛病。
有很多人都只应用AOF长久化，但其实不太举荐，因为定时生成RDB快照十分不便于进行数据库的备份，并且RDB复原数据集的速度也要比AOF复原的速度快，除此之外，应用RDB也能够无效躲避AOF程序的bug，当然如果你只心愿你的数据在服务器运行的时候存在，也能够不抉择应用任何长久化形式。
以上就是针对该问题做的简要论述，心愿可能小小的帮忙到大家。