redis mongodb持久化的方式
redis持久化方式(两种)
RDB持久化
redis提供了RDB持久化的功能，这个功能可以将redis在内存中的的状态保存到硬盘中，相当于snapshot，它可以手动执行，也可以再redis.conf中配置，定期执行。
相关配置
-
databases
配置db文件的数目，可以用select dbid 指令为每个连接指定后续持久化时的db文件，新连接默认均使用db 0
-
save
SNAPSHOTTING的持久化方式有多种save策略可供选择，而且支持混用，例如：
save 900 1
save 300 100
save 60 10000
上述配置的效果是：snapshotting会在3个条件中的任何一个满足时被触发：- 900s内至少1个key有变化；
- 300s内至少100个key有变化；
- 60s内至少有10000个key有变化
save条件被触发时，Redis通过fork子进程，由子进程在后台实现异步dump磁盘。根据fork的写时复制策略，若持久化过程中出现很多写入请求，在最坏的情况下，需要的内存是当前数据集所占内存的2倍。
备注1：上述配置的3个触发条件其实是逐次加强的，哪个条件先满足就先触发那个save策略。
备注2：如果业务不需要持久化或不需要RDB方式的持久化，可以通过注释掉save配置项来实现 -
stop-writes-on-bgsave-error
指定Redis在后台dump磁盘出错时的行为，默认为yes，表示若后台dump出错，则RedisServer拒绝新的写入请求，通过这种方式来引起用户警觉，避免因用户未发现异常而引起更大的事故。
-
rdbcompression
RDB文件是否压缩存储，若为yes，会在压缩时消耗一点CPU，但省磁盘空间。
-
rdbchecksum
RDB文件是否需要CRC64校验, 若为yes,会在生成RDB文件后计算其CRC64并将结果追加至文件尾，同样，Redis启动Load RDB时，也会先计算该文件的CRC64并与dump时的计算结果对比。
好处：可以严格保证RDB的完整性及安全性
代价：会在dump或load时损失10%的性能。如果要最大化Redis的性能，这个配置项应该用no关掉 -
dbfilename
指定RDB文件名，默认为dump.rdb
-
dir
指定RDB文件存放目录的路径，若包含多级路径，则相关父路径需事先mkdir出来，否则启动失败。
AOF持久化
AOF持久化（Append-Only-File），与RDB持久化不同，AOF持久化是通过保存Redis服务器锁执行的写状态来记录数据库的，即commandlog。
具体来说，RDB持久化相当于备份数据库状态，而AOF持久化是备份数据库接收到的命令，所有被写入AOF的命令都是以redis的协议格式来保存的。
在AOF持久化的文件中，数据库会记录下所有变更数据库状态的命令，除了指定数据库的select命令，其他的命令都是来自client的，这些命令会以追加(append)的形式保存到文件中。AOF的引入可以将数据损失的程度减少到1秒或1条写入指令。
相关配置‘
-
appendonly
配置是否启用AOF持久化，默认为no
-
appendfilename
指定aof文件名，默认为appendonly.aof
-
appendfsync
配置aof文件的同步方式，Redis支持3种方式:
- no => redis不主动调用fsync，何时刷盘由OS来调度；
- always => redis针对每个写入命令均会主动调用fsync刷磁盘；
- everysec => 每秒调一次fsync刷盘。
用户可以根据业务对数据的敏感性选择合适的同步策略。
-
no-appendfsync-on-rewrite
指定是否在后台aof文件rewrite期间调用fsync，默认为no，表示要调用fsync（无论后台是否有子进程在刷盘）。备注：Redis在后台写RDB文件或重写aof文件期间会存在大量磁盘IO，此时，在某些linux系统中，调用fsync可能会阻塞。
-
auto-aof-rewrite-percentage
指定Redis重写aof文件的条件，默认为100，表示与上次rewrite的aof文件大小相比，当前aof文件增长量超过上次aof文件大小的100%时，就会触发background rewrite。若配置为0，则会禁用自动rewrite。
-
auto-aof-rewrite-min-size
指定触发rewrite的aof文件大小。若aof文件小于该值，即使当前文件的增量比例达到auto-aof-rewrite-percentage的配置值，也不会触发自动rewrite。即这两个配置项同时满足时，才会触发rewrite。
两种持续化方式需要明确的问题
-
若同时启用RDB和AFO两种持久化方式，则Redis Server启动时，会加载AOF文件以重建数据集，因为AOF可以保证数据是相对最完整的。
-
关于RDB和AOF各自的优缺点以及用户如何选择合适的持久化策略
-
若可以忍受数据丢失，只启用RDB即可；若对数据很敏感，可以同时启用RDB和AOF；不建议只启用AOF（注释配置文件的save配置项或通过redis-cli执行save ""），因为一旦如果AOF文件损坏或AOF解析引擎存在bug，整个数据集都无法重建。
对比
AOF更安全，可将数据及时同步到文件中，但需要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 也更完整。
RDB持久化，安全性较差，它是正常时期数据备份及 master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。
MongoDB持久化方式
mongodb在启动时，专门初始化一个线程不断循环（除非应用crash掉），用于在一定时间周期内来从defer队列中获取要持久化的数据并写入到磁盘的journal(日志)和mongofile(数据)处，当然因为它不是在用户添加记录时就写到磁盘上，所以按mongodb开发者说，它不会造成性能上的损耗，因为看过代码发现，当进行CUD操作时，记录(Record类型)都被放入到defer队列中以供延时批量（groupcommit）提交写入，但相信其中时间周期参数是个要认真考量的参数，系统为90毫秒，如果该值更低的话，可能会造成频繁磁盘操作，过高又会造成系统宕机时数据丢失过。
