众所周知，redis是一个高性能的key-value数据库，由于操作都是基于内存的，因此存取效率比其他数据要高不少，今天要说的是redis的一个比较重要的知识：持久化。
redis的高性能是基于内存的，因此自然需要考虑内存的特性，读写快，但不稳定，断电数据会全部丢失，因此redis用户数据存储时，就不得不考虑数据的持久性了，及将数据保存在磁盘上，当硬件断电，重新启动时自动从磁盘读取数据，笔者所知道的持久化方式有两种：RDB和AOF。
RDB
RDB笔者用的比较多，相信大家也是，因为RDB是redis默认开启的，可能有读者曾几何时发现硬件重启后，redis的数据竟然还在（redis版本不能太老），曾几何时，redis在更新版本后将rdb加入默认配置里面了。
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。过程比较简单，也不需要过多配置。
AOF
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。可以说几乎是用户的每一个操作，都会记录。
开启方式大家可以百度一下。
相信大家看了两者的实现方式，心里大概了解了两者的基本机制和优劣势了，笔者就自己的使用心得来叙述一下两种方式
- RDB方式备份的磁盘上只有一个文件，而且只保留数据原文件，因此体积不大，对于宕机恢复是相当快的，而AOF则是记录每次修改，因此体积自然比RDB大不少，对于恢复数据较慢。
- RDB的性能比AOF高，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了，而AOF则需要跟踪每一个操作redis的进程，记录每一次的操作，如果操作频繁，可能会拖慢redis主进程的效率。
- AOF的数据安全性要比RDB高不少，由于AOF的同步方式默认是每修改同步，如果服务器宕机，损失的数据几乎可以忽略不记，而RDB则是周期性备份数据，宕机可能会损失不少东西，因此对于一些数据安全较高的系统，AOF是较好的选择甚至是必须的选择
基本配置方式
RDB持久化配置
Redis会将数据集的快照dump到dump.rdb文件中，当然我们也可以通过配置文件来修改Redis服务器dump快照的频率，打开redis配置文件之后，我们搜索save，应该可以看到下面的配置信息：
save 900 1 #在900秒之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒之后，如果至少有10000个key发生变化，则dump内存快照。
当然大家可以根据项目需求自己更改
AOF持久化配置
# appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
# appendfsync no #从不同步。高效但是数据不会被持久化。
不过虽然说redis性能高，但是笔者大多数项目里面redis只是充当中间数据库的角色，存储完整数据还是要依靠磁盘数据库，不过笔者有朋友是有项目里只有redis来存储数据，并没有mysql，sql server等，听说数据安全性还不错。具体使用，还需要根据场景需求和程序员的专业能力来操作。