4.redis-持久化

1.持久化的做用
2.什么是持久化:redis全部数据保持在内存中,对数据的更新将异步地保存到磁盘上
3.持久化的实现方式
方式一:快照
实现方式一:mysql dump
实现方式二:redis RDB
方式二:写日志
实现方式一:mysql binlog
实现方式二:hbase hlog
实现方式三:redis AOF
4.RDB
(1)什么是RDB
mysql

(2)触发机制-主要三种方式
第一种:save(同步)ios

 


文件策略--->如存在老的RDB文件,新替换老
复杂度--->O(N)
IO类型同步,阻塞,复杂度O(n),优势不会消耗额外内存,缺点,阻塞客户端命令
命令:redis

127.0.0.1:6379> save OK

第二种:bgsave(异步)

文件策略--->如存在老的RDB文件,新替换老
复杂度--->O(N)
IO类型异步,阻塞发生在fork(子进程),复杂度O(n),优势不阻塞客户端命令,缺点,须要fork(子进程),消耗内存
命令:sql

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文件

6.Redis持久化的取舍和选择
(1)RDB和AOF的抉择
app

启动优先级: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缓冲区,同时它还有一个同步线程进行每秒刷盘动做,同时还记录最近一次同步时间,主线程负责对比上一次同步时间,若是距离上次同步时间大于两秒阻塞,小于两秒经过

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

相关文章
相关标签/搜索