浙江建设工程合同备案网站,英文网站提交,网站的购物车怎么做,网站建设公司排名深圳由于redis是基于内存的数据库#xff0c;一旦宕机#xff0c;数据就会丢失?如何解决#xff1f;
目前#xff0c;Redis 的持久化主要有两大机制#xff0c;即 AOF#xff08;Append Only File#xff09;日志和 RDB#xff08;Redis DataBase#xff09; 快照。
AO…由于redis是基于内存的数据库一旦宕机数据就会丢失?如何解决
目前Redis 的持久化主要有两大机制即 AOFAppend Only File日志和 RDBRedis DataBase 快照。
AOF日志 是写后日志写后的意思是 Redis 是先执行命令把数据写入内存然后才记录日志。 我们以 Redis 收到“set testkey testvalue”命令后记录的日志为例看看 AOF 日志的内容。其中“*3”表示当前命令有三个部分每部分都是由“$数字”开头后面紧跟着具体的命令、键或值。这里“数字”表示这部分中的命令、键或值一共有多少字节。例如“$3 set”表示这部分有 3 个字节也就是“set”命令。 写后日志的优势与风险 为了避免额外的检查开销Redis 在向 AOF 里面记录日志的时候并不会先去对这些命令进行语法检查。如果先记日志再执行命令的话日志中就有可能记录了错误的命令Redis 在使用日志恢复数据时就可能会出错。而写后日志这种方式就是先让系统执行命令只有命令能执行成功才会被记录到日志中否则系统就会直接向客户端报错。 除此之外写后日志一个好处它是在命令执行后才记录日志不会阻塞当前的写操作。
AOF 也有两个潜在的风险
风险一如果刚执行完一个命令还没有来得及记日志就宕机了那么这个命令和相应的数据就有丢失的风险。 如果此时 Redis 是用作缓存还可以从后端数据库重新读入数据进行恢复。 如果 Redis 是直接用作数据库的话此时因为命令没有记入日志所以就无法用日志进行恢复了。 风险二AOF 虽然避免了对当前命令的阻塞但可能会给下一个操作带来阻塞风险。 AOF 日志也是在主线程中执行(写回策略为 always 时)如果在把日志文件写入磁盘时磁盘写压力大就会导致写盘很慢进而导致后续的操作也无法执行了。 这两个风险都是和 AOF 写回磁盘的时机相关的。这也就意味着如果我们能够控制一个写命令执行完后 AOF 日志写回磁盘的时机这两个风险就解除了。
写回策略 Always 同步写回每个写命令执行完立马同步地将日志写回磁盘 Everysec 每秒写回每个写命令执行完只是先把日志写到 AOF 文件的内存缓冲区每隔一秒把缓冲区中的内容写入磁盘 No 操作系统控制的写回每个写命令执行完只是先把日志写到 AOF 文件的内存缓冲区由操作系统决定何时将缓冲区内容写回磁盘。 AOF重写 AOF 是以文件的形式在记录接收到的所有写命令。随着接收的写命令越来越多AOF 文件会越来越大。这也就意味着我们一定要小心 AOF 文件过大带来的性能问题主要在于以下三个方面 一是文件系统本身对文件大小有限制无法保存过大的文件 二是如果文件太大之后再往里面追加命令记录的话效率也会变低 三是如果发生宕机AOF 中记录的命令要一个个被重新执行用于故障恢复如果日志文件太大整个恢复过程就会非常缓慢这就会影响到 Redis 的正常使用。 AOF 重写机制就是在重写时Redis 根据数据库的现状创建一个新的 AOF 文件也就是说读取数据库中的所有键值对然后对每一个键值对用一条命令记录它的写入。重写机制具有“多变一”功能。所谓的“多变一”也就是说旧日志文件中的多条命令在重写后的新日志中变成了一条命令。
AOF 日志由主线程写回不同重写过程是由后台子进程 bgrewriteaof 来完成的这也是为了避免阻塞主线程导致数据库性能下降。
我把重写的过程总结为“一个拷贝两处日志”。 “一个拷贝”就是指每次执行重写时主线程 fork 出后台的 bgrewriteaof 子进程。此时fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程这里面就包含了数据库的最新数据。然后bgrewriteaof 子进程就可以在不影响主线程的情况下逐一把拷贝的数据写成操作记入重写日志。 第一处日志指的是因为主线程未阻塞仍然可以处理新来的操作Redis 会把这个操作写到它的缓冲区。这样一来即使宕机了这个 AOF 日志的操作仍然是齐全的可以用于恢复。 第二处日志就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后重写日志记录的这些最新操作也会写入新的 AOF 文件以保证数据库最新状态的记录。 总结来说每次 AOF 重写时Redis 会先执行一个内存拷贝用于重写然后使用两个日志保证在重写过程中新写入的数据不会丢失。而且因为 Redis 采用子进程进行日志重写所以这个过程并不会阻塞主线程。 正因为记录的是操作命令而不是实际的数据所以用 AOF 方法进行故障恢复的时候需要逐一把操作日志都执行一遍。如果操作日志非常多Redis 就会恢复得很缓慢影响到正常使用。这当然不是理想的结果。那么还有没有既可以保证可靠性还能在宕机时实现快速恢复的其他方法呢
RDB快照 和 AOF 相比RDB 记录的是某一时刻的数据并不是操作所以在做数据恢复时我们可以直接把 RDB 文件读入内存很快地完成恢复。
Redis 提供了两个命令来生成 RDB 文件分别是 save 和 bgsave。
save在主线程中执行会导致阻塞 bgsave创建一个子进程专门用于写入 RDB 文件避免了主线程的阻塞这也是 Redis RDB 文件生成的默认配置。
我们可以通过 bgsave 命令来执行全量快照这既提供了数据的可靠性保证也避免了对 Redis 的性能影响。 在执行快照的同时Redis 就会借助操作系统提供的写时复制技术Copy-On-Write, COW正常处理写操作。bgsave 子进程是由主线程 fork 生成的可以共享主线程的所有内存数据。bgsave 子进程运行后开始读取主线程的内存数据并把它们写入 RDB 文件。 如果主线程对这些数据也都是读操作例如图中的键值对 A那么主线程和 bgsave 子进程相互不影响。但是如果主线程要修改一块数据例如图中的键值对 C那么这块数据就会被复制一份生成该数据的副本键值对 C’。然后主线程在这个数据副本上进行修改。同时bgsave 子进程可以继续把原来的数据键值对 C写入 RDB 文件。 虽然 bgsave 执行时不阻塞主线程但是如果频繁地执行全量快照也会带来两方面的开销。 一方面频繁将全量数据写入磁盘会给磁盘带来很大压力多个快照竞争有限的磁盘带宽前一个快照还没有做完后一个又开始做了容易造成恶性循环所以在 Redis 中如果有一个 bgsave 在运行就不会再启动第二个 bgsave 子进程。 另一方面bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然子进程在创建后不会再阻塞主线程但是fork 这个创建过程本身会阻塞主线程而且主线程的内存越大阻塞时间越长。 Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说内存快照以一定的频率执行在两次快照之间使用 AOF 日志记录这期间的所有命令操作。这样一来快照不用很频繁地执行这就避免了频繁 fork 对主线程的影响。而且AOF 日志也只用记录两次快照间的操作也就是说不需要记录所有操作了因此就不会出现文件过大的情况了也可以避免重写开销。
最后关于 AOF 和 RDB 的选择问题我想再给你提三点建议
数据不能丢失时内存快照和 AOF 的混合使用是一个很好的选择 如果允许分钟级别的数据丢失可以只使用 RDB 如果只用 AOF优先使用 everysec 的配置选项因为它在可靠性和性能之间取了一个平衡
