2.redis持久化

Redis持久化 RDB (触发机制，流程解析，优点，缺点)   AOF (触发机制，aof常用配置总结，流程解析，重写机制，优点，缺点)   持久化的选择   持久化配置方案
为什么需要持久化：             持久化的功能：Redis是内存数据库，数据都是存储在内存中，进程退出数据就会永久丢失，所以需要定期将Redis中的数据从内存保存到硬盘。           Redis持久化分为RDB持久化和AOF持久化，前者是把当前数据保存到硬盘，后者则是把每次执行的写命令保存到硬盘。
RDB （默认RDB）		把当前数据保存到硬盘
	触发机制	手动触发分别对应 save 和 bgsave 命令 save 命令：阻塞当前 Redis 服务器，直到 RDB 过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。   bgsave 命令：Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。   自动触发 RDB 的持久化机制 “save m n”。表示 m 秒内数据集存在 n 次修改时，自动触发 bgsave。 # 900s内至少达到一条写命令 save 900 1 这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能， 时间设置太长则会造成数据丢失。   （     把数据保存到硬盘的触发机制：     手动 save（阻塞）  /   bgsave（fork子进程）     自动 save 900 1 (不推荐，会影响服务器性能 => 频繁写入RDB文件) ）
	流程解析	1）执行 bgsave 命令，Redis 父进程判断当前是否存在正在执行的子进程，如 RDB/AOF 子进程，如果存在 bgsave 命令直接返回。 2）父进程执行 fork 操作创建子进程，fork 操作过程中父进程会阻塞，通过 info stats 命令查看 latest_fork_usec 选项，可以获取最近一个 fork 操作的耗时，单位为微秒。 3）父进程 fork 完成后，bgsave 命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。 4）子进程创建 RDB 文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行 lastsave 命令可以获取最后一次生成RDB 的时间，对应 info 统计的 rdb_last_save_time 选项。 5）进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence 下的 rdb_* 相关选项。   （   1.判断当前是否存在执行的子进程 存在则bgsave直接返回   2.父进程fork创建子进程，fork操作过程中父进程可能会阻塞   3.bgsave返回 background saving started，不再阻塞父进程 ）
	优点	1）RDB 保存了 Redis 在某个时间点上的数据，适合用于进行备份   2）父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。   3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。   （    1.保存的是某个时间点的数据    2.父进程在保存RDB文件时唯一需要做的是fork一个子进程    3.恢复大数据的速度比AOF快 ）
	缺点	1）RDB 方式数据没办法做到实时持久化/秒级持久化  （AOF可以解决 针对 RDB 不适合实时持久化的问题，Redis 提供了 AOF 持久化方式来解决 RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端对服务器的每一次写操作命令到日志当中，并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾）   2）如果数据量太大，forks的子进程也会发生阻塞，另外，forks子进程会耗费内存。   （    1.没办法做到实时，秒级别的持久化    2.fork子进程的时候，可能会阻塞 ）
AOF (如果开启了AOF，redis恢复的时候，会优先加载AOF，就会清空RDB,需要注意)	触发机制	AOF 重写过程可以手动触发和自动触发： ·手动触发：直接调用 bgrewriteaof 命令。   ·自动触发：根据 auto-aof-rewrite-min-size和auto-aof-rewrite-percentage 参数确定自动触发时机。 ·auto-aof-rewrite-min-size：表示运行 AOF 重写时文件最小体积，默认为 64MB。 ·auto-aof-rewrite-percentage：代表当前 AOF 文件空间   示例： auto-aof-rewrite-percentage：100 auto-aof-rewrite-min-size：64mb 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发   AOF持久化的触发机制：    手动触发    bgrewriteof      自动触发    Auto-aof-rewrite-min-size    Auto-aof-rewrite-percentage
	Aof常用配置总结	appendonly no：是否开启AOF appendfilename "appendonly.aof"：AOF文件名 dir ./：RDB文件和AOF文件所在目录 appendfsync everysec：fsync持久化策略 no-appendfsync-on-rewrite no：AOF重写期间是否禁止fsync；如果开启该选项，可以减轻文件重写 时CPU和硬盘的负载（尤其是硬盘），但是可能会丢失AOF重写期间的数据；需要在负载和安全性之间进行平衡 auto-aof-rewrite-percentage 100：文件重写触发条件之一 auto-aof-rewrite-min-size 64mb：文件重写触发提交之一 aof-load-truncated yes：如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件
	流程如下	1）所有的写入命令会追加到 aof_buf（缓冲区）中。   2）AOF 缓冲区根据对应的策略向硬盘做同步操作。   3）随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。   4）当 Redis 服务器重启时，如果开启了 AOF 文件，会优先加载aof进行数据恢复。
	重写机制说明	AOF将客户端的每一个写操作都追加到aof文件末尾，随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，Redis 引入 AOF 重写机制压缩文件体积。   AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。   比如： 多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c 可以转化为：lpush list a b c。 AOF 重写降低了文件占用空间，除此之外，另一个目的是：更小的 AOF 文件可以更快地被 Redis 加载。
	AOF的优点	1）AOF可以设置 完全不同步、每秒同步、每次操作同，默认是每秒同步。因为AOF是操作指令的追加，所以可以频繁的大量的同步。   2）AOF文件是一个值追加日志的文件，即使服务宕机为写入完整的命令，也可以通过redis-check-aof工具修复这些问题。   3）如果AOF文件过大，Redis会在后台自动地重写AOF文件。重写后会使AOF文件压缩到最小所需的指令集。   4）AOF文件因为是有序保存数据库的所有写入操作，所以即使如果不小心误操作数据库，也很容易找出错误指令，恢复到某个数据节点。   （     1.每秒同步 因为是追加指令的方式     2.aof文件过大 可以压缩     3.容易找出错误指令，因为文件是有序保存所有写操作 ）
	AOF的缺点	1、相同数据量下，AOF的文件通常体积会比RDB大。因为AOF是存指令的，而RDB是所有指令的结果快照。但AOF在日志重写后会压缩一些空间。 2、在大量写入和载入的时候，AOF的效率会比RDB低。因为大量写入，AOF会执行更多的保存命令，载入的时候也需要大量的重执行命令来得到最后的结果。 RDB对此更有优势。   （     1.体积会比RDB大  因为AOF是指令，RDB是所有指令的结果快照     2.在大量写入和载入的时候，AOF的效率会比RDB低 ）
		AOF 和 RDB 文件都可以用于服务器重启时的数据恢复
持久化的选择	在实际生产环境中，根据数据量、应用对数据的安全要求、预算限制等不同情况，会有各种各样的持久化策略；此外，持久化的选择必须与Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能， 而且主机master和从机slave可以独立的选择持久化方案。 面分场景来讨论持久化策略的选择，下面的讨论也只是作为参考，实际方案可能更复杂更具多样性。 1）如果Redis中的数据完全丢弃也没有关系（如Redis完全用作DB层数据的cache），那么无论是单机， 还是主从架构，都可以不进行任何持久化。 2）在单机环境下（对于个人开发者，这种情况可能比较常见），如果可以接受十几分钟或更多的数据丢失，选择RDB对Redis的性能更加有利；如果只能接受秒级别的数据丢失，应该选择AOF。 3）但在多数情况下，我们都会配置主从环境，slave的存在既可以实现数据的热备，也可以进行读写分离分担Redis读请求，以及在master宕掉后继续提供服务。 在这种情况下的做法是： master：完全关闭持久化（包括RDB和AOF），这样可以让master的性能达到最好； slave：关闭RDB，开启AOF（如果对数据安全要求不高，开启RDB关闭AOF也可以），并定时对持久化文件进行备份（如备份到其他文件夹，并标记好备份的时间）； 然后关闭AOF的自动重写，然后添加定时任务，在每天Redis闲时（如凌晨12点）调用bgrewriteaof。    为什么开启了主从复制，可以实现数据的热备份，还需要设置持久化呢？因为在一些特殊情况下，主从复制仍然不足以保证数据的安全，例如： master和slave进程同时停止：考虑这样一种场景，如果master和slave在同一个机房，则一次停电事故就可能导致master和slave机器同时关机，Redis进程停止；如果没有持久化，则面临的是数据的完全丢失。 master误重启：考虑这样一种场景，master服务因为故障宕掉了，如果系统中有自动拉起机制（即检测到服务停止后重启该服务）将master自动重启，由于没有持久化文件，那么master重启后数据是空的， slave同步数据也变成了空的；如果master和slave都没有持久化，同样会面临数据的完全丢失。需要注意的是，即便是使用了哨兵进行自动的主从切换，也有可能在哨兵轮询到master之前，便被自动拉起机制重启了。因此，应尽量避免“自动拉起机制”和“不做持久化”同时出现。 4）异地灾备：上述讨论的几种持久化策略，针对的都是一般的系统故障，如进程异常退出、宕机、断电等，这些故障不会损坏硬盘。但是对于一些可能导致硬盘损坏的灾难情况，如火灾地震，就需要进行异地灾备。 例如对于单机的情形，可以定时将RDB文件或重写后的AOF文件，通过scp拷贝到远程机器，如阿里云；对于主从的情形，可以定时在master上执行bgsave，然后将RDB文件拷贝到远程机器，或者在slave上执行bgrewriteaof重写AOF文件后，将AOF文件拷贝到远程机器上。一般来说，由于RDB文件文件小、恢复快，因此灾难恢复常用RDB文件；异地备份的频率根据数据安全性的需要及其它条件来确定，但最好不要低于一天一次。     持久化的选择： 需要与redis的主从一起考虑，持久化和主从复制同样具有数据备份的功能     1）完全丢失数据也没关系     2）单机环境下，可以接受10多分钟或者更多的数据丢失，选择RDB     3）配置了主从的环境   最好的做法是：     1）主服务器:完全关闭持久化，让其性能达到最好     2）从服务器：对数据安全要求高时，关闭RDB，开启AOF。     3）关闭AOF的自动重写，然后添加定时任务，每天闲时调用bgrewriteof   为什么开启了主从复制，可以实现数据的热备份，还需要设置持久化 因为在一些特殊情况下，主从复制仍然不足够保证数据的安全     1）因为停电事故，导致主从服务器同时停止     2）主服务器误重启，重启后如果没有持久化，就会清空数据，从服务器也会同步成空的了     3）异地灾备   定时将RDB和重写后的AOF文件，通过scp拷贝到远程机器
持久化配置方案	1、企业级的持久化的配置策略 save 60 10000：如果你希望尽可能确保说，RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照，低峰期，数据量很少，也没必要 10000->生成RDB，1000->RDB，这个根据你自己的应用和业务的数据量，你自己去决定 AOF一定要打开，fsync，everysec auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%，上次的两倍 auto-aof-rewrite-min-size 64mb: 根据你的数据量来定，16mb，32mb 2、数据备份方案  RDB非常适合做冷备，每次生成之后，就不会再有修改了 数据备份方案 （1）写crontab定时调度脚本去做数据备份 （2）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份 （3）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份 （4）每次copy备份的时候，都把太旧的备份给删了 （5）每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去【crontab】   Crontab 定时做rdb备份，把太久的删除