为什么Redis持久化需要持久化其实我们工作中有很多持久化场景，比如word。它的持久化形式以~$paper.docx的形式持久化。那么在Redis中，为了防止数据意外丢失，保证数据安全，还进行了持久化。这种使用永久性存储介质保存数据并在特定时间恢复保存数据的工作机制称为持久化。Redis中有两种持久化方式：RDB（RedisDataBase）、AOF（AppendOnlyFile）。RDB（RedisDataBase）保存当前数据状态，以快照的形式存储数据结果，存储格式简单，以数据为中心。AOF（AppendOnlyFile）保存数据的操作过程，日志形式，存储操作过程，存储格式复杂，重点放在命令上。RDB持久化在Redis中，可以使用save命令进行RDB持久化操作。保存命令相关配置：dbfilename.dump.rdb说明：设置本地数据库文件名，默认为dump.rdbdir说明：设置存储.rdb文件路径rdbcompressionyes说明：设置存储到本地数据库时是否压缩数据，默认是yes，使用LZF压缩是单线程的。当我们执行save命令时，当前的Redis服务器会被阻塞，直到RDB进程执行完毕，可能会造成长期阻塞，不建议在线上环境使用。那么问题来了，既然使用save会影响到在线服务器，那么有没有更好的方式来持久化呢？答案是肯定的，那就是bgsave。从名字我们可以看出这个持久化操作是在后台进行的，不会导致Redis阻塞。我们来看一下bgsave的工作原理：可以看出，在执行bgsave命令时，Redis会fork一个子进程创建RDB文件进行持久化，这样Redis就不会被阻塞。但是bgsave不会立即执行，会消耗额外的CPU资源。bgsave命令针对保存阻塞问题进行了优化。Redis中所有的RDB操作都使用bgsave方法，save命令可以舍弃。bgsave命令相关配置：dbfilename.dump.rdb描述：设置本地数据库文件名，默认为dump.rdbdir描述：设置.rdb文件的存放路径rdbcompressionyes描述：设置存放时是否压缩数据到本地数据库，默认是，使用LZF压缩rdbchecksumyes说明：设置是否进行RDB文件格式校验，校验在写文件和读文件过程中进行stop-writes-on-bgsave-erroryes说明：如果有是后台存储出错，是否停止save操作那么问题又来了，我们不可能一直手动执行或者bgsave命令。这时候Redis就为我们提供了自动执行bgsave的功能。在Redis的配置文件中，有这样一个配置save[secone][changes]可以帮助我们自动持久化。配置：savesecondchanges作用：如果在限定的时间范围内key变化的次数达到指定次数，则持久化。参数：second：监听时间范围变化：监听key变化。位置：在conf文件中配置。应根据实际业务情况设置。如果频率过高或过低，都会出现性能问题，后果可能不堪设想。保存配置通常与秒和更改设置之间具有互补关系。尽量不要将其设置为包容关系。saveconfigurationstartup最后要做的就是bgsaveoperationRDB三种持久化方式：RDB的优点：RDB是一个紧凑的压缩二进制文件，存储效率高。RDB是存储在Redis中的数据在某个时间点的快照，非常适合做数据备份。在全量复制等场景下，RDB恢复数据的速度要比AOF快。多台服务器每X小时做一次bgsave备份，将RDB文件复制到远程机器上进行容灾。RDB的缺点：RDB无论是执行指令还是利用配置都不能实现实时持久化，数据丢失的可能性更大在数据不兼容的情况下，AOF持久化AOF（AppendOnlyFile）持久化将每条写命令记录在一个独立日志，重启时重新执行AOF文件中的命令恢复数据。相对于RDB，可以简单的描述为数据生成的过程。AOF的主要作用是解决持久化的实时性，是目前Redis持久化的主流方式。AOF持久化进程在同步AOF命令缓冲区到文件时有三种写数据策略（appendfsync）：always（每次）每次写操作都同步到AOF文件，数据零错误，但是性能低everysec（Everysecond)每秒将缓冲区中的指令同步到AOF文件中，数据精度高，性能也高。如果系统突然死机，1秒内的数据就会丢失。no(systemcontrol)每次由操作系统控制同步到AOF文件的循环，整体流程不可控Redis开启AOF功能持久化配置：appendonlyyes|no作用：是否开启AOF持久化，默认不开启appendfsyncalways|everysec|no功能：AOF同步命令数据策略appendfilenamefilenameAOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-portnumber。aofAOF如何处理相同的命令？如果同步策略是appendfsynceverysec，则执行如下命令：setnamezhangsansetnamelisisetnamewangwu将在最终的AOF文件中只有一个：setnamewangwuAOF重写随着AOF文件的不断写入，AOF文件会越来越大。为了解决这个问题，Redis引入了AOF重写机制来压缩文件大小。AOF文件改写是将Redis进程中的数据转化为写入命令，同步到新的AOF文件中的过程。简单的说，就是将几条命令的执行结果转换成最终结果数据对应的指令进行记录。AOF重写的作用是减少磁盘占用，提高磁盘利用率，提高持久化效率，减少持久化时间，提高IO性能，减少数据恢复时间，提高数据恢复效率。进程中的AOF重写规则有超时命令不再忽略写入文件时的无效指令，重写时使用进程内数据直接生成，这样新的AOF中只保留最后的数据写入命令delkey1hdelkey2。将相同数据的写命令合为一条命令如下：lpushlist1a、lpushlist1b、lpushlist1c可转换为：lpushlist1abc。为了防止数据量过大导致客户端缓冲区溢出，每个命令最多可以写入64个元素，包括list、set、hash、zset等类型。AOF重写规则手动重写bgrewriteaof和自动重写auto-aof-rewrite-min-sizesizeauto-aof-rewrite-percentagepercentageAOF重写流程AOF持久化+重写：执行set等命令主进程先执行这条命令，然后fork一个子进程,用于重写AOF缓存和AOF缓存写命令满足条件后写入AOF文件。bgwriteaof执行时，还会fork一个子进程从AOF重写缓冲区中读取指令并重启。同时会提示bgwriteaof正在执行。重写完成后，将原来的.aof文件RDB替换为AOFRDB和AOF的区别如何选择对数据敏感，建议使用默认的AOF持久化方案AOF持久化策略使用everysec，每秒fsync一次.这种策略可以很好的保持处理性能，出现问题时最多丢失0-1秒的数据。注：由于AOF存储量大，恢复速度慢，数据呈现阶段有效性。推荐使用RDB持久化方案。阶段性数据可以很好的实现不丢失，恢复速度快。RDB通常用于阶段点数据恢复。解决方案注意：使用RDB实现紧凑的数据持久化会降低Redis的性能。综合比较RDB和AOF其实是一个trade-off。每个都有自己的优点和缺点。如果不能容忍几分钟内的数据丢失，对业务危害很大敏感的，选择AOF如果可以接受几分钟内的数据丢失，追求大数据集的恢复速度，选择RDB容灾，选择RDB双保险策略，同时启用RDB和AOF。重启后Redis会先使用AOF恢复数据。减少丢失数据量持久化应用场景应用于抢购、限购、限发优惠券、激活码等业务的数据存储设计应用于操作顺序数据控制应用于最新消息展示应用于黑白名单列表设置的服务控制应用于柜台组合排序功能对应的排名
