标签：常见问题 队列 根据 star compress 分片 eve bsp 内存数据
1.持久化的作用
2.什么是持久化：redis所有数据保持在内存中，对数据的更新将异步地保存到磁盘上
3.持久化的实现方式
方式一：快照
实现方式一：mysql dump
实现方式二：redis RDB
方式二：写日志
实现方式一：mysql binlog
实现方式二：hbase hlog
实现方式三：redis AOF
4.RDB
(1)什么是RDB
(2)触发机制-主要三种方式
第一种：save(同步)
文件策略--->如存在老的RDB文件，新替换老
复杂度--->O(N)
IO类型同步，阻塞，复杂度O(n)，优点不会消耗额外内存，缺点，阻塞客户端命令
命令：
127.0.0.1:6379> save
OK
第二种：bgsave(异步)
文件策略--->如存在老的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文件
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缓冲区，同时它还有一个同步线程进行每秒刷盘动作，同时还记录最近一次同步时间，主线程负责对比上一次同步时间，如果距离上次同步时间大于两秒阻塞，小于两秒通过
(5)AOF阻塞定位
<1>redis日志
<2>单机多实例部署
标签：常见问题 队列 根据 star compress 分片 eve bsp 内存数据
原文地址：https://www.cnblogs.com/xixi18/p/11137269.html
