运维开发网

Redis持久化的取舍和选择

运维开发网 https://www.qedev.com 2020-06-11 15:04 出处:网络 作者:运维开发网整理
七.Redis持久化的取舍和选择 1.持久化的作用 2.什么是持久化:redis所有数据保持在内存中,对数据的更新将异步地保存到磁盘上 3.持久化的实现方式 方式一:快照 实现方式一:mysql dump 实现方式二:redis RDB 方式二:写日志 实现方式一:mysql binlog 实现方式二:hbase hlog 实现方式三:redis AOF 4.RDB (1)什么是RDB (2)触发

七.Redis持久化的取舍和选择

1.持久化的作用

2.什么是持久化:redis所有数据保持在内存中,对数据的更新将异步地保存到磁盘上

3.持久化的实现方式

方式一:快照

实现方式一:mysql dump

实现方式二:redis RDB

方式二:写日志

实现方式一:mysql binlog

实现方式二:hbase hlog

实现方式三:redis AOF

4.RDB

(1)什么是RDB

Redis持久化的取舍和选择

(2)触发机制-主要三种方式

第一种:save(同步)

Redis持久化的取舍和选择

 

文件策略--->如存在老的RDB文件,新替换老

复杂度--->O(N)

IO类型同步,阻塞,复杂度O(n),优点不会消耗额外内存,缺点,阻塞客户端命令

命令:

127.0.0.1:6379> save OK

第二种:bgsave(异步)

Redis持久化的取舍和选择

文件策略--->如存在老的RDB文件,新替换老

复杂度--->O(N)

IO类型异步,阻塞发生在fork(子进程),复杂度O(n),优点不阻塞客户端命令,缺点,需要fork(子进程),消耗内存

命令:

127.0.0.1:6379> bgsave Background saving started

第三种:自动生成RDB

(3)配置:

#如果在9000秒中改变了1条数据自动生成RDB
save 900 1
#如果在300秒中改变了10条数据自动生成RDB
save 300 10
#如果在60秒中改变了10000条数据自动生成RDB
save 60 10000
#rdb文件名字
dbfilename dump.rdb
#rdb文件的路径(默认当前目录)
dir ./
#是否停止写入默认是yes
stop-writes-on-bgsave-error yes
#是否采用压缩格式
rdbcompression yes
#是否对rdb文件检验
rdbchecksum yes

(4)触发机制-不容忽略方式

1)全量复制

2)debug reload:不将内存清空的重启,触发rdb文件生成

3)shutdown:

(5)RDB总结

1)RDB是Redis内存到硬盘的快照,用于持久化

2)save通常会阻塞Redis

3)bgsave不会阻塞Redis,但是会fork新进程

4)save自动配置满足任一就会被执行

5)有些触发机制不容忽视

5.AOF

(1)RDB现存问题

耗时,耗性能

不可控,丢失数据

(2)什么是AOF

客户端每执行一条写命令,redis就在AOF文件里追加一条写命令,当redis宕机后,从AOF文件中把命令从新写入到redis

(3)AOF三种策略

策略一:always

redis写命令刷新到缓冲区,缓冲区根据always策略每条命令刷新到AOF文件

优点:不会丢失数据

缺点:IO开销较大,一般的sata盘只有几百TPS

策略二:everysec

redis写命令刷新到缓冲区,缓冲区根据everysec策略每一秒都刷新到AOF文件

优点:每秒一次fsync丢1秒数据

缺点:丢1秒数据

策略三:no

redis写命令刷新到缓冲区,缓冲区根据操作系统来决定什么时候刷到AOF文件

优点:不用管

缺点:不可控

(4)AOF重写:把过期的,没有用,重复,以及可以优化的命令化简,减少磁盘占用量,加速恢复速度

AOF重写的两种方式

方式一:bgrewriteaof

命令:bgrewriteaof

Background append only file rewriting started

方式二:AOF重写配置

(5)配置:

#打开AOF功能默认为no
appendonly yes
#AOF文件名
appendfilename "AOF文件名"
#AOF目录
dir /bigdiskpath
#AOF重写的时候是否做AOF的append操作
no-appendfsync-on-rewrite yes
#AOF文件重写需要的尺寸
auto-aof-rewrite-min-size
#AOF文件增长率
auto-aof-rewrite-percentage
RDB和AOF的抉择

(6)统计:

#AOF当前尺寸(单位:字节)
aof_current_size
#AOF上次重启和重写的尺寸(单位:字节)
aof_base_size

(7)AOF重写流程图

1.bgrewriteaof对父进程执行之后

2.父进程会fork一个子进程

4.子进程完成AOF重写的过程(将redis内存数据进行一次回溯成写到新的AOF文件中),

3.1主进程正常进行客户端写命令写到aof_buf当中去写到AOF文件当中

3.2过程redis会将这段时间的写命令写到aof_rewrite_buf文件

5.2当新文件生成之后,会将新文件补充道新AOF文件

5.3用新的AOF文件替换旧的AOF文件

Redis持久化的取舍和选择

6.Redis持久化的取舍和选择

(1)RDB和AOF的抉择

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

(2)RDB最佳策略

集中管理

主从,从开

(3)AOF最佳策略

开缓存和存储

AOF重写集中管理

everysec每秒去刷

(4)最佳策略

小分片

缓存或者存储

监控(硬盘,内存,负载,网络)

7.开发运维常见问题

(1)fork操作

<1>同步操作

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

<3>info:latest_fork_usec 查看fork执行时间

(2)改善fork

<1>优化使用物理机或高效支持fork操作的虚拟化技术

<2>控制Redis实例最大可用内存:maxmemory

<3>合理配置liunx内存分配策略:vm.overcommit_memory=1

<4>降低fork频率:列如放宽AOF重写自动触发时机,不必要的全量复制

(3)进程外开销

<1>CPU:

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

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

<2>内存:

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

优化:echo never > /sys/kernel/mm/transparent_hugepage/enabled

<3>硬盘

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

硬盘优化:

不要和高硬盘服务部署一起:存储服务,消息队列等

no-appendfsync-on-rewrite = yes

根据写入量决定磁盘类型:列如ssd

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

(4)AOF追加阻塞

主线程负责写入AOF缓冲区,同时它还有一个同步线程进行每秒刷盘动作,同时还记录最近一次同步时间,主线程负责对比上一次同步时间,如果距离上次同步时间大于两秒阻塞,小于两秒通过

Redis持久化的取舍和选择

(5)AOF阻塞定位<1>redis日志<2>单机多实例部署

扫码领视频副本.gif

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号