Redis持久化

Redis持久化策略

1：RDB 持久化
2：AOF 持久化
3：无持久化
4：RDB AND AOF持久化

RDB持久化

 指定的时间间隔把内存中缓存的数据一次性完整的快照到磁盘，也是redis默认的持久化方式。默认的文件名dump.rdb。默认保存在redis根目录下
    RDB持久化配置(redis配置文件  默认:redis.conf文件中)：
        save 900 1 # 900秒累计有超过1个key更新就执行持久化操作
        save 300 10 # 300秒累计有超过10个key更新就执行持久化操作
        save 60 1000 # 60秒累计有超过1000个key更新就执行持久化操作
    RDB持久化机制：
        当redis达到持久化条件时，Redis会Fork（分出）一个子进程来专门把redis内存中的数据到写入到磁盘的一个临时文件。
        这个时候主进程还是可以继续处理client的请求，不受影响。在子进程把所有数据写完后再把这个临时文件用原子函数rename(2)重命名为目标rdb文件。
        这种实现方式充分利用fork的copy on write。进程处理完后会自动退出。
        还有一种方式是通过Redis客户端调用 save 和bgsave命令来执行一次持久化操作， 调用save或bgsave时是由主进程来处理持久化操作，不会fork一个子进程
        程来处理，这样会导致主进程会阻塞其他client的请求，不推荐使用！
    RDB持久化机制的优势：
        1：只有一个数据库文件，方便备份归档。
        2：很容易的数据恢复。当Redis的缓存数据非常大的时候，RDB恢复效率高于AOF
        3：让Redis性能最大化。由于RDB持久化的时候会fork一个子进程来处理，不影响主进程的请求处理。
    RDB持久化的劣势：
        1：当服务器故障时会发生部分数据丢失。对于数据完整性要求严格的业务，此持久机制不适合。
        2：每次做RDB持久化，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。
            在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 
            如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间会更长。

AOF持久化

    把客户端client每次的请求执行的命令保存起来，文件后缀名为.aof,默认的文件名appendonly.aof 当要恢复Redis缓存数据时，通过对aof文件中的命令重建，
    来达到恢复Redis数据缓存。AOF持久化机制默认是关闭，通过配置可以开启。
    AOF持久化配置(redis配置文件  默认:redis.conf文件中)：
        appendonly yes  #启用aof持久化方式
        # appendfsync always  #每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
        appendfsync everysec    #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
        # appendfsync no    #完全依赖os，性能最好,持久化没保证
    bgrewriteaof命令：
        当Redis客户端请求命令频繁，导致aof文件越来越大，如：incr foo 100时，此时会保存100条操作命令，其实只需set foo 100一条命令就好了
        所以redis就提供了gbrewriteaof命令来瘦身aof文件：
        瘦身机制：
            当redis收到gbrewriteaof命令后，会fork（分出）一个子进程来专门把redis内存中的数据到用命令的方式写入到磁盘的一个临时文件，最后替换原来的文件。具体过程如下
            redis调用fork ，现在有父子两个进程
            子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
            父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
            当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
            现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。
            需要注意到是重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
    AOF持久化优势：
        1：尽量保持数据的完整性，减少数据丢失的可能
        2：aof文件的格式有顺序，易读懂。
    AOF持久化劣势：
        1：对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
        2：一般情况下，使用AOF，redis的性能低于使用RDB

总结：

般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
其余情况我个人喜好选择AOF