Redis的持久化之RDB和AOF

Redis的持久化的取舍和选择

一 什么是持久化

redis所有数据保持在内存中，对数据的更新将异步地保存在磁盘上

持久化方式 ： 快照 ，写日志

快照： mysql的Dump Redis RDB

写日志： mysql的Binlog ，Hbase的Hlog，Redis的AOF 

二 Rdis持久化之RDB( 快照 Redis DataBase )

什么是RDB

redis（内存）           ———创建                    RDB文件（二进制，硬盘）

redis（内存）重启后———启动载入             RDB文件（二进制，硬盘）

触发机制--主要三种方式：save（同步）  bgsave（异步） 自动

save（同步）

文件策略： 如存在老的RDB文件，新替换老

复杂度： O(N)

IO类型：同步

阻塞？：是

优点：不会消耗额外内存

缺点：阻塞客户端命令

bg（backgroud）bgsave（异步）

文件策略： 如存在老的RDB文件，新替换老

复杂度： O(N)

IO类型：异步

阻塞？：是（阻塞发生在fork）

优点："不阻塞"客户端命令 (一般情况下fork很快，如果fork很慢的时候会阻塞)

缺点：需要fork，消耗内存

自动生成RDB

自动策略：

配置：           seconds                  changes

save                900秒                        1条

save                300秒                       10条

save                60秒                         10000条

基本配置：

save  900  1

save 300  10

save  60   10000

dbfilename dump.rdb        :文件名

dir ./      ：目录路径

stop-writes-on-bgsave-error yes   ： 如果bgsave发生错误 停止写入

rdbcompression yes  ：是否采用校验和的方式

最佳配置： 

dbfilename dump-${port}.rdb    :文件名

dir ./bigdiskpath       ：目录路径

stop-writes-on-bgsave-error yes  ： 如果bgsave发生错误 停止写入

rdbcompression yes           ：是否采用校验和的方式

触发机制--不容忽略方式

1.全量复制         : 主从复制的时候，主会自动生成一个RDB文件

2.debug-reload  ：不需要将内存中清空后重启

3.shutdown        ：shotdown的时候会执行一个RDB文件的生成

RDB总结

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

2.save通常会阻塞Redis

3.bgsize 不会阻塞Redis 但是会fork新进程（会有消耗）

4. save自动配置满足任一就会执行 （通常不会用自动配置）

5.有些触发机制不容忽视（比如主从复制 比如shutdown这些机制不容忽视）

三 Rdis持久化之AOF( 写日志  appendonly file )

RDF有什么问题？

1.耗时耗性能   ：

O(N)  数据：耗时 

fork：消耗内存， copy-on-write策略

Disk I/O：IO性能消耗

2.不可控，丢失数据

什么是AOF？

AOF的三种策略： always  everysec  no

always ：每条命令都会fsync（把文件在内存中的部分写回磁盘）到硬盘中

优点：不丢失数据 

 缺点：IO开销较大，一般的sata盘只有几百TPS（每秒传输的事物处理个数）

everysec ：每秒把缓冲区fsync到磁盘  （权衡之下，一般使用这种方式）

优点：每秒一次fsync  只丢失一秒数据

 缺点：丢失一秒数据

no ： 由操作系统来决定fsync

优点：不用管

 缺点：不可控

QPS/TPS

QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

Tps即每秒处理事务数，包括了

1）用户请求服务器

2）服务器自己的内部处理

3）服务器返回给用户

这三个过程，每秒能够完成N个这三个过程，Tps也就是N；

Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。

例如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q” 

系统吞吐量

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

        QPS（TPS）：每秒钟request/事务 数量

        并发数： 系统同时处理的request/事务数

        响应时间：  一般取平均响应时间

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

QPS（TPS）= 并发数/平均响应时间    或者   并发数 = QPS*平均响应时间

AOF重写

什么是AOF重写：会优化AOF数据，把过期的没有用的，重复的，以及可以优化的命令简化

AOF重写的作用：减少硬盘占用量，简述恢复速度

AOF重写实现的两种方式：bgrewriteaof  AOF重写配置

bgrewriteaof命令：客户端对redis主进程发一条bgrewriteaof命令，redis接收到这个命令之后会fork一个子进程来完成AOF的重写（实际上就是将内存中的数据进行一次回溯，回溯成AOF文件）

AOF重写配置：

aoto-aof-rewrite-in-size: AOF文件重写需要的尺寸（当AOF多大的时候才开始AOF重写）

auto-aof-rewrite-percentage: AOF文件增长率（AOF重写之后下一个达到什么条件在重写呢？）

统计：

aof-current_size : AOF当前尺寸（单位：字节）

aof_base_size ： AOF上次启动和重写的尺寸（单位：字节）

自动触发时机：必须同时满足以下条件才可以触发AOF重写

aof-current_size>aoto-aof-rewrite-in-size

( aof-current_size - aof_base_size ) / aof_base_size > auto-aof-rewrite-percentage

AOF配置：

appendonly yes  ：默认值为 no ，如果要用AOF的所有功能 首先要先该默认值为yes

appendfilename "appendonly-${port}.aof"  ：AOF的文件名 用端口进行区分

appendfsync everysec  ：AOF同步的策略 每秒进行刷盘的策略

dir /bigdiskpath  ：RDB AOF以及日志的目录

no-appendfsync-on-write yes ：在AOF重写的时候，是否要做正常的AOF的append操作 yes是不做这个操作

这个什么意思呢，因为AOF重写是非常消耗性能的，所以不做这个操作

auto-aof-rewrite-percentage  100 : 增长率

auto-aof-rewrite-min-size 64MB  :  最小尺寸

RDB和AOF的抉择

RDB和AOF比较

     命令                  RDB                   AOF

启动优先级               低                      高

体积                          小                      大

恢复速度                   快                      慢

数据安全性            丢数据            根据策略决定

轻重                         重                        轻

RDB最佳策略 ：

 "关"  ， 集中管理 ，主从 从开？

AOF最佳策略 ：

 "开"：缓存和存储 

AOF重写集中管理

everysec:每秒的刷盘

最佳策略：

小分片

缓存或者存储

监控（硬盘 内存 负载 网络）

足够的内存