文章目录
- 知识点18:数据存储设计
- 知识点19:Redis持久化:RDB设计
- 知识点20:Redis持久化:RDB测试
- 后记
 
知识点18:数据存储设计
-  目标:掌握常见数据存储的设计 
-  实施 - 问题 - 数据存储如何保证数据安全?
- HDFS的数据怎么保证安全性?
- HDFS的元数据怎么保证安全性?
- Spark的RDD数据怎么保证安全性?
 
- 解决 - 磁盘存储:数据存储在硬盘上 - 特点:容量大、安全性高、读写速度上相对不如内存
- 解决:副本备份
 
- 内存存储:数据存储在内存中 - 特点:容量小、安全性低、读写性能高
- 解决:副本、持久化到磁盘
 
- HDFS的数据怎么保证安全性? - 磁盘:副本机制
 
- HDFS的元数据怎么保证安全性? - 磁盘:fsimage + edits - 副本机制:可以配置fsimage存储在多个目录中,每个目录存储一份
 
- 内存:启动时加载到内存,在内存进行读写 - edits:操作日志,NameNode会将内存中元数据的变化记录在edits文件中
 
 
- 磁盘:fsimage + edits 
- Spark的RDD数据怎么保证安全性? - 方式一:血缘机制:每个RDD保存与父RDD之间的依赖关系
- 方式二:persist/unpersist:缓存,将RDD缓存在内存或者磁盘中,缓存有副本机制
- 方式三:checkpoint:检查点持久化,将RDD的数据持久在磁盘【HDFS】中
 
 
- 磁盘存储:数据存储在硬盘上 
 
- 问题 
-  小结 
-  掌握常见数据存储的设计 
知识点19:Redis持久化:RDB设计
-  目标:掌握Redis的RDB持久化机制 
-  路径 - step1:问题
- step2:RDB方案
- step3:优缺点
 
-  实施 -  问题 Redis中的数据都存储在内存中,由内存对外提供读写,Redis一旦重启,内存中的数据就会丢失,Redis如何实现持久化?- 写:set/hset/lpush/sadd/zadd
- 写入内存直接返回
- 读:get/hget/lrange/smembers/zrange - 直接读取内存
 
- 每次Redis写入内存,将数据同步到磁盘
- 如果重启,就将磁盘中的数据重新加载到磁盘,提供读取
 
-  RDB方案 -  Redis默认的持久化方案 
-  思想 - 按照一定的时间内,如果Redis内存中的数据产生了一定次数的更新,就将整个Redis内存中的所有数据拍摄一个全量快照文件存储在硬盘上
- 新的快照会覆盖老的快照文件,快照是全量快照,包含了内存中所有的内容,基本与内存一致
- 如果Redis故障重启,从硬盘的快照文件进行恢复
 
-  举例 - 配置:save 30 2
- 解释:如果30s内,redis内存中的数据发生了2条更新【插入、删除、修改】,就将整个Redis内存数据保存到磁盘文件中,作为快照
 
-  过程  
-  触发 -  手动触发:当执行某些命令时,会自动拍摄快照【一般不用】 - save:手动触发拍摄RDB快照的,将内存的所有数据拍摄最新的快照 - 前端运行
- 阻塞所有的客户端请求,等待快照拍摄完成后,再继续处理客户端请求
- 特点:快照与内存是一致的,数据不会丢失,用户的请求会被阻塞
 
- bgsave:手动触发拍摄RDB快照的,将内存的所有数据拍摄最新的快照 - 后台运行
- 主进程会fork一个子进程负责拍摄快照,客户端可以正常请求,不会被阻塞
- 特点:用户请求继续执行,用户的新增的更新数据不在快照中
 
- shutdown:执行关闭服务端命令
- flushall:清空,没有意义
 
- save:手动触发拍摄RDB快照的,将内存的所有数据拍摄最新的快照 
-  自动触发:按照一定的时间内发生的更新的次数,拍摄快照 -  配置文件中有对应的配置,决定什么时候做快照 #Redis可以设置多组rdb条件,默认设置了三组,这三组共同交叉作用,满足任何一个都会拍摄快照 save 900 1 save 300 10 save 60 10000- 为什么默认设置3组?
 
 
-  
 
-  
 
-  
-  原因:如果只有一组策略,面向不同的写的场景,会导致数据丢失 
 - 针对不同读写速度,设置不同策略,进行交叉保存快照,满足各种情况下数据的保存策略
-  优缺点 - 优点 - rdb方式实现的是全量快照,快照文件中的数据与内存中的数据是一致的
- 快照是二进制文件,生成快照加载快照都比较快,体积更小
- Fork进程实现,性能更好
- 总结:更快、更小、性能更好
 
- 缺点 - 存在一定概率导致部分数据丢失
 
 
- 优点 
-  应用:希望有一个高性能的读写,不影响业务,允许一部分的数据存在一定概率的丢失**【做缓存】**,大规模的数据备份和恢复 
 
-  
-  小结 -  什么是RDB机制,优缺点分别是什么? - 思想:在一定时间内如果Redis发生一定次数的更新,就拍摄一个全量快照二进制文件存储在磁盘中
 
-  如果重启,直接加载二进制文件恢复到内存 - 触发 - 手动:bgsave,shutdown
- 自动:save 时间 次数
 
- 特点 - 优点:更小、更快、全量、性能更好
- 缺点:存在一定概率数据丢失
 
- 场景:大规模数据缓存或者数据备份和恢复
 
- 触发 
 
-  
知识点20:Redis持久化:RDB测试
-  目标:实现RDB持久化的测试 
-  实施 -  查看当前快照 ll /export/server/redis/datas/ 
-  配置修改 cd /export/server/redis vim redis.conf #202行 save 900 1 save 300 10 save 60 10000 save 20 2
-  重启redis服务,配置才会生效 shutdown redis-start.sh
 
-  
-  插入数据 set s1 "laoda"set s2 "laoliu"set s3 "laoliu"
-  查看dump的rdb快照 ll /export/server/redis/datas/ 
-  小结 - 实现RDB持久化的测试
 
后记
📢博客主页:https://manor.blog.csdn.net
📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正!
 📢本文由 Maynor 原创,首发于 CSDN博客🙉
 📢不能老盯着手机屏幕,要不时地抬起头,看看老板的位置⭐
 📢专栏持续更新,欢迎订阅:https://blog.csdn.net/xianyu120/category_12394313.html