标签：场景 系统 不一致 自己 方案 最优 优点 update 配置
前情概要：
和一个同事排查一个Redis的问题的时候，同事突然来了句“你知道Redis的几种持久化方式么？”，很自然的就答道“rdb和aof嘛“，同事则说其实有第三种方式“rdb和aof的混合版”，震惊！！！
Redis需要持久化的原因：
Redis数据都在内存中，当出现服务挂掉等场景时需要重新启动服务，若未进行持久化则直接数据丢失（其实就和最开始没用文件或者数据库学编程一样吧，重启下代码啥都得从头再来）
Redis持久化方式：RDB（快照）、AOF（追加）、混合（持久化操作数据rdb、之后操作aof）
RDB（快照）
原理：将当前内存中的redis库中的数据写入磁盘（主进程会fork一个子进程执行BGSAVE命令来将内存中redis的数据写入临时持久化文件，同时主进程继续接收请求提供服务，待快照生成后使用临时文件替换原持久化文件）
参数设置：配置文件中或者命令行修改参数，save seconds updateCount（即在指定时间内执行了指定条修改操作将执行一次持久化），可设置多条
优点：1、文件紧凑、小 2、性能较优 3、大数据集恢复比aof快 4、适用容灾（文件小传输快、恢复快）
缺点：1、故障时会丢失最后一次持久化后的数据 2、大数据集时fork子进程较耗时 3、可读性差
持久化命令：bgsave（fork子进程进行持久化） save（直接阻塞进行持久化）
AOF（追加）
原理：将所有修改指令追加到文件末尾（恢复时从头一条条执行命令即可）
参数设置：appendonly设置为yes，appendfsync设置为everysec（每秒执行一次，默认）、always（每条修改命令都执行）、no（不主动执行，由操作系统决定）
优点：1、故障时丢失数据少（取决于参数配置） 2、持久化文件兼容性（不受版本制约）、可读性强（协议较简单，了解规则可直接读懂，在未重写前可恢复至指定位置）
缺点：1、持久化文件较大 2、性能可能没rdb快 3、可能重新载入时数据不一致
持久化命令：bgrewriteaof
混合（RDB+AOF）
原理：先将内存数据rdb快照存到aof文件前面，然后再将缓冲区数据通过aof格式存到aof文件末尾，然后替换旧文件
参数设置：aof-use-rdb-preamble设置为yes
优点：结合rdb和aof的优点，持久化文件小，加载快
缺点：持久化文件可读性差、兼容性差（4.0前版本不识别）
持久化命令：bgrewriteaof
恢复：同aof，恢复aof文件，只是aof文件中可能前一部分为rdb格式
后话：各个方案都有自己的优劣，没有那种方案是万能最优解，我们需要根据实际的场景来选择持久化的方式，是啊，除了Redis的持久化我们的生活也如此，不是么？
标签：场景 系统 不一致 自己 方案 最优 优点 update 配置
原文地址：https://www.cnblogs.com/huangxinyuan650/p/14165859.html
