redis的持久化的取舍和选择（5）

持久化的作用

　　什么是持久化？

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

　　主流数据库的持久化实现方式

　　　　1.快照  数据备份  MYSQL的Dump    Redis的RDB

　　　　2.写日志　　对数据的更新写在日志中  MYSQL的Binlog    Hbase Hlog  和Redis 的AOF

RDB

　　什么是RDB？

　　　　redis创建二进制文件到硬盘中，在重新启动时，从硬盘中获取

　　

 

 

 

　　触发机制的主要三种方式？

　　　　　　

 

 

 　　　　客户端发送一个save命令，redis就会创建一个RDB的二进制文件,有一个问题，save是同步的，可能会造成阻塞

　　　　　　

 

 

 

 

 

 bgsave

　　客户端发送一个bgsave命令到redis，redis使用了linux一个fork（）函数生成了一个主进程的一个子进程，

让子进程完成了一个RDB文件的生成，当我们的文件生成后，子进程会告诉主进程文件创建成功，就客户端来说只是执行了一个bgsave命令

　　　

 

 

 

 

 

　　

 

 

 

 自动生成RDB文件，60s发生10000次改变或者300s发生10次改变或者900s发生一次改变满足任意一个条件就会自动生成RDB文件，实际上是内部执行了bgsave，无法控制，

 

 

 

   save  900 1

   save 300 1

  save 60  10000 

　　以上的save在配置文件中，是可以改变的

　dbfilename  dump .rdb　　RDB文件叫什么名字

　dir  ./　　　　rdb文件  aof文件，日志文件存储在当前目录下

　stop-writes-on-bgsave-error   yes   如果你的bgsave发生错误，是否停止写入  默认yes

　rdbcompression yes   rdb文件是否采用压缩的格式 默认压缩

　rdbchecksum  yes     是否对rdb文件进行校验 默认yes

  最佳配置：

　　1.将save的配置关闭，不使用自动配置

　　2.dbfilename dump-${port}.rdb    rdb名使用dump-port.rdb的形式进行区分

　　3.dir /bigdiskpath    很大硬盘目录

　　4.stop-writes-on-bgsave-error   yes

　　5.rdbcompression yes

　　6.rdbchecksum  yes  

触发机制：没有执行save或者bgsave，生成了rdb文件

　

 

 

 习惯上在redis的安装目录下，新建一个data文件夹，新建一个config文件夹，

 

 

 将redis.conf  复制到 config目录下，并以redis-port.conf命名

 

修改配置文件，是否以守护进程的方式启动--yes

 

 修改pidfile的名字

 修改logfile名字

 

 注释掉

 

 修改rdb生成名字

 

 修改数据目录位置在redis安装目录下的data文件夹

 

 以配置文件方式启动

 

 演示save阻塞

redis中有5000000条数据，已经使用了904.38M，此时执行save命令

 

 另外一个窗口，获取hello，此时发现get hello 是阻塞的，因为他在save后执行的，阻塞了6.43s

 

 在data目录下查看日志已经rdb文件

 

 使用bgsave执行以上操作，bgsave不会阻塞，他会生成一条子进程，异步操作

修改配置文件，60s 改变5次

使用shutdown进行关闭，会生成rdb文件，一般不使用rdb的自动配置

 

 

AOF

RDB的现存问题

1.耗时耗性能

　　rdb文件的生成过程就是将redis中的数据dump到磁盘中，形成rdb文件，将所有文件都dump到硬盘中，耗时，写也会消耗cpu，bgsave会执行fork（）出新进程，消耗内存，还有I/O性能消耗

 

 

 

2.不可控，丢失数据

　　　　T3-T4之间的数据会丢失

　　

 

 

什么是AOF

会把所有的写入命令，放到AOF文件中

　　

 

 使用AOF文件对redis进行完整恢复，重启之后，将AOF载入到redis当中，进行数据恢复

 

 

AOF的三种策略

　　

 always：reids将写命令写到硬盘的缓冲区，然后按照一定的策略，刷新到磁盘中，为了提高写入效率，always是指每条命令都写入到磁盘中

 

 

 

 everysec：每秒都把缓冲区的数据写到硬盘，出现故障，会丢失一秒的数据，是redis的默认配置

 

 

 no是根据操作系统决定什么时候将缓冲刷新到硬盘

 

 

 三种策略比较：通常选择第二种

　　　　

 

 

 

 

AOF重写

 将数据全部写入AOF文件，AOF文件会越来越大，恢复也会越来越慢，不利于硬盘管理，

写入以下三条命令，只有最后一条命令最用，过期文件无效被删除，化解为很小的AOF文件

 

 

 AOF重写的作用

　　　　1.减少硬盘占用量　　　　2.加速恢复速度

AOF实现重写的俩种方式：

　　1.bgrewriteaof  类似于bgsave，fork出新的子进程完成AOF重写，是从redis内存中重写

　　　　

 

 

 

　　2.AOF重写配置  提供俩个配置完成重写

　　　　1.AOF多大进行重写，非常小是否有必要重写

　　　　2.AOF文件增长率，增长到多大重写

　　　　

 

 

 

 

 

 1.当前尺寸大于最小尺寸

2.增长率  当前尺寸-上一次重写的尺寸/上次重写的尺寸  > 配置的增长率

 

 

 AOF重写流程

 

 

 配置：

appendonly:使用AOF所有功能要把appendonly置为yes

appendfilename：aof文件

appendfsync：aof同步的三种方式

dir  rdb，aof，日志的存放位置

no-appendfsync-on-rewrite  yes  在aof重写，是否正常做aof 的append操作，这里是不做，因为他消耗性能有冲突 ，但是会丢失数据

 

 

 

 

实验：

AOF配置

 

 

 在将AOF文件从缓冲区刷新到硬盘，宕机，AOF在缓冲区中只刷入了一半，不完整，造成错误

 

 

 这也可以？？厉害

 

 

RDB和AOF的抉择

RDB和AOF的比较

同时使用RDB和AOF文件，redis挂掉之后，首先加载的是AOF文件，数据级别高，数据新

体积：因为RDB使用了二进制的形式，且数据采用了压缩，所以体积更小，恢复速度快

数据安全性：RDB使用快照的方式，会丢失数据；AOF是根据策略决定的

轻重：操作RDB将全部数据写入内存，bgsave是子进程消耗内存AOF是追加操作

　　　　

 

 

RDB最佳策略

把RDB关掉，带引号，redis主从复制

对数据备份有用

主从复制，从节点开

 

 

AOF最佳策略

开缓存和存储，只会丢一秒的数据，大部分使用redis做缓存，如果数据丢失在从数据源获取

AOF集中管理，发生大量fork（），分配给redis百分之60

建议使用eveysec策略，每秒刷新

 

 

最佳策略

 开发运维常见问题

1.fork操作

　　是同步操作，执行bgsave和bgwriteaof，它是做一个内存页的拷贝，如果执行慢卡住会阻塞redis的主线程

　　

 

 

 

 

2.进程外开销

 

 

 

 

 

 

 

 

3.AOF追加阻塞

 

 

 

 硬盘查看