vi设计网站大全,织梦本地做网站,wordpress爆破工具,简单html5网页设计AOF的回顾 回顾Redis 的AOF的持久化机制。 Redis 避免数据丢失的 AOF 方法。这个方法的好处#xff0c;是每次执行只需要记录操作命令#xff0c;需要持久化的数据量不大。一般而言#xff0c;只要你采用的不是 always 的持久化策略#xff0c;就不会对性能造成太大影响。 …AOF的回顾 回顾Redis 的AOF的持久化机制。 Redis 避免数据丢失的 AOF 方法。这个方法的好处是每次执行只需要记录操作命令需要持久化的数据量不大。一般而言只要你采用的不是 always 的持久化策略就不会对性能造成太大影响。 但是也正因为记录的是操作命令而不是实际的数据所以用 AOF 方法进行故障恢复 的时候需要逐一把操作日志都执行一遍。如果操作日志非常多Redis 就会恢复得很缓 慢影响到正常使用。那这就引出了这篇文章所写的内存快照。所谓内存快照就是指内存中的数据在某一个时刻的状态记录。 对 Redis 来说它实现类似照片记录效果的方式就是把某一时刻的状态以文件的形式写 到磁盘上也就是快照。这样一来即使宕机快照文件也不会丢失数据的可靠性也就 得到了保证。这个快照文件就称为 RDB 文件其中RDB 就是 Redis DataBase 的缩 写。 和 AOF 相比RDB 记录的是某一时刻的数据并不是操作这样恢复数据会很快那为啥不直接把RDB作为最优选呢 我们需要考虑两件事情 对哪些数据做快照这关系到快照的执行效率问题 做快照时数据还能被增删改吗这关系到 Redis 是否被阻塞能否同时正常处理请求。
给哪些内存数据做快照 Redis 的数据都在内存中为了提供所有数据的可靠性保证它执行的是全量快照也就 是说把内存中的所有数据都记录到磁盘中这就类似于给 100 个人拍合影把每一个人 都拍进照片里。这样做的好处是一次性记录了所有数据一个都不少。 当你给一个人拍照时只用协调一个人就够了但是拍 100 人的大合影却需要协调 100 个人的位置、状态等等这当然会更费时费力。同样给内存的全量数据做快照 把它们全部写入磁盘也会花费很多时间。而且全量数据越多RDB 文件就越大往磁盘 上写数据的时间开销就越大。 对于 Redis 而言它的单线程模型就决定了我们要尽量避免所有会阻塞主线程的操作 所以针对任何操作我们都会提一个灵魂之问“它会阻塞主线程吗?”RDB 文件的生成 是否会阻塞主线程这就关系到是否会降低 Redis 的性能。 Redis 提供了两个命令来生成 RDB 文件分别是 save 和 bgsave save在主线程中执行会导致阻塞 bgsave创建一个子进程专门用于写入 RDB 文件避免了主线程的阻塞这也是 Redis RDB 文件生成的默认配置。 好了这个时候我们就可以通过 bgsave 命令来执行全量快照这既提供了数据的可靠 性保证也避免了对 Redis 的性能影响。
接下来我们要关注的问题就是在对内存数据做快照时这些数据还能“动”吗? 也就是 说这些数据还能被修改吗 这个问题非常重要这是因为如果数据能被修改那就意 味着 Redis 还能正常处理写操作。否则所有写操作都得等到快照完了才能执行性能一 下子就降低了。
快照时数据能修改吗?
在给别人拍照时一旦对方动了那么这张照片就拍糊了我们就需要重拍所以我们当 然希望对方保持不动。对于内存快照而言我们也不希望数据“动”。
举个例子。我们在时刻 t 给内存做快照假设内存数据量是 4GB磁盘的写入带宽是 0.2GB/s简单来说至少需要 20s4/0.2 20才能做完。如果在时刻 t5s 时一个 还没有被写入磁盘的内存数据 A被修改成了 A’那么就会破坏快照的完整性因为 A’不是时刻 t 时的状态。因此和拍照类似我们在做快照时也不希望数据“动”也就 是不能被修改。
但是如果快照执行期间数据不能被修改是会有潜在问题的。对于刚刚的例子来说在 做快照的 20s 时间里如果这 4GB 的数据都不能被修改Redis 就不能处理对这些数据的 写操作那无疑就会给业务服务造成巨大的影响。
你可能会想到可以用 bgsave 避免阻塞啊。这里我就要说到一个常见的误区了避免阻 塞和正常处理写操作并不是一回事。此时主线程的确没有阻塞可以正常接收请求但 是为了保证快照完整性它只能处理读操作因为不能修改正在执行快照的数据。
为了快照而暂停写操作肯定是不能接受的。所以这个时候Redis 就会借助操作系统提 供的写时复制技术Copy-On-Write, COW在执行快照的同时正常处理写操作。
简单来说bgsave 子进程是由主线程 fork 生成的可以共享主线程的所有内存数据。 bgsave 子进程运行后开始读取主线程的内存数据并把它们写入 RDB 文件。
此时如果主线程对这些数据也都是读操作例如图中的键值对 A那么主线程和 bgsave 子进程相互不影响。但是如果主线程要修改一块数据例如图中的键值对 C 那么这块数据就会被复制一份生成该数据的副本。然后bgsave 子进程会把这个副本 数据写入 RDB 文件而在这个过程中主线程仍然可以直接修改原来的数据。 这既保证了快照的完整性也允许主线程同时对数据进行修改避免了对正常业务的影 响。
到这里我们就解决了对“哪些数据做快照”以及“做快照时数据能否修改”这两大问 题Redis 会使用 bgsave 对当前内存中的所有数据做快照这个操作是子进程在后台完 成的这就允许主线程同时可以修改数据。 现在我们再来看另一个问题多久做一次快照我们在拍照的时候还有项技术叫“连 拍”可以记录人或物连续多个瞬间的状态。那么快照也适合“连拍”吗
可以每秒做一次快照吗
连拍的间隔比较大的话就是你当及两次拍照的之间发生宕机的话丢失的数据就会很多。
但是如果连拍间隔非常小的话虽然 bgsave 执行时不阻塞主线程但是如果频繁地执行全量 快照也会带来两方面的开销。
一方面频繁将全量数据写入磁盘会给磁盘带来很大压力多个快照竞争有限的磁盘带 宽前一个快照还没有做完后一个又开始做了容易造成恶性循环。
另一方面bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然子进程在创建后 不会再阻塞主线程但是fork 这个创建过程本身会阻塞主线程而且主线程的内存越 大阻塞时间越长。如果频繁 fork 出 bgsave 子进程这就会频繁阻塞主线程了。那么 有什么其他好方法吗
此时我们可以做增量快照所谓增量快照就是指做了一次全量快照后后续的快照 只对修改的数据进行快照记录这样可以避免每次全量快照的开销
在第一次做完全量快照后T1 和 T2 时刻如果再做快照我们只需要将被修改的数据写入 快照文件就行。但是这么做的前提是我们需要记住哪些数据被修改了。你可不要小瞧 这个“记住”功能它需要我们使用额外的元数据信息去记录哪些数据被修改了这会带 来额外的空间开销问题。如下图所示 但是我们两次拍照之间有1万键值对别更改了。但是存出这个增量的空间很有效。所以这个增量的只适用于修改次数少的。
到这里你可以发现虽然跟 AOF 相比快照的恢复速度快但是快照的频率不好把 握如果频率太低两次快照间一旦宕机就可能有比较多的数据丢失。如果频率太高 又会产生额外开销那么还有什么方法既能利用 RDB 的快速恢复又能以较小的开销做 到尽量少丢数据呢
AOF和RDB混合使用
Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说内存快照以一 定的频率执行在两次快照之间使用 AOF 日志记录这期间的所有命令操作。
这样一来快照不用很频繁地执行这就避免了频繁 fork 对主线程的影响。而且AOF 日志也只用记录两次快照间的操作也就是说不需要记录所有操作了因此就不会出 现文件过大的情况了也可以避免重写开销。
如下图所示T1 和 T2 时刻的修改用 AOF 日志记录等到第二次做全量快照时就可 以清空 AOF 日志因为此时的修改都已经记录到快照中了恢复时就不再用日志了。 这个方法既能享受到 RDB 文件快速恢复的好处又能享受到 AOF 只记录操作命令的简单 优势颇有点“鱼和熊掌可以兼得”的感觉。
