Redis核心技术与实战-学习笔记（五）内存快照RDB
一.为什么需要RDB
AOF 方法优势：每次执行只需要记录操作命令，需要持久化的数据量不大。在进行写后日志只要不采用always(同步写回)的持久化策略就不会对性能造成太大影响。
AOF方法劣势：AOF在进行故障恢复时候，需要逐一把操作日志都执行一遍，如果操作日志非常多，Redis就会恢复的非常缓慢，影响到正常使用。
内存快照。所谓内存快照，就是将内存中的数据在某一时刻的状态记录，这就类似于照片。
RDB:Redis DataBase，它实现类似于照片记录效果的方式，将某一时刻的状态以文件形式写入到磁盘，也就是快照。RDB记录的是某一时刻的数据而不是AOF的操作，所以在做数据恢复时，直接把RDB读入内存，很快完成恢复。
二.一次性记录所有数据
Redis的数据都存在内存中，为了提供所有数据的可靠性保证，他执行的是全量快照，将内存中的所有数据都记录在磁盘中，一次性记录所有数据。
Redis提供了两个命令来生成RDB文件，分别是save和bgsave。
save：在主线程中执行，会导致阻塞;
bgsave:创建一个子进程，专门用于写入RDB文件，避免主线程阻塞，这也是Redis RDB文件生成默认配置。
通过bgsave命令来执行全量快照，这既提供了数据的可靠性保证也避免了对Redis性能的影响。
通过 bgsave 命令来执行全量快照，这既提供了数据的可靠性保证，也避免了对 Redis 的性能影响。
三.快照时数据可以修改吗
在给别人拍照时候，一旦对方动了，这张照片就拍糊了，那么我们就需要重拍，所以当然希望对方可以保持不动。对于内存快照而言，我们也不希望数据动。
举例：在时刻t给内存生成快照，假设内存数据量是4GB,磁盘写入带宽是0.2GB/s,至少需要20s
(4/0.2=20)才能执行完，这时候在t+5s时，一个还没有被写入磁盘的内存数据从A,被修改为A+,那么就会破坏快照完整性，因为A+不是时刻t时的状态。因此，和拍照类似，我们做快照时候不希望数据动，也就是不能被修改。
但是，如果快照执行期间数据不能被修改，例如刚刚的例子：在做快照的20s时间里，如果4GB的数据都不能被修改，Redis就不能对这些数据进行写操作。那么服务就被阻塞住了。
bgsave避免阻塞，是指主线程可以正常接收请求，但是为了保证快照的完整性，他只能处理读操作，因此不能修改正在执行快照的数据。
为了快照而暂停写操作，是不可以接收。所以这时候，Redis会借助操作系统提供的写时复制技术（Copy-On-Write,COW），在执行快照期间可以正常处理读写操作。
总结：bgsave子进程是由主线程fork生成，可以共享主线程的所有内存数据。bgsave子进程运行后，开始读取主线程的内存数据，并把它们写入RDB文件。
此时，如果主线程对这些数据也都是读操作。那么，主线程和bgsave子进程互不影响。但是，主线程要修改一块数据，那么该数据就会在修改前被复制一份，生成该数据的副本，然后主线程在这个数据副本上进行修改。同时，bgsave子进程可以继续把原来数据写入RDB文件。
写时复制机制保证快照期间数据可以修改。
四.可以每秒做一次快照吗？
如果bgsave执行时不阻塞主线程，但是如果频繁执行全量快照会带来两方面的开销：
- 频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照没结束，后一个快照又开始了，容易造成恶性循环。
- bgsave子进程需要通过fork操作从子进程创建出来。子进程在创建后不会阻塞主线程，但是fork这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长，如果频繁fork出bgsave子进程，这就会频繁阻塞主线程。（Redis如果有一个bgsave在执行了，就不会启动第二个子进程了）
五. 增量快照
做一次全量快照以后，后续的快照只对修改的数据进行快照记录，这样以增量的方式避免每次全量快照的开销。
在第一次做完全量快照以后，T1和T2时刻如果在做快照，我们只需要将修改的数据写入快照文件就行。但是，这样做的前提是，我们需要记住哪些数据被修改了。但是记住这个功能，我们使用额外的元数据信息记录哪些数据被修改了。这会带来额外的空间开销问题。
如下图所示：
如果我们对每一个键值对的修改，都做个记录，那么，如果有 1 万个被修改的键值对，我们就需要有 1 万条额外的记录。而且，有的时候，键值对非常小，比如只有 32 字节，而记录它被修改的元数据信息，可能就需要 8 字节，这样的画，为了“记住”修改，引入的额外空间开销比较大。这对于内存资源宝贵的 Redis 来说，有些得不偿失。
快照频率过低，一旦宕机，损失数据较多。频率较高，额外开销较高。
六.Redis4.0混合使用AOF日志和内存快照
内存快照以一定频率执行，在两次快照之间，使用AOF记录这期间所有的命令操作。
快照不用很频繁的执行，避免频繁fork对主线程的影响。
AOF日志也只用记录两次快照间的操作，不需要记录所有操作，因此，就不会出现文件过大情况，也可以避免重写开销。
T1和T2时刻的修改，用AOF日志记录，等到第二次做全量快照时，就可以清空AOF日志，因此此时的修改都记录到快照中了，恢复时就不再用日志。
既可以享受RDB文件快速恢复的好处，又可以享受AOF只记录操作命令的简单优势：鱼和熊掌可以得兼。
AOF和RDB的选择问题
| 数据不能丢失 | RDB和AOF混合使用 |
| 允许分钟级别数据丢失 | 使用RDB |
| 只用AOF | 有限使用everysec配置选项 |
七.课后习题
使用一个2核CPU,4GB内存，500GB磁盘的云主机运行Redis,Redis数据库的数据量差不多是2GB,我们使用RDB做持久化保证，当Redis的运行负载以修改操作为主，写读比例差不多是8:2（100个请求80个写操作）。这种情况下RDB做持久化的风险？
此时风险主要在于CPU资源和内存资源2个方面：
- 内存资源风险：Redis fork子进程做RDB持久化，由于写的比例是百分之80，那么"写时复制" 会重新分配整个实例百分之80的内存副本，大约需要重新分配1.6GB内存空间，这样整个系统内存接近饱和3.6GB/4GB。此时父进程写入大量key时，很快机器内存会被吃光，当机器开启了swap机制，那么Redis会有一部分数据被换到磁盘上，当Redis访问这部分磁盘上的数据，性能会急剧下降，当机器没有开始swap，会导致内存溢出oom,父子进程面临被系统kill的风险。
- CPU资源风险：在fork bgsave子进程时候会消耗大量cpu资源。Redis server还有其他线程在后台工作，例如每秒AOF刷盘，异步关闭文件描述符等，由于机器只有2核cpu，这意味着父进程占用超过一半cpu资源，此时子进程做RDB持久化，可能会产生cpu竞争，导致父进程处理请求延迟增大，子进程生成RDB快照的时间也会变长，整个Redis Server性能下降。
- Redis进程是否绑定cpu,如果绑定cpu子进程会继承父进程的cpu亲和性属性，子进程必然会与父进程争夺同一cpu资源，整个Redis Server性能下降。所以如果Redis需要开启定时RDB和AOF重写，进程一定不要绑定CPU。
Redis核心技术与实战-学习笔记（五）内存快照RDB相关推荐
- Redis核心技术与实战-学习笔记（三十五）Redis使用建议
键值对使用规范 key的命令规范,只有命名规范,才能提供可读性强,可维护性好的key,方便日常管理: value的设计规范,包括避免bigkey,选择高效序列化方法和压缩方法,使用整数对象共享池,数据 ...
- Redis核心技术与实战-学习笔记（十五）：消息队列（Redis的解决方案）
一.消息队列 消息队列:分布式系统必备的一个基础软件,能支持组件通信消息的快速读写 Redis本身支持数据的快速访问,满足消息队列的读写性能需求 二.Redis适合做消息队列吗? 消息队列的消息存取需 ...
- Redis核心技术与实战-学习笔记（二十九）：Redis并发控制
一.需要并发控制的原因 Redis不可避免的会遇到并发访问问题,比如多用户同时下单,就会对缓存在Redis中的商品库存并发更新,一旦有了并发操作,数据就会被修改,如果我们没有对并发写请求做好控制,就可 ...
- Redis核心技术与实战-学习笔记（二十六）：缓存雪崩、击穿、穿透
一.缓存雪崩 缓存雪崩:大量应用请求无法在Redis缓存中进行处理,应用请求频繁访问数据库,导致数据库压力激增. 产生原因: 缓存中有大量数据同时过期,导致大量请求无法得到处理 数据保存在缓存中,并设 ...
- Redis核心技术与实战-学习笔记（七）哨兵机制
一.主库挂了,如何不间断服务? 主库挂了,需要运行一个新的主库:将从库切换为主库.这就涉及到三个问题: 主库真的挂了吗? 选择哪个从库作为主库? 如何把新主库相关信息通知给从库和客户端 Redis主从 ...
- Redis核心技术与实战-学习笔记（十四）：时间序列数据
一.时间序列数据 时间序列数据:没有严格的关系模型,记录的信息可以表示成键和值的关系. (例如,一个设备ID对应一条记录): 时间序列数据的读写特点 持续高并发写入,需要连续记录数万个设备的实时状态值 ...
- Elasticsearch核心技术与实战学习笔记 43 | 分页与遍历：From, Size, Search After Scroll API
一 序 本文属于极客时间Elasticsearch核心技术与实战学习笔记系列. 二 分页 2.1 From / Size 默认情况下,查询按照相关度算分排序,返回前 10 条记录 容易理解的分页方案 ...
- Redis运维和开发学习笔记(7) 内存管理和过期策略
Redis运维和开发学习笔记(7) 内存管理和过期策略 文章目录 Redis运维和开发学习笔记(7) 内存管理和过期策略 内存回收策略 惰性删除 定时任务删除 maxmemory 过期策略allkey ...
- Kafka 核心技术与实战学习笔记（二十四）请求处理过程
一.请求/响应 所有的请求都是通过 TCP 网络以 Socket 的方式进行通讯的. Apache Kafka自定义的请求协议: PRODUCE请求是用于生产消息的 FETCH请求是用于消费消息的 M ...
最新文章
- Linux包管理器apt/apt-get发现远程代码执行漏洞
- pytorch元素相乘_PyTorch – 变量和张量之间的元素乘法？
- python3用什么系统好_学python用什么系统【怎么学好python】
- 【年终总结】2021年有三AI做了什么，2022年我们要做什么？
- 七夕节，程序员们都怎么哄女朋友开心？
- MySQL数据库-笔记03【范式（1NF、2NF、3NF）、查询练习题*10道（附解析）】
- PHP-代码审计-代码执行
- 广州元宇宙10条（附pdf下载地址）
- ubuntu18.04 init setting
- 电脑系统怎么修改图片格式
- php 降低采样率,讨论采样频率、采样深度（位深）、音量调节对音质的影响
- 想让Word文档更整齐，这五个Word排版技巧少不了
- VMware中性能分配的问题
- eig()函数求特征值、特征向量、归一化
- Unity EditorWindow Rename
- 时光机穿梭-管理修改
- Node.js 的安装（电脑win7支持的版本）
- MySQL 数据库基础（一）（数据库的简介）
- 图书管理系统 jsp + servlet + mysql （2023）
- 招聘巨头Monster公司宣布全面收购中华英才网