• Home
  • Archives
  • 随笔
所有文章 友链 关于我

  • Home
  • Archives
  • 随笔

redis持久化的秘密

发布于: 2021-02-12
更新于: 2023-07-09

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
  • db

扫一扫,分享到微信

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

tag:

  • 复盘
  • 我
  • 规划
  • java
  • 面试
  • 源码
  • 架构
  • Hadoop
  • HTTP
  • TCP
  • 学习笔记
  • IDEA
  • maven
  • idea
  • Java
  • jdk
  • 面经
  • linux
  • 爱情
  • mysql
  • 性能
  • sql
  • Mysql
  • JAVA
  • 技术
  • Redis
  • MQ
  • Spring
  • 数据库
  • TIDB
  • spring
  • unity
  • chatgpt
  • 经验分享
  • 前端
  • redis
  • vue
  • git
  • shadowsocks
  • hexo
  • blog
  • bug
  • 开发
  • 业务
  • jvm
  • 算法
  • MySQL
  • nginx
  • Linux
  • mq
  • db
  • springCloud
  • ssh
  • python
  • 爬虫
  • test
  • vim
  • 影视剧
  • 中间件
  • 事务
  • 性格
  • 音乐
  • 程序员
  • 随笔
  • mybatis
  • 演讲
  • 域名
  • 猫咪
  • 她
  • github
  • 计划
  • 旅游
  • 软件
  • 心理
  • 情商
  • 幽默
  • 才艺
  • 穿搭
  • 编程
  • 排序
  • 查找
  • 缓存
  • 网络
  • 设计模式
  • c
  • 课程设计
  • centos
  • 数学
  • 本网站主题yilia设计者的主页
如果有问题或者想讨论的可以联系[email protected]或者[email protected]