基于内存的分布式NoSQL数据库Redis(五)数据存储与RDB设计

知识点18：数据存储设计

• 目标：掌握常见数据存储的设计

• 实施

  • 问题
    • 数据存储如何保证数据安全？
    • HDFS的数据怎么保证安全性？
    • HDFS的元数据怎么保证安全性？
    • Spark的RDD数据怎么保证安全性？
  • 解决
    • 磁盘存储：数据存储在硬盘上
      • 特点：容量大、安全性高、读写速度上相对不如内存
      • 解决：副本备份
    • 内存存储：数据存储在内存中
      • 特点：容量小、安全性低、读写性能高
      • 解决：副本、持久化到磁盘
    • HDFS的数据怎么保证安全性？
      • 磁盘：副本机制
    • HDFS的元数据怎么保证安全性？
      • 磁盘：fsimage + edits
        • 副本机制：可以配置fsimage存储在多个目录中，每个目录存储一份
      • 内存：启动时加载到内存，在内存进行读写
        • edits：操作日志，NameNode会将内存中元数据的变化记录在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：清空，没有意义

      • 自动触发：按照一定的时间内发生的更新的次数，拍摄快照

        • 配置文件中有对应的配置，决定什么时候做快照

          #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