• Home
  • 归档
文章检索 作品与友邻 关于我
暴君乔博客
Home 归档

redis持久化的秘密

发布于: 2021-02-12
更新于: 2023-07-09
文章目录
  1. redis
    1. 持久化
    2. redis持久化

redis

基于内存的高速存取数据库模型,key-val键值对模式

持久化

持久化细节介绍

因为是基于内存的,所以当服务器宕机或者异常时,内存数据会丢失,“持久化”就该上场解决问题了。
关于持久化细节主要参考了官方文档 详情戳此(╯‵□′)╯︵┻━┻

首先需要了解OS(operate System)和disk(磁盘)间的交互,有助于更好地理解持久化这个过程

  1. 客户发送写命令到数据库(此时数据仍在客户端的内存中)
  2. 数据库接收到写命令(此时数据存储于服务器的内存)
  3. 数据库调用底层命令写数据到磁盘中(数据存储于内核的缓存中)
  4. 操作系统将写缓存传输给磁盘控制器(数据存储于磁盘缓存)
  5. 磁盘控制器将数据写到物理媒介上(磁性磁盘etc)

关于上面的五个模型是极其简单的,比较抽象。第二步数据库接收到写命令是内存数据库中极为复杂的一环,当接收到写命令时,数据库很快也需要将数据写到磁盘中,内存中的数据必须传输到内核中,也就是第三步。 原因:如果做了第二步,但是第三步调用失败,或者没有调用,调用超时响应,这都会导致内存数据与磁盘数据不一致的问题,对于金融业,高精度行业是不可容忍的误差。

关于第三步与操作系统写数据库命令的交互也是一个复杂的工程,涉及到了文件系统缓存(Linus’s Page Cache),小一点的buffer cache负责存储等待把数据提交给磁盘的数据。缓存数据库对于Page Cache和buffer cache而言,OS的缓存层实现是不透明的不可控制的,一般在Cache DB中实现了缓存的话,就会放弃禁用掉Page Cache,防止数据库和内核做同样的事情在同一个时间段(事务并发产生种种可能结果),而Buffer Cache依然会开启,毕竟写磁盘还是一个很耗时,占用IO的一个动作,通过Buffer Cache减少读取IO的时间

事务失败

关于写安全在第几步安全的问题,那就是看不同的场景,写安全也是不同的,比如不考虑OS的,那只要命令过去OS了,就可以认为安全了。
算上OS的情况,除了停电拔线的情况,只有第五步写到媒介上完成后才可以认为写安全了。

问题主要有:

  1. 数据库软件多久将user-space buffers写到内核kernel buffers里面去,通过写的系统底层命令
  2. 内核多久清空提交缓存给disk controller
  3. disk controller 多久将数据写到物理媒介上面去

disk controller 指磁盘用来提高缓存性能的部分。当追求稳定性时会将这一层缓存给屏蔽掉
一般这块缓存是将直写的命令到缓存,便于读取。也可以开启write back模式对写操作缓存,但是必须设备要支持断电自动切换紧急电源应对拔线的操作。

Posix API

step3:数据库调用底层命令写数据到磁盘中,通过操作系统的写操作将数据传输给内核缓存中,当IO阻塞无法写入,且kernel buffer达到最大上限时,kernel会阻塞我们的写操作,当disk有办法接受更多数据时,写系统调用才能最终调用

step4:操作系统将写缓存传输给磁盘控制器,对于linux系统默认为提交写操作每30s。如果有故障的话,将会导致最近30秒的操作有丢失的潜在风险

POSIX API提供了一系列api命令进行调用内核操作去写kernel buffer到disk里面去。数据库系统通过fsync强迫kernel提交数据到disk去,但这同样是有消耗的,fsync会阻塞同时间段需要写的操作,如果在阻塞仍不足以满足高并发的话,在linux系统上可能会需要阻塞其他现场以便完成写操作。

而对于step5:disk controller提交给disk,这部分操作就难以控制了,本身POSIX API就是难以控制的,对于硬件层的交互就不做过多讨论,基本上所有数据库应用都有这方面的难题,也有一些专门的软件会直接操作硬件层,但操作硬件层依旧会涉及到user-space cache,kernel buffer,disk controller,disk,写时的速度以及IO等情况

redis持久化

AOF

append only file持久化,redis每次写命令时,都会将命令记录到日志文件中,在恢复宕机的时候通过日志文件进行恢复数据

  • 好处
    • 数据安全,能保证宕机恢复,可以配置每一次写命令都记录到aof文件中
  • 缺点
    • 比rdb文件大,加载恢复的时间也会比rdb慢

RDB

默认机制,redis database,按照一定时间将内存数据以快照形式进行存储到磁盘中,产生的数据文件为dump.rdb。通过配置文件中的save参数定义快照的周期

  • 好处
    • 只有一个文件,方便持久化,写入磁盘更安全
    • 在持久化时,可以通过fork子进程做持久化写操作,不影响主进程进行处理命令
    • 通过整个文件快速读取恢复启动,比aof速度快一点
  • 缺点
    • 宕机恢复时,存在备份后增量数据的丢失
redis持久化的秘密
/archives/484bfb3/
作者
tyrantqiao
发布于
2021-02-12
更新于
2023-07-09
许可协议
CC BY-NC-SA 4.0
赏

蟹蟹大佬的打赏,大家一起进步

支付宝
微信
  • 数据库
  • Redis

扫一扫,分享到微信

微信分享二维码
段子和笑话
2020年度总结以及2021第一季度目标
© 2026 tyrantqiao 本站总访问量次 本站访客数人次 载入天数...载入时分秒...
  • 文章检索
  • 作品与友邻
  • 关于我

展开标签

  • 随笔
  • 旅行
  • Java
  • 面经
  • 源码
  • 计算机网络
  • 技术
  • 架构
  • Hadoop
  • IDEA
  • maven
  • JDK
  • Linux
  • MySQL
  • 性能
  • 数据库
  • Redis
  • MQ
  • Spring
  • SquirrelFin
  • 记账
  • Android
  • 个人财务
  • unity
  • TIDB
  • chatgpt
  • 前端
  • Vue
  • Git
  • Hexo
  • shadowsocks
  • 问题排查
  • 业务
  • JVM
  • 算法
  • nginx
  • ssh
  • Python
  • 爬虫
  • test
  • vim
  • 影视剧
  • 中间件
  • 事务
  • 表达
  • 运动
  • mybatis
  • AI
  • 产品
  • 家装
  • 土巴兔
  • 域名
  • github
  • 软件
  • 个人项目
  • Leaves
  • Chrome
  • 浏览器插件
  • 开源
  • Balance Voice
  • 穿搭
  • 幽默
  • 画画
  • 缓存
  • 摄影
  • c
  • 课程设计
  • 调酒
  • 设计模式
  • 数学

Collection

作品与友邻

我做的小工具、朋友的站点和一些长期值得回访的灵感来源。

  • 土 土巴兔 AI 导购交互演示 可点击体验用户导购、平台运营、装修公司、材料商及 AI 话术知识库的多端增长流程。 /demos/tubatu-ai-guide/
  • L Leaves 行程记录 我做的行程记录页面小工具,用来沉淀旅行路线、日程安排和途中的灵感。 https://leaves.tyrantqiao.com/
  • 本 本网站主题yilia设计者的主页 http://litten.me/
tyrantqiao的头像

tyrantqiao

github rss qq mail facebook linkedin

About

关于我

代码、海浪和持续折腾,都是生活的一部分。

<div class="aboutme-card"> <p class="aboutme-eyebrow">tyrantqiao</p> <h3>Java 全栈开发</h3> <p>常年和 Java、后端服务、前端工程、数据与部署打交道,喜欢把复杂问题拆开、写清楚,也把踩坑过程整理成文章留给后来的人。</p> <div class="aboutme-tags"> <span>Java</span> <span>Full Stack</span> <span>Backend</span> <span>Frontend</span> <span>Extreme Sports</span> </div> <p>工作之外偏爱冲浪等极限运动,享受在浪上找平衡,也享受在代码里找边界。</p> <div class="aboutme-contact"> <a href="mailto:[email protected]">Gmail</a> <a href="mailto:[email protected]">QQ Mail</a> </div> </div>