redis03
持久化
redis将所有数据保持在内存中，对数据的更新将异步地保存在磁盘中
快照
MySQL Dump ，Redis RDB
日志
MySQL Binlog Hbase HLog Redis AOF
RDB的触发方式
save同步
在save的同时，其他命令会阻塞等待
如果存在老的RDB文件，会先创建一个临时文件，然后对老文件进行替换
时间复杂度，O(n)
bgsave异步
调用bgsave后，会调用linux的fork()函数，创建一个子进程
如果存在老的RDB文件，会先创建一个临时文件，然后对老文件进行替换
时间复杂度，O(n)
子进程名称：redis-rdb-bgsave
save与bgsave的比较
通过配置自动进行RDB操作
内部相当于bgsave
save 900 1
save 300 10
save 60 10000
1 配置项 默认值 含义 2 dbfilename dump.rdb RDB快照文件名 3 dir ./ RDB快照文件生成所在目录 4 stop-writes-on-bgsave-error yes bgsave时发生错误是否停止写入 5 rdbcompression yes RDB文件是否采用压缩 6 rdbchecksum yes 是否对RDB进行校验
其他触发机制
主从复制时机的全量复制，master节点会执行bgsave
debug reload
shutdown
flushDB 、 flushAll
RDB缺点
耗时
耗性能
不可控，容易丢失数据
AOF
通过日志方式将redis中的写命令进行日志记录，保存在硬盘文件中
日志记录的实质是将写命令写在硬盘的缓冲区中，再根据相关策略把数据刷新到磁盘中
当redis服务器启动时候，执行硬盘中的日志文件以恢复redis中的数据
AOF的三种策略
always
执行每条写命令都会将写命令写到磁盘中
不丢失数据，IO开销大
everysec
每秒将数据从缓冲区刷到磁盘中，可能会丢失一秒的数据
no
写命令何时刷新的磁盘中，由操作系统来决定
不用管，不可控
AOF的重写
减少磁盘占用
加速AOF恢复速度
例如一万次incr key 可以重写为 set key 10000
bgrewriteaof
客户端发送出一条bgrewriteaof命令后，redis会fork一个子进程完成AOF重写操作逻辑
配置 默认值 含义
auto-aof-rewrite-min-size 64MB AOF文件重写需要的尺寸，AOF多大时开启重写
auto-aof-rewrite-percentage 100 AOF文件增长率(当前AOF文件大小超过上一次重写的 AOF、文件大小的百分之多少才会重写)
统计名 含义
aof_current_size AOF当前尺寸（单位：字节）
aof_base_size AOF上次启动和重写的尺寸（单位：字节）
原理
AOF重写不会读取老的AOF文件，而是根据当前服务器的状态生成一份新的AOF文件，将老的AOF文件进行替换
1 配置项 取值 含义 2 appendonly yes 开启AOF 3 appendfilename aof-${port}.aof AOF文件名 4 appendfsync everysec AOF策略 5 dir /redisDataPath AOF文件所在目录 6 no-appendfsync-no-rewrite yes 在执行重写时不进行AOF操作 7 auto-aof-rewrite-percentage 100 AOF文件增长率 8 auto-aof-rewrite-min-size 64MB AOF文件重写需要的尺寸
RDB与AOF的比较
策略
RDB
关闭RDB自动执行配置
手动管理时进行RDB操作
在从节点打开自动执行配置，但是不宜频繁执行RDB
AOF
建议打开，但是如果只是纯作为缓存使用可以不开
AOF重写集中管理
everysec
最佳策略
小分片
例如设置maxmemory参数设置每个redis只存储4个G的空间，这样各种操作都不会太慢
需要进行监控（硬盘、内存、负载、网络）
机器需要有足够的内存
fork操作
fork操作是一个同步操作，若执行较慢会阻塞redis主线程
执行时间与内存量相关：内存越大，耗时越长；虚拟机较慢，真机较快
查看fork执行时间，可做监控
info : latest_fork_usec 上一次执行fork的微秒数
改善fotk
优先使用物理机或者高效支持fork操作的虚拟化技术
控制Redis实际最大可用内存
合理配置Linux内存分配策略 vm.overcommit_memory = 1
默认这个值为0，在内存比较低的时候，会发生fork阻塞
降低fork频率：例如放宽AOF重写自动触发时机，不必要的全量复制
子进程开销
CPU开销： RDB和AOF都会生成文件，属于CPU密集型
优化1：不做CPU绑定，不和CPU密集型的应用部署在同一台服务器上
优化2：避免在单机多部署的场景大量发生AOF重写
内存开销：fork内存开销，copy-on-write，子进程会共享父进程的物理内存页，当父进程执行写请求的时候会创建一个副本，此时会消耗内存。即父进程在大量写入的时候，子进程开销会比较大，创建副本。
优化1：防止单机多部署的时候发生大量的重写
优化2：echo never > /sys/kernel/mm/transparent_hugepage/enabled
Linux内核的2.6.38版本中增加以上配置，支持大的内存页的分配
内存页分配越大，会提高创建副本页的大小，影响性能
硬盘开销：RDB与AOF文件写入的场景，可以集合iostat、iotop进行分析
优化1：不要和高硬盘负载服务部署在一起，例如存储服务、消息队列
配置：no-appendfsync-on-rewrite = yes
根据写入量决定磁盘类型：SSD
单机多实例持久化目录可以考虑分盘以及做资源限制，例如cgroup
AOF追加阻塞
Redis在执行fsync的时候，redis为了保证AOF文件安全性，会校验上次fsync的时间是否大于2秒。若超过2秒，会发生阻塞。
可以通过Redis日志进行定位：Asynchronous AOF fsync is taking too long (disk is busy?)
可以通过info persistence命令进行查看：每发生一次，aof_delayed_fsync 会增1
优化方法可以参考硬盘优化策略
完
