Redis基础知识（学习条记17--持久化 (3)）

3.4 参数优化

（1）appendfsync

1. # The fsync() call tells the Operating System to actually write data on disk
2. # instead of waiting for more data in the output buffer. Some OS will really flush
3. # data on disk, some other OS will just try to do it ASAP.
4. #
5. # Redis supports three different modes:
6. #
7. # no: don't fsync, just let the OS flush the data when it wants. Faster. ##这种模式比较快
8. # always: fsync after every write to the append only log. Slow, Safest.  ##这种模式比较安全
9. # everysec: fsync only one time every second. Compromise. ##妥协或折中的方案
10. #
11. # The default is "everysec"【默认值】, as that's usually the right compromise between
12. # speed and data safety. It's up to you to understand if you can relax this to
13. # "no" that will let the operating system flush the output buffer【输出缓存】 when
14. # it wants, for better performances (but if you can live with【接受】 the idea of
15. # some data loss consider the default persistence mode that's snapshotting),
16. # or on the contrary【相反】, use "always" that's very slow but a bit safer than
17. # everysec.
18. #
19. # More details please check the following article:
20. # http://antirez.com/post/redis-persistence-demystified.html
21. #
22. # If unsure, use "everysec".
24. # appendfsync always
25. appendfsync everysec
26. # appendfsync no

复制代码

当客户端提交写命令后，该命令就会写入到aof_buf中，而aof_buf中的数据持久化到磁盘AOF文件的过程称为数据同步。
何时将aof_buf中的数据同步到AOF文件？采用差别的数据同步策略，同步的机遇是差别的，有三种策略：

• alwasy：写操纵命令写入aof_buf后会立即调用fsync()体系函数，将其追加到AOF文件。该策略效率较低，但是相对较安全，不会丢失太多数据。最多就是刚刚执行过的写操纵在尚未同步时出现宕机或重启，将这一操纵丢失。
  
• no：写操纵命令写入aof_buf后什么也不做，不会调用fsync()函数。而将aof_buf中的数据同步到磁盘的操纵由操纵体系负责。Linux体系默认同步周期为30秒。效率较高。
  
• everysec：默认策略。写操纵命令写入aof_buf后并不直接调用fsync()，而是每秒调用一次fsync()体系函数来完成同步。该策略兼顾到了性能与安全，是一种折中方案。
  

（2）no-appendfsync-on-rewrite

1. # When the AOF fsync policy is set to always or everysec, and a background
2. # saving process (a background save or AOF log background rewriting) is
3. # performing a lot of I/O against the disk, in some Linux configurations
4. # Redis may block too long on the fsync() call. Note that there is no fix【没有修复】 for
5. # this currently, as even performing fsync in a different thread will block
6. # our synchronous write(2) call.
7. #
8. # In order to mitigate【缓和；减轻；缓解】 this problem it's possible to use the following option
9. # that will prevent【阻塞；阻止；】 fsync() from being called in the main process while a
10. # BGSAVE or BGREWRITEAOF is in progress.
11. #
12. # This means that while another child is saving, the durability【持久性】 of Redis is
13. # the same as "appendfsync no". In practical terms, this means that it is
14. # possible to lose up to 30 seconds of log in the worst scenario (with the
15. # default Linux settings).
16. #
17. # If you have latency【延迟】 problems turn this to "yes". Otherwise leave it as
18. # "no" that is the safest pick from the point of view of durability.
20. no-appendfsync-on-rewrite no

复制代码

 该属性用于指定，当AOF fsync策略设置为always 或 everysec，当主进程创建了子进程正在执行bgsave或bgrewriteaof时，主进程是否不调用fsync()来做数据同步。设置为no，双重否定即肯定，主进程会调用fsync()做同步。而yes则不会调用fsync()做数据同步。
假如调用了fsync()，在需要同步的数据量非常大时，会阻塞主进程对外提供服务，即会存在延迟题目。假如不调用fsync()，则AOF fsync策略相称于设置为了no，可能会存在高达30秒日记的丢失。
（3）aof-rewrite-incremental-fsync 和 rdb-save-incremental-fsync

注意：这一步的定义在【########## ADVANCED CONFIG #######】部门

1. # When a child rewrites the AOF file, if the following option is enabled
2. # the file will be fsync-ed every 4 MB of data generated. This is useful
3. # in order to commit the file to the disk more incrementally and avoid
4. # big latency【延迟】 spikes【尖刺】.
5. aof-rewrite-incremental-fsync yes
7. # When redis saves RDB file, if the following option is enabled
8. # the file will be fsync-ed every 4 MB of data generated. This is useful
9. # in order to commit the file to the disk more incrementally and avoid
10. # big latency spikes.
11. rdb-save-incremental-fsync yes

复制代码

当bgrewriteaof在执行过程中也是先将rewrite计算的结果写入到了aof_rewrite_buf缓存中，然后当缓存中数据到达一定量后，就会调用fsync()进行刷盘操纵，即数据同步，将数据写入到临时文件。该属性用于控制fsync()每次刷盘的数据量最大不高出4MB。这样可以避免由于单次刷盘量过大而引发长时间阻塞。
（4）aof-load-truncated

1. # An AOF file may be found to be truncated【截断的；缩减的】 at the end during the Redis
2. # startup process, when the AOF data gets loaded back into memory.
3. # This may happen when the system【指操作系统】 where Redis is running
4. # crashes, especially when an ext4 filesystem is mounted without the
5. # data=ordered option (however this can't happen when Redis itself
6. # crashes or aborts but the operating system still works correctly).
7. #
8. # Redis can either exit with an error when this happens, or load as much
9. # data as possible (the default now) and start if the AOF file is found
10. # to be truncated at the end. The following option controls this behavior.
11. #
12. # If aof-load-truncated is set to yes, a truncated AOF file is loaded and
13. # the Redis server starts emitting【发出；发射】 a log to inform the user of the event.
14. # Otherwise if the option is set to no, the server aborts【终止】 with an error
15. # and refuses to start. When the option is set to no, the user requires
16. # to fix the AOF file using the "redis-check-aof" utility before to restart
17. # the server.
18. #
19. # Note that if the AOF file will be found to be corrupted【损坏的】 in the middle
20. # the server will still exit【退出】 with an error. This option only applies when
21. # Redis will try to read more data from the AOF file but not enough bytes
22. # will be found.
23. aof-load-truncated yes

复制代码

（5）aof-timestamp-enabled

# Redis supports recording timestamp annotations【注解】 in the AOF to support restoring # the data from a specific point-in-time. However, using this capability changes # the AOF format in a way that may not be compatible【兼容的】 with existing AOF parsers.【当前的AOF解析器】 aof-timestamp-enabled no

该属性设置为yes则会开启在AOF文件中增长时间戳的表现功能，可方便按照时间对数据进行规复。但该方式可能会与AOF解析器不兼容，所以默认值为no，不开启。
3.5 AOF持久化过程

AOF具体的持久化过程如下：
1）Redis担当到写操纵命令并不是直接追加到磁盘的AOF文件的，而是将每一条写命令按照redis通讯协议格式暂时添加到AOF缓冲区aof_buf。
2）根据设置的数据同步策略，当同步条件满足时，再将缓冲区中的数据一次性写入磁盘的AOF文件，以减少磁盘IO次数，提高性能。
3）当磁盘的AOF文件大小到达rewrite条件时，redis-server主进程会fork出一个子进程bgwriteaof，由该子进程完成rewrite过程。
4）子进程bgwriteaof起首对磁盘AOF文件进行rewrite计算，将计算结果写入到一个临时文件，全部写入完毕后，再rename该临时文件为磁盘文件的原名称，覆盖原文件。
5）假如在rewrite过程中又有写操纵命令写入到临时文件后，那么这些数据会暂时写入aof_rewrite_buf缓冲区。等将全部rewrite计算结果写入临时文件后，会先将aof_rewrite_buf缓冲区中的数据写入临时文件，然后再rename为磁盘文件的原名称，覆盖原文件。
概况如下：

  

 四. RDB 与 AOF 对比

4.4.1 RDB上风与不足

（1）RDB上风

• RDB文件较小（内存数据）；
  
• 数据规复较快。
  

（2）RDB不足

• 在一次性写入量较大的情况下，数据丢失风险较大；持久化过程相对较长，较重的磁盘IO；因此数据持久性相对差；
  
• 写时复制会降低性能；
  
• RDB文件可读性较差。
  

4.4.2 AOF上风与不足

（1）AOF上风

• 数据实时持久性强（数据丢失的可能性小）；
  
• AOF文件可读性强。
  

（2）AOF不足

• AOF文件相对较大（日记型）；
  
• 写操纵会影响性能；
  
• 数据规复相对慢。
  

4.4.3 持久化技术的选型

• 官方推荐利用RDB与AOF混淆式持久化。
  
• 若对数据持久性要求不高，则推荐利用纯RDB持久化方式。
  
• 官方不推荐利用纯AOF持久化方式（文件大；规复慢）。
  
• 若Redis仅用于缓存，则无需利用任何持久化技术。
  

 
学习参阅特别声明

【Redis视频从入门到高级】
【https://www.bilibili.com/video/BV1U24y1y7jF?p=11&vd_source=0e347fbc6c2b049143afaa5a15abfc1c】

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。