11/6笔记 补充(Redis持久化,RDB&&AOF)

Anthony-bird 2020-11-07 21:19:23
redis 笔记 持久 补充 rdb&&aof


11/6补充笔记

修改redis-6379.conf里面的save10秒2个数据发生改变 (save 10 2)

修改一次数据不发生改变,修改2次数据才发生改变

继续修改数据,发现还是一样的规律

增删该都发生变化,除了查以外。

save配置原理

返回结果,要对数据产生影响,数据发生了变化,或者变量达到设置要求,rdb才会发生变化。save配置要根据真实场景进行设置,否则性能可能出现问题,save配置后执行的是bgsave操作。

RDB2种启动方式对比

save指令在读写的过程中是同步的,而不敢save是异步的,save指令会阻塞客服端,bgsave读写的过程是异步的,会创建子线程(相当于启动了新进程),不会造成客服端堵塞,但会造成额外消耗内存。

rdb特殊启动指令

服务器运行过程中重启

debug reload

关闭服务器是指定保存数据

shutdown save(不管是够开启,自动执行bgsave)

RDB优点与缺点

优点:

RDB是一个紧凑压缩的二进制文件,代表Redis在某个时间点上的数据快照。非常适用于备份,全量复制等场景。比如每2小时执行bgsave备份, 并把RDB文件拷贝到远程机器或者文件系统中(如hdfs),用于灾难恢复。RDB恢复数据远远快于AOF的方式。

缺点:

RDB方式数据没办法做到实时持久化/秒级持久化,可能保存的数据不是很完整。因为bgsave每次运行都要执行fork操作创建子进程,会额外消耗性能,频繁执行成本过高。RDB文件使用特定二进制格式保存,Redis版本更新过程中有多个格式的RDB版本,存在老版本Redis服务数据格式无法兼容新版RDB格式的问题。

AOF

使用AOF的原因:针对RDB不适合实时持久化的问题,Redis提供了AOF持久化方式来解决。

概念

AOF(append only file)持久化:以日志的方式记录数据产生的过程(每次写入时命令), 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式

AOF写数据三种策略(appendfsync)

always(每次),每次把写入操作同步到AOF文件中,数据完整,性能较低.

everysec(每秒),每秒将缓冲区同步到AOF文件中,数据准确性和性能较高,一般都是使用这个指令,也是默认配置

no(系统控制),由操作系统控制每次同步到AOF中,整体不可控

实操:

配置:appendfilename配置为appendonly.aof,如果是多端口号的话,建议配置为appendonly-端口号.aof

1.进入conf目录配置redis-6379的conf文件

2.添加以下命令,开启持久化功能(appendonly yes|no),配置写数据策略(appendfsync always |everysec|no)

3.先杀死原来的服务进程,再重新用配置文件启动

4.进入data,查看文档是否多了一个aof的文件

5.添加数据发现文件变大了

6.在使用everysec指令,重启服务端,在修改数据之前查看文件大小

7.在写入数据之后,查看文件大小,和cat 文件.aof日志,发现修改数据日志成功

AOF重写

随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的。

就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

目的:AOF重写节省了文件占用空间,提高数据恢复效率,更小的AOF 文件可以更快地被Redis加载.

AOF重写方式:手动和自动

手动:bgrewriteaof(后台重新写入aof)

自动: auto-aof-rewrite-min-size size

 `auto-aof-rewrite-percentage` *percentage*

修改配置文件

启动客服端修改数据

查看文件和查看aof文档数据

修改之后,启动bgrewriteaof会出现以下提示

再次查看文件大小明显变小了

当我查看aof数据过程的时候是乱码,反正文件是被压缩了.

AOF手动重写 :bgrewriteaof指令工作原理

与bgsave指令相似,首先也是发送指令(控制台会反馈Background append only file rewriting started),调用fork函数生成子进程,重写.aof文件,返回消息.

AOF自动重写

自动重写触发条件设置 auto-aof-rewrite-min-size size自动重写最小体积,默认为64MB。

auto-aof-rewrite-percentage percent代表当前AOF文件空间 和上一次重写后AOF文件空间的比值。

aof_current_size AOF文件空间 aof_base_size上一次重写后AOF文件空间

自动重写触发时机

aof_current_size>auto-aof-rewrite-min-size &&(aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage

在客服端输入info,可以看到 Persistence(持久化),关于持久化的东西,

AOF重写流程

RDB与AOF区别

RDB产生的文件紧凑压缩比更高,占用储存空间小,因此读取RDB恢复速度更快。由于每次生成RDB开销较大,储存速度很慢,可能会丢失数据,RDB在消耗资源是重量级的,相对于AOF启动优先级很低。

AOF通过追加写命令到文件实现持久化,通过appendfsync参数可以控制实时/秒级持久化。因为需要不断追加写命令,所以AOF文件体积逐渐变大,需要定期执行重写操作来降低文件体积。由于体积很大,所以占用的储存空间很大,与RDB相比,是相反的,占用的储存空间很大,存储速度很快,恢复的速度比较慢,因为是记录的数据的储存过程,经过重写之后会变小,AOF在消耗资源方面是轻量级的,在不同的场景更改策略可以提高数据的安全性。

RDB与AOF的选者

对数据的过程很敏感,而且不要求恢复速度的话,建议使用AOF,

对数据要求完整性,建议使用RDB持久化方案,切恢复速度很快。

如果能承受数分钟以内的数据丢失,且追求恢复速度,选用RDB

如不能承受数分钟以内的数据丢失,对业务数据非常敏感,选用AOF

或者两者同时启用,优先使用AOF恢复数据,降低数据丢失的量。

持久化应用场景

应用于抢购,限购类、限量发放优惠卷、激活码等业务的数据存储设计,应用于具有操作先后顺序的数据控制,应用于最新消息展示,应用于控制黑名单设定的服务控制,应用于计数器组合排序功能对应的排名。

版权声明
本文为[Anthony-bird]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/zzy8080/p/13942367.html

  1. 【计算机网络 12(1),尚学堂马士兵Java视频教程
  2. 【程序猿历程,史上最全的Java面试题集锦在这里
  3. 【程序猿历程(1),Javaweb视频教程百度云
  4. Notes on MySQL 45 lectures (1-7)
  5. [computer network 12 (1), Shang Xuetang Ma soldier java video tutorial
  6. The most complete collection of Java interview questions in history is here
  7. [process of program ape (1), JavaWeb video tutorial, baidu cloud
  8. Notes on MySQL 45 lectures (1-7)
  9. 精进 Spring Boot 03:Spring Boot 的配置文件和配置管理,以及用三种方式读取配置文件
  10. Refined spring boot 03: spring boot configuration files and configuration management, and reading configuration files in three ways
  11. 精进 Spring Boot 03:Spring Boot 的配置文件和配置管理,以及用三种方式读取配置文件
  12. Refined spring boot 03: spring boot configuration files and configuration management, and reading configuration files in three ways
  13. 【递归,Java传智播客笔记
  14. [recursion, Java intelligence podcast notes
  15. [adhere to painting for 386 days] the beginning of spring of 24 solar terms
  16. K8S系列第八篇(Service、EndPoints以及高可用kubeadm部署)
  17. K8s Series Part 8 (service, endpoints and high availability kubeadm deployment)
  18. 【重识 HTML (3),350道Java面试真题分享
  19. 【重识 HTML (2),Java并发编程必会的多线程你竟然还不会
  20. 【重识 HTML (1),二本Java小菜鸟4面字节跳动被秒成渣渣
  21. [re recognize HTML (3) and share 350 real Java interview questions
  22. [re recognize HTML (2). Multithreading is a must for Java Concurrent Programming. How dare you not
  23. [re recognize HTML (1), two Java rookies' 4-sided bytes beat and become slag in seconds
  24. 造轮子系列之RPC 1:如何从零开始开发RPC框架
  25. RPC 1: how to develop RPC framework from scratch
  26. 造轮子系列之RPC 1:如何从零开始开发RPC框架
  27. RPC 1: how to develop RPC framework from scratch
  28. 一次性捋清楚吧,对乱糟糟的,Spring事务扩展机制
  29. 一文彻底弄懂如何选择抽象类还是接口,连续四年百度Java岗必问面试题
  30. Redis常用命令
  31. 一双拖鞋引发的血案,狂神说Java系列笔记
  32. 一、mysql基础安装
  33. 一位程序员的独白:尽管我一生坎坷,Java框架面试基础
  34. Clear it all at once. For the messy, spring transaction extension mechanism
  35. A thorough understanding of how to choose abstract classes or interfaces, baidu Java post must ask interview questions for four consecutive years
  36. Redis common commands
  37. A pair of slippers triggered the murder, crazy God said java series notes
  38. 1、 MySQL basic installation
  39. Monologue of a programmer: despite my ups and downs in my life, Java framework is the foundation of interview
  40. 【大厂面试】三面三问Spring循环依赖,请一定要把这篇看完(建议收藏)
  41. 一线互联网企业中,springboot入门项目
  42. 一篇文带你入门SSM框架Spring开发,帮你快速拿Offer
  43. 【面试资料】Java全集、微服务、大数据、数据结构与算法、机器学习知识最全总结,283页pdf
  44. 【leetcode刷题】24.数组中重复的数字——Java版
  45. 【leetcode刷题】23.对称二叉树——Java版
  46. 【leetcode刷题】22.二叉树的中序遍历——Java版
  47. 【leetcode刷题】21.三数之和——Java版
  48. 【leetcode刷题】20.最长回文子串——Java版
  49. 【leetcode刷题】19.回文链表——Java版
  50. 【leetcode刷题】18.反转链表——Java版
  51. 【leetcode刷题】17.相交链表——Java&python版
  52. 【leetcode刷题】16.环形链表——Java版
  53. 【leetcode刷题】15.汉明距离——Java版
  54. 【leetcode刷题】14.找到所有数组中消失的数字——Java版
  55. 【leetcode刷题】13.比特位计数——Java版
  56. oracle控制用户权限命令
  57. 三年Java开发,继阿里,鲁班二期Java架构师
  58. Oracle必须要启动的服务
  59. 万字长文!深入剖析HashMap,Java基础笔试题大全带答案
  60. 一问Kafka就心慌?我却凭着这份,图灵学院vip课程百度云