Redis——持久化
Posted 散人阿淦的自学之旅
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis——持久化相关的知识，希望对你有一定的参考价值。
简单说说吧，码少点字。Redis持久化分两种，快照（RDB）以及日志（AOF）。Redis指令以及Redis配置等不详细解释了。通常来说，Redis主节点不会进行持久化操作，持久化操作在从节点进行。最好有两个从节点，降低网络分区概率，数据不会轻易丢失。
一、快照
快照是一次全量备份，对redis内存中的数据进行二进制序列化。三种方式。在单线程的Redis中进行这种文件IO操作，必然会严重拖累服务器性能。所以Redis使用操作系统的多进程COW（copy on write）机制来实现快照持久化。所以呢，Redis通过调用fork函数产生一个子进程来完成持久化，主进程继续处理客户端请求。
二、日志
记录对Redis内存进行修改的指令记录。比如说set，incr等会产生或者是修改值的，而get或者是lrang等这些获取性的指令不会进行记录。Redis会先执行指令，然后将日志存盘（leveldb，hbase等是先存储日志再逻辑处理）。对于AOF日志写操作来说，实际上是先将日志内容写到内存缓存中，然后再将数据写到磁盘。这样问题就来了，假如说缓存区的日志内容没得写入到磁盘，redis挂了咋整。只需要实时调用glibc提供的fsync函数，执行一次指令就fsync一次，保证AOF日志不丢失。问题是，对于一个高性能的缓存数据库来说，这样的操作合适吗？
所以在正式的生产环境，一般都是隔1s执行一次fsync。还有个问题，假如每个记录都记录下来，AOF日志会越来越长，如果服务器宕机重启了，进行AOF日志恢复的时候会非常耗时，这个时候就需要对AOF日志进行瘦身重写。
2.1 AOF日志重写
bgwriteaof指令，开辟子进程对内存遍历，序列化成一个新的AOF文件，只保留可以恢复数据的最小指令集。序列化完毕后再将操作期间发生的增量AOF日志追加到新的AOF文件中，追加完毕后替换旧的AOF文件（比如demo这个键的值发生了三次变化，只会记录只会一次变化后的值）
三、想了想还是说说吧
3.1关于快照持久化
save会导致主线程的阻塞，bgsave不会，因为是创建子进程进行的，可以在配置文件redis.conf里进行配置来实现bgsave的自动化；
"save m n",m秒内对数据集进行n次的快照存储；
rdbcompression:yes/no,是否进行压缩存储。
3.2关于日志持久化
appendfsync，调用fsync参数的频率，有三个参数，always，no，everysec；
appendonly:yes/no，是否开启AOF持久化；
auto-aof-rewrite-percentage，当前AOF文件比最后一次AOF重写大小的比例，达到这个比例（没有bgsave，bgwriteaof在进行，AOF文件大于rewrite值）就进行重写
auto-aof-rewrite-min-size，AOF文件大于这个值就重写（依然要满足上述的三个条件），初始化Redis时这个参数有效，后期重写不会根据这个变量进行重写
以上是关于Redis——持久化的主要内容，如果未能解决你的问题，请参考以下文章