配置文件在哪里？怎么配置？
配置文件名 redis.conf
路径在/etc/redis/redis.conf
一下是来自官方配置文件模板的RDB配置内容 https://download.redis.io/redis-stable/redis.conf
################################ SNAPSHOTTING ################################
# Save the DB to disk.
#
# save <seconds> <changes> [<seconds> <changes> ...]
#
# Redis will save the DB if the given number of seconds elapsed and it
# surpassed the given number of write operations against the DB.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# save ""
#
# Unless specified otherwise, by default Redis will save the DB:
# * After 3600 seconds (an hour) if at least 1 change was performed
# * After 300 seconds (5 minutes) if at least 100 changes were performed
# * After 60 seconds if at least 10000 changes were performed
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 10000
# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes
# Compress string objects using LZF when dump .rdb databases?
# By default compression is enabled as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes
# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes
# Enables or disables full sanitization checks for ziplist and listpack etc when
# loading an RDB or RESTORE payload. This reduces the chances of a assertion or
# crash later on while processing commands.
# Options:
# no - Never perform full sanitization
# yes - Always perform full sanitization
# clients - Perform full sanitization only for user connections.
# Excludes: RDB files, RESTORE commands received from the master
# connection, and client connections which have the
# skip-sanitize-payload ACL flag.
# The default should be 'clients' but since it currently affects cluster
# resharding via MIGRATE, it is temporarily set to 'no' by default.
#
# sanitize-dump-payload no
# The filename where to dump the DB
dbfilename dump.rdb
# Remove RDB files used by replication in instances without persistence
# enabled. By default this option is disabled, however there are environments
# where for regulations or other security concerns, RDB files persisted on
# disk by masters in order to feed replicas, or stored on disk by replicas
# in order to load them for the initial synchronization, should be deleted
# ASAP. Note that this option ONLY WORKS in instances that have both AOF
# and RDB persistence disabled, otherwise is completely ignored.
#
# An alternative (and sometimes better) way to obtain the same effect is
# to use diskless replication on both master and replicas instances. However
# in the case of replicas, diskless is not always an option.
rdb-del-sync-files no
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./什么时候进行持久化?
手动执行SAVE/BGSAVE
SAVE 会在线程中执行SAVE 刷盘写文件大量系统I/O 请求会阻塞当前进程，慎用！
BGSAVE 会fork 一个子进程进行数据镜像，主进程会等待这一次fork出来的子进程镜像完成才会再次进行数据镜像
关闭Redis 服务时会进行一次SAVE，所以在数据量大时关闭服务会发现阻塞...
到达配置条件时server.cron 周期函数触发 进行fork-镜像
主从全量复制发送RDB文件时
FLUSHALL - 清空数据库时
这里那官方配置文件中示例参数作示例
# save <seconds> <changes> [<seconds> <changes> ...]
#
# Redis will save the DB if the given number of seconds elapsed and it
# surpassed the given number of write operations against the DB.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# save ""
#
# Unless specified otherwise, by default Redis will save the DB:
# * After 3600 seconds (an hour) if at least 1 change was performed
# * After 300 seconds (5 minutes) if at least 100 changes were performed
# * After 60 seconds if at least 10000 changes were performed
save 3600 1 300 100 60 10000save 配置可以作分档式的配置,上面配置意思是:
3600 s 有一次修改，作一次镜像 -- 等了3600s 刚好有一次数据操作,镜像
300s 修改次数大于等于100次，镜像。
60s 修改大于10000次，镜像
以上只要到达任一档的条件就会触发.
RDB 做了什么？
看图说话
redis 触发RDB流程有三种方式这里将server.cron 定时时间回调 检查触发 RDB。
检擦函数发现当前情况刚好满足触发条件其中一档，则进入RDB流程:
BGSAVE
主进程检擦是否有无子RDB进程正在备份，有则进行，返回，无则进行下一步
主进程 fork 一个RDB子进程 (子进程拷贝页表....)
子进程开始 镜像数据，将惊险数据写入到新RDB文件中...
新RDB文件写入完成，替换旧RDB文件，返回.
注意
在大量数据的场景下，RDB 备份频率配置是需要认真考量的，因为linux 写时复制的优化特性，父子进程时共享同一块物理内存，子进程只是拷贝了父进程的页表，但并没有拷贝页表中指向物理内存中的数据，如果在RDB备份期间如果主进程要增删改数据，主进程会复制一份原内存段数据到操作系统分配的新内存中进行修改。这中间的拷贝如果数据量很大就会占用大量系统资源导致系统抖动，影响业务.