标签
SQL Server
Redis
MySQL
其它
Oracle
外部链接
redis持久化

什么是持久化

redis所有数据保存在内存中,对数据的更新将异步的保存到硬盘上

持久化方式

快照-RDB,将某个时间段的数据全部备份下来保存在rdb文件中

写日志-AOF,每次执行命令都会写入到日志中aof文件中

RDB方式

1、save命令(同步)

客户端发送save命令就会创建RDB文件,因为是同步命令,如果save命令慢即数据量大时会照成redis的阻塞,新的文件会替换老的文件。

2、bgsave命令(异步)

客户端发送bgsave时redis会执行一个fork()来启动一个子进程,由子进程去完成这个RDB文件的生成,生成成功后会通知主进程文件已经生成成功了

3、自动执行的配置

save配置(例如在60秒中改变了10000条文件就执行生成RDB文件,这个可以多个配置)

配置文件中 #save 900 1

                  #save 300  10

                  #save 60  10000

缺点就是数据写入量大时容易造成频繁写磁盘的操作。

配置文件中 dbfilename  dump.rdb rdb文件的名称

                  dir  ./文件保存的目录

                  stop-writes-on-bgsave-error yes  bgsave执行错误时是否停止写入

                  rdbcompression yes RDB文件是否采用压缩的格式

                  rdbchecksum yes 是否对RDB文件进行一个检验

RDB最佳配置

一般要关闭自动执行的方式,如果一台机子上部署多个redis需要改写rdb文件的名称,通常使用redis的端口来命名例如:dump-{port}.rdb

RDB触发机制

1、全量复制

2、debug reload机制

3、shutdown

RDB存在的问题:不可控,会丢失文件,因为RDB是在某个时间点去执行创建的,如果在这个执行完的时间多后面再写入命令且好又出现宕机的情况的话,那么这部分写入的数据就会丢失。RDB同时也是比较耗时耗性能的,要一次将所有数据全部写入到硬盘中。

AOF方式

运行原理:客户端写入一个命令都会记录到日志中,就是追加到aof文件中,写入aof之前它会先将命令写入一个缓存区域,然后根据策略执行一个fsync命令,写入到aof中即磁盘当中。

AOF的三种策略

1、always

每写一条命令都会立马追加到AOF中

优点:不会丢失数据

缺点:IO开销大,需要频繁的写入磁盘

2、everysec

每一秒会执行写入AOF中的命令,就是将缓存区的命令写入到AOF中,但是是每秒写入(这个每秒是可以配置的)

优点:每秒一次fsync,可以减少磁盘的写入操作

缺点:丢1秒的数据

3、no

这个是根据操作系统来决定什么时候去刷新AOF

优点:不用管

缺点:不可控

AOF重写

重写就是精简命令,减少AOF的体积,就是要把过期的,没有由的,复杂的命令进行一个删除和优化的过程。

AOF重写的好处,一是减少硬盘的占用量,二是加速恢复速度

AOF重写的两种实现方式

1、bgrewriteaof

客户端对redis发送bgrewriteaof命令,redis会fork一个子进程去执行这个aof重写的操作,重写并不是从aof文件中去重新写入,而是从内存中读取再写的过程

2、aof重写的配置

auto-aof-rewrite-min-size   AOF文件重写需要的尺寸,就是AOF达到多大的时候进行一个重写

auto-aof-rewrite-percentage   AOF文件增长率,即使AOF重写过后,下一次增长率达到多少再次重写例如现在是100%如果下次达到了120%就需要重写。

3、aof统计命令

aof_current_size  AOF当前尺寸即大小(单位是字节)

aof_base_size  AOF上次启动和重写的尺寸(单位是字节)

AOF配置文件配置

appendonly yes,AOF使用的最基础配置,要使用AOF需要配置成yes

appendfilename "",AOF文件保存的名称

appendfsync  everysec,AOF同步策略

dir ../,AOF、RDB、日志文件的保存路径

no-appendfsync-on-rewrite yes,AOF重写的时候是否还要append(追加)AOF,意思就是说重写的这段时间是否允许丢失数据。

RDB与AOF

命令RDBAOF
启动优先级低高
体积小大
恢复速度快慢
数据安全性丢数据根据策略决定
轻重重轻

持久化常见问题

fork操作

1、同步操作

2、与内存量息息相关:内存越大,耗时越长(与机器类型有关)

3、info:latest_fork_usec 上一次执行fork时消耗的微秒数

子进程开销和优化

1、CPU

开销:RDB和AOF文件生成,属于CPU密集型

优化:不错CPU绑定,不和CPU密集型部署

2、内存

开销:fork内存开销,copy-on-write

优化:不允许单机多部署时大量AOF重写

3、硬盘

开销:AOF与RDB文件写入,可以结合iostat,iotop分析

优化:a、不要和高硬盘负载服务器部署在一起:存储服务、消息队列等

          b、no-appendfsync-on-write  =  yes :AOF重写时不要去追加AOF的写入

          c、根据写入量决定磁盘类型:例如ssd

          d、单机多实例持久化文件目录可以考虑分盘

AOF阻塞

image.png


image.png


扫一扫手机看
点击排行
订阅号
...