网站建设朋友圈素材,wordpress图片加标签,软文大全800字,桂林市地图全图高清版我们知道 Redis 之所以读写快、性能高#xff0c;得益于它是一种基于内存的数据库#xff0c;毫无疑问它的操作都几乎都是基于内存。但是内存型数据库也有一个很大的弊端#xff1a;如果进程崩溃或者服务重启的时候内存数据得不到保存#xff0c;就会造成数据丢失。为了解决…我们知道 Redis 之所以读写快、性能高得益于它是一种基于内存的数据库毫无疑问它的操作都几乎都是基于内存。但是内存型数据库也有一个很大的弊端如果进程崩溃或者服务重启的时候内存数据得不到保存就会造成数据丢失。为了解决这个问题 Redis 提供了两种持久化方式 RDB 和 AOF 。今天笔者主要和大家一起探讨 Redis 的 AOF 模式是如何运行的。AOF 详解AOF 是 Append Only File 的缩写默认是关闭的。当 Redis 启动时只要开启 AOF 模式就会通过 AOF 文件恢复数据否则将从 RDB 快照文件中恢复数据。开启 AOF 模式需要将 redis.conf 中默认的 appendonly no 改为 appendonly yes 。AOF 开启后 Redis 内部会维护一份 AOF 文件AOF 文件可以看做是 Redis 的日志文件。Redis 服务使用其通信协议的格式将更新命令保存到 AOF 文件中所以文件内容容易被人读懂我们在维护时能够轻松的对文件进行分析。工作原理Redis 内部维护了一个缓冲区 aof_buf Redis 服务如果发现有更新命令这些更新命令不是被直接写入到 AOF 文件中的而是会被先以 Redis 通信协议的格式追加到 aof_buf 中(命令追加)维护 aof_buf 缓冲区的同时会执行 appendfsync 策略(写入和同步策略)。持久化的过程了解 appendfsync 策略之前我们先要搞清楚 AOF 持久化的过程它一共有三步1)命令追加更新命令追加写入到 aof_buf 中。2)文件写入执行 write 操作写入到系统缓冲区。3)文件同步从系统缓冲区同步到磁盘中。同步策略(appendfsync)1)alwaysRedis 每次执行更新命令将 aof_buf 中内容写入并同步到 AOF 文件中。 该策略每次执行更新命令触发每次发生数据变更就会立刻同步到到磁盘。always 策略2)everysec 将 aof_buf 缓冲区所有内容写入到 AOF 文件如果上次同步时间距离现在超过1秒钟那么再次对 AOF 文件进行同步这个操作是由一个线程专门负责执行的。everysec 策略持久化性能较好但是宕机时会造成数据丢失。everysec 策略3)no将 aof_buf 中的内容写入到 AOF 文件中但并不对 AOF 同步何时同步由操作系统来决定。no 策略我们可以看到三种策略都是将 aof_buf 缓冲区的所有内容写入到 aof 文件只是同步时操作不一样。在操作系统中除非设置了自动同步否则为了减少磁盘的写入量延长磁盘寿命、提高文件写入效率。写入文件时并不是同步写入到磁盘中而是先写入内存这段内存区域被称为系统缓冲区。在系统缓冲区数据累计到一定数量后(具体数量因系统实际设置而定)会有系统进程一次性写入所有缓冲数据。因此只有等到同步执行完毕这是才是持久化完成。always 的优点是数据安全效率太低因为过于频繁的调用系统只有在这种策略下redis的事务是满足持久化的。no 的优点是效率较高但是不够安全因为 aof_buf 中的数据可能因为宕机而丢失。ererysec 介于两者之间在效率和安全之间达到一个平衡。这里我们又一次看到折中思想在计算机中的应用。AOF 的重写机制AOF 文件由于不断写入会变得越来越大。通过分析 AOF 文件往往发现里面有太多的重复和冗余数据重写策略就是成一个新的 AOF 文件来代替旧的 AOF 文件这个操作在满足一定条件 Redis 会自动触发。当 AOF 文件大小从 0 增长到指定大小时会触发 AOF 的第一次 rewrite 操作Redis 会 fork 出来一个进程(这样主进还可以程继续处理命令fork出来的子进程带有主进程的数据副本可以在避免锁的情况下保证数据的一致性)通过 bgRewriteAOF 命令完成基于当前数据生成新 AOF 文件。在此期间 Redis 如果收到新的更新命令Redis 会将命令暂时保存在内存。等待新的 AOF 文件生成后Redis 会将内存中的命令追加到新 AOF 文件中。新 AOF 完成后Redis 会删除旧的 AOF 文件。当新的 AOF 文件扩大到2倍的时候会触发第二次 rewrite。在重写期间主进程继续处理命令而新的命令有可能还会对现在有数据进行修改这会导致当前数据库中的数据和生成的 AOF 文件不一致。Redis 维护了一个 AOF 重写缓冲区 rewrite_buf 主进程接收到更新命令后把命令写入到 rewrite_buf 中。这样主进程在接收到跟新命令的时候一边将命令写入 aof_buf (重写执行是)一边写入到 rewrite_buf 中(重写的时候会保持继续更新旧 AOF 文件)。fork 出来的子进程完成 bgRewriteAOF 操作后会向主进程发送信号会执行一个信号处理函数 1)将 rewrite_buf 中的数据全量写到新的 AOF 文件中。2)重命名新 AOF 文件覆盖旧文件。信号处理函数完成时主进程会短暂阻塞。AOF 优势劣势有哪些呢优势1)AOF 模式带来了更高数据安全性的数据持久化解决方案。2)AOF 模式对日志文件的写入操作采用的是 append 模式因此在写入过程中即使出现宕机现象也不会破坏日志文件中已经存在的内容。如果我们数据写入了一半出现了宕机现象 redis-check-aof 工具可以帮我们解决问题感兴趣同学们可以去研究下。3)如果日志过大Redis 有自动启动的 rewrite 机制。即 Redis 以 append 模式不断的将修改数据写入到老的磁盘文件中同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行 rewrite 切换时可以更好的保证数据安全性。4) AOF 包含一个格式清晰、易于理解的日志文件用于记录所有的更新操作。事实上我们也可以通过该文件完成数据的重建。劣势1)由于 AOF 格式是 Redis 通信协议并且文件是命令 append 因此通常要大于 RDB 模式下产生的 .rdb 文件。RDB 模式产生的是数据快照文件小海量数据集时 RDB 模式恢复速度会比 AOF 快。2)同步策略与 RDB 模式AOF 在运行效率上往往会慢于 RDB 。但是everysec 同步策略的效率也是是比较高的no 同步策略的效率和RDB一样高效。总结Redis 的两种持久化机制各有优劣AOF 模式是牺牲性能换取数据数据一致性 RDB 模式则是牺牲一致性换取更高性能。同学们选型时需要根据业务场景合理的使用。想了解 RDB 持久化模式的同学可以关注下下回再一起聊一聊~点击收藏、关注不迷路欢迎大家评论区留言讨论~
