Redis是个支持持久化的内存数据库，redis需要经常将内存中的数据同步到磁盘来保证持久化。
1、RDB方式（Snapshotting默认快照方式）：
1.1）配置：
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:
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做一次快照持久化不推荐。
127.0.0.1:7000> save
OK
127.0.0.1:7000>
原因：save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求。所以不推荐使用。
2、Append-only file（缩写aof）的方式：
2.1）配置
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
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也不常用）
相关配置
持久化文件会变的越来越大。
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命令将其设置成新的主数据库的从数据库，即可将数据同步回来。
如有不妥，欢迎指正！
