十年河东，十年河西，莫欺少年穷
学无止境，精益求精
首先说下，我的 Redis 系列博客如下：
[置顶] 高并发时，使用Redis应注意的问题【缓存穿透、缓存击穿.、缓存雪崩】
windows环境下配置Redis主从复制-一主二仆，薪火相传、反客为主、哨兵模式
Redis 持久化技术 ，大名鼎鼎的Rdb和Aof，你会选谁呢？
简单介绍下Redis消息队列，实际生产环境中，大数据高并发时，不建议使用Redis做消息队列中间件
Redis 事务，和传统的关系型数据库ACID并不同，别搞混了
Redis常用配置redis.conf介绍，别把默认配置部署到到服务器，否则，会被领导骂的
C# Nuget程序集StackExchange.Redis操作Redis 及 Redis 视频资源 及 相关入门指令 牛逼不，全都有
Window环境下安装Redis 并 自启动Redis 及 Redis Desktop Manager
进入正文
Redis 提供了多种不同级别的持久化方式：
RDB【Redis Data Base】 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
AOF 【Append Only File】持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
一、RDB的持久化
工作原理：每隔一定时间给内存照一个快照，将内存中的数据写入文件（rdb文件）。这是Redis默认的持久化方式。当redis生成dump.rdb文件时，工作过程如下：
当达到RDB生成条件时，redis主进程fork一个子进程
fork出来的子进程将内存的数据集dump到临时的RDB中
当子进程对临时的RDB文件写入完毕，redis用新的RDB文件代替旧的RDB文件
配置参数如下【参考的redis.conf配置文件】：
含义分别是：
15分钟内有1个写入操作【包括修改和删除】，将会更新dump.Rdb文件。
6分钟内有10个写入操作【包括修改和删除】，将会更新dump.Rdb文件。
1分钟内有10000个写入操作【包括修改和删除】，将会更新dump.Rdb文件。
需要说明的是，Redis默认使用Rdb的方式进行持久化，Rdb持久化可以和Aof共存。
RDB的缺点：
在两次快照之间，如果发生断电，数据会丢失。举例：在生成rdb后，插入新值。突然断电，数据可能会丢失。也就是说，Rdb在数据完整性这块没有Aof那么优秀。
RDB的优点：
RDB的效率会高于Aof，在数据完整性要求不那么高的情况下，建议采用RDB模式。
显式保存/更新dump.Rdb：
在redis持久化技术中，如果想实时持久化dump.Rdb文件，可以使用save指令。
C:Userschenwolong>redis-cli 127.0.0.1:6379> ping PONG 127.0.0.1:6379> save OK 127.0.0.1:6379> keys * 1) "rds_set01" 127.0.0.1:6379> set k1 v1 OK 127.0.0.1:6379> save OK 127.0.0.1:6379>
如果你使用flushall指令，该指令将会清空dump.rdb文件，此指令慎用。因为用了，会清空所有16个数据库的key。
127.0.0.1:6379> flushall OK 127.0.0.1:6379>
监控Rdb
Redis监控最直接的方法当然就是使用系统提供的 info 命令来做了，只需要执行下面一条命令，就能获得 Redis 系统的状态报告。
C:Userschenwolong>redis-cli 127.0.0.1:6379> ping PONG 127.0.0.1:6379> info # Server redis_version:5.0.10 redis_git_sha1:1c047b68 redis_git_dirty:0 redis_build_id:76de97c74f6945e9 redis_mode:standalone os:Windows arch_bits:64 multiplexing_api:WinSock_IOCP atomicvar_api:pthread-mutex process_id:5324 run_id:e80e12a295d0733a7e33b8d7f78619bbafe32b9d tcp_port:6379 uptime_in_seconds:81905 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:5521244 executable:C:Program FilesRedis"c:program files edis edis-server.exe" config_file:C:Program FilesRedis edis.windows-service.conf # Clients connected_clients:1 client_recent_max_input_buffer:2 client_recent_max_output_buffer:0 blocked_clients:0 # Memory used_memory:724384 used_memory_human:707.41K used_memory_rss:682128 used_memory_rss_human:666.14K used_memory_peak:724408 used_memory_peak_human:707.43K used_memory_peak_perc:100.00% used_memory_overhead:710342 used_memory_startup:660392 used_memory_dataset:14042 used_memory_dataset_perc:21.94% allocator_allocated:5898008 allocator_active:432013312 allocator_resident:457179136 total_system_memory:0 total_system_memory_human:0B used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:73.25 allocator_frag_bytes:426115304 allocator_rss_ratio:1.06 allocator_rss_bytes:25165824 rss_overhead_ratio:0.00 rss_overhead_bytes:-456497008 mem_fragmentation_ratio:1.00 mem_fragmentation_bytes:0 mem_not_counted_for_evict:0 mem_replication_backlog:0 mem_clients_slaves:0 mem_clients_normal:49950 mem_aof_buffer:0 mem_allocator:jemalloc-5.2.1-redis active_defrag_running:0 lazyfree_pending_objects:0 # Persistence loading:0 rdb_changes_since_last_save:0 rdb_bgsave_in_progress:0 rdb_last_save_time:1616117339 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:0 rdb_current_bgsave_time_sec:-1 rdb_last_cow_size:0 aof_enabled:1 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok aof_last_cow_size:0 aof_current_size:90 aof_base_size:90 aof_pending_rewrite:0 aof_buffer_length:0 aof_rewrite_buffer_length:0 aof_pending_bio_fsync:0 aof_delayed_fsync:0 # Stats total_connections_received:5 total_commands_processed:30 instantaneous_ops_per_sec:0 total_net_input_bytes:1227 total_net_output_bytes:65190 instantaneous_input_kbps:0.00 instantaneous_output_kbps:0.00 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 expired_stale_perc:0.00 expired_time_cap_reached_count:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:57084 migrate_cached_sockets:0 slave_expires_tracked_keys:0 active_defrag_hits:0 active_defrag_misses:0 active_defrag_key_hits:0 active_defrag_key_misses:0 # Replication role:master connected_slaves:0 master_replid:eb41d45f5df47dce112c1d0496ca61bb66b3206f master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 # CPU used_cpu_sys:0.328125 used_cpu_user:0.343750 used_cpu_sys_children:0.000000 used_cpu_user_children:0.000000 # Cluster cluster_enabled:0 # Keyspace 127.0.0.1:6379>
rdb_changes_since_last_save 表明上次RDB保存以后改变的key次数
rdb_bgsave_in_progress 表示当前是否在进行bgsave操作，1表示正在进行；0表示没有进行
rdb_last_save_time 上次保存RDB文件的时间戳
rdb_last_bgsave_time_sec 上次保存的耗时
rdb_last_bgsave_status 上次保存的状态
rdb_current_bgsave_time_sec 目前保存RDB文件已花费的时间
修复错误的Rdb，如果服务器断电时或者重启/关机时，Rdb的save工作正在进行，且并未完成，这是的dump.rdb就可能出错，如果dump出错了，那么整个Redis服务也就挂了，那么当Rdb损坏或者错误时，我们怎么修复Rdb文件呢？
修复的原则是先备份，后修复
在Redis的安装目录下，我们可以看到有>redis-check-rdb.exe 和 redis-check-aof.exe，这两个可执行程序是依据Redis的过滤规则，规律掉Rdb或Aof中错误的部分，然后重新生成正确的文件。
一、AOF的持久化【Append only File】
AOF持久化方式在Redis.conf中默认是关闭的，因此，我们需要将appendonly：No 改成 appendonly:Yes
执行如下指令：
C:Userschenwolong>redis-cli 127.0.0.1:6379> ping PONG 127.0.0.1:6379> config set appendonly yes OK 127.0.0.1:6379> config get appendonly 1) "appendonly" 2) "yes" 127.0.0.1:6379>
AOF的优缺点：
AOF模式中数据的完整性要由于Rdb模式，但执行效率性能方面要低于Rdb，因此，如果对数据的完整性要求比较高，建议会用Aof的方式。
AOF的工作模式：
在AOF模式中，有三种模式
Redis 目前支持三种 AOF 保存模式，它们分别是：
AOF_FSYNC_NO ：不保存。
AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。
AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。
修改配置文件，可以通过管理员方式直接修改redis.windows-service.conf，修改完成后，重启redis服务即可生效
这里的意思是：当文件大于64M或者当前大小的一倍时，Redis会启动瘦身策略。在实际生产环境中，Redis的默认最小大小设置为64MB是不够的，因此每进行一次瘦身，就会消耗一次服务器IO资源，所有有比较将此值设大点
设置瘦身的大小 C:Userschenwolong>redis-cli 127.0.0.1:6379> ping PONG 127.0.0.1:6379> config set auto-aof-rewrite-min-size 128MB OK 127.0.0.1:6379> config get auto-aof-rewrite-min-size 1) "auto-aof-rewrite-min-size" 2) "134217728" 127.0.0.1:6379>
最后，借用别人的内容，如下：
redis 持久化 aof和rdb的加载顺序问题
如果开启 aof 和 rdb 。在redis重启后， 是先加载哪个文件？
查了很多资料都说是先加载aof, 但是也说了 如果 aof文件不存在，则加载 rdb文件
但经过测试，如果 aof不存在(手动删除aof文件)，貌似会创建一个新的 空的 aof文件，并没有去用 rdb文件
这是咋回事？（我的版本是Redis 5.0.8）
回答
1.aof和rdb都开启，只会加载aof,因为aof最能保证数据的完整性
2.关于你的疑问，其实很好解释，加载的顺序，取决于你的配置文件是否开启了aof，而不是说去判断aof文件是否存在！！所以配置很重要！！
主要是看到这么一张图，看着画的挺细的
最最后，祝福大家快乐每一天。
@天才卧龙的博客