Redis中RDB和AOF使用细节

Redis RDB

概念：

• 指在规定时间间隔内将内存中的数据集快照写入磁盘，也就是行话里讲的sanpshot快照，它恢复时将快照文件直接读入到内存中
• Redis会单独的创建（fork）可以理解为复制）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何io操作，这就确保了极高的性能，如果需要进行大规模的数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加高效。RDB缺点时最后一次持久化后数据可能丢失。

Fork：

• Fork作用是复制一个与当前进程一样的进程。新进程的所有数据数值都和原进程一样，但这是一个全新的进程，并作为原进程的子进程。
• Rdb保存的是dump.rdb文件。

SANPSHOTTING快照

• save ：save秒种写操作次数

  • 一分钟内更改1万次
  • 5分钟之内更改了10次
  • 15分钟内更改了1次

• 如何触发RDB快照

  • 配置文件种默认的快照配置，冷拷贝后重新使用

  • 命令save或者是bgsave，save时只保存其他不管，全部阻塞。bgsave：redis在后台异步进行快照操作，快照同时还可以响应客户端的请求。可以通过lastsave命令获取最后一次成功执行快照的时间。

    执行flushall命令，会产生dump.rdb文件，但里面是空的，没什么意义。

• 如何恢复数据

  • 将备分文件dump.rdb文件移动刀片rendis的安装目录并启动服务即可
  • CONFIG GET dir 获取目录

• 优势：适合大规模数据恢复，且对数据完整性和一致性比较低

• 劣势：在一定间隔时间做一次备分，如果redis意外down掉的话，就会丢失最后一次快照后的所有修改，fork的时候内存的数据被克隆了一份，大致两倍的膨胀性需要考虑

• 如何停止：save “ ”

• 禁用RDB持久化策略

  • 如果想禁用RDB持久化策略只要不设置任何save指令，或者给save传入一个空字符串参数也可以

AOF

概念：

• 以日志的形式记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录）只许追加文件但不可以更改文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将指令从前到后执行一次以完成数据的恢复工作

• AOF保存的是appendonly.aof文件

• 配置位置：在APPEND ONLY MODE 下appendonly no 改为yes就打开持久化，默认是no

• AOF启动/修复/恢复：

  • 正常恢复：设置yes，修改默认的appendonly no，改为yes

  • 将有数据的aof文件复制一份保存到对应目录（config get dir）

  • 恢复：重启redis然后重新加载

• 异常恢复：

  • 启动：修改默认的appendonly no 为yes
  • 备分被写坏的AOF文件
  • 修复：Redis-check-aof–fix进行修复
  • 恢复：重启redis然后重新加载

• Rewrite ：AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件超过所设定的阈值，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

• 重写原理：AOF文件持续增长而过大时，会fork出一条新进程来讲文件重写（先写临时文件最后在rename）遍历新进程内存中的数据，每条数据记录中有一条set语句。重写aof文件的操作，并没有读取旧得aof文件，而是将整个内存中得数据库内容用命令得方式重写了一个aof文件，这点和快照有点相似

• 触发机制：redis会记录上次重写得aof得大小，默认配置时当aof文件大小时上吃rewrite大小得一倍且文件大于64m时触发

• 优点：每修改同步：appendfsync 同步持久化 每次发生数据变更被立即记录到磁盘，性能较差但数据完整性较好。每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失。不同步：appendfsync no 永不同步

• 缺点：相同数据集得数据而言aof文件要远大于rdb文件，恢复速率慢于rdb。aof运行效率要慢于rdb，每秒同步策略较好，不同步效率和rdb相同。

  总结

  • RDB持久化方式能够维持在指定时间间隔能对你的数据进行快照存储

  • AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到末尾。redis还能对AOF文件进行后台重写，使得AOF文件体积不至于过大

  • 只做缓存：如果你只希望你的数据在服务器运行的时候存在，可以不开启任何持久化方式

  • 同时开启RDB和AOF：在这种情况下当redis重启的时候优先加载AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据要比RDB文件保存的数据集要完整。RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？建议不要，因为RDB更适合备分数据库（AOF在不断变换不好备分）快速重启，而且不会有AOF可能潜在的Bug，留着做一个万一的手段。

Redis的事务

概念

• 可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会被序列化，按顺序地串行化执行而不会被其他命令插入，不许加塞。
• 作用：一个队列中，一次性，顺序性，排他性的执行一系列命令

事务的几种情况

• 常用命令：DISCARD：取消事务放弃事务块儿内所有命令

  • EXEC：执行事务块内所有命令
  • MULTI：标记事务块的开始
  • UNWATCH：取消WATCH命令对所有KEY的监视
  • WATCH key[ key1，key2…]:表示监视一个或者多个key，如果在事务执行之前key被其他命令改动那么事务将被打断。

• 正常执行：exec 操作正常执行

• 放弃事务：discard放弃事务，之前所做的操作全部失效

• 全体连坐：遇到错误指令所有操作全部放弃

• 冤头寨主：对的执行错的放弃

• 事务的3个阶段：开启：以multi开始一个事务，入队：将多个命令入队到事务中，接受这些命令不会立即执行，而是放到等待执行的事务队列里面。执行：有exec命令触发事务

• WATCH监控：

  • 乐观锁：乐观的认为他每次去拿数据的时候别人不会去修改，所以不会上锁，但是在更新的时候会判断在此期间有没有人去更新这个数据。可以使用版本号等机制。乐观锁适用于多读的应用类型这样可以提高吞吐量。版本号机制：在表中加版本号，如果当前版本号为1，第一次修改后会更新为2，如果当前取到的数据版本号为1，更新的时候就会报错，需要拿到版本号为最新的数据做出修改在提交。
  • 悲观锁：顾名思义就很悲观，它认为每次去拿数据的时候认为别人会去修改，所以每次去拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库就用到了很多这种锁机制，比如行锁，表锁等，都是在操作之前先上锁

  Redis发布订阅

  概念：进程之间的一种消息通信模式：发送者（PUB）发送消息，订阅者（SUB）接收消息。

  • 命令：PSUBSCRIBE patterm：订阅一个或多个符合给定模式的频道
  • PUBSUB subcommand：查看订阅发布系统状态
  • PUBLISH channel message：将信息发送到指定的频道
  • PUNSUSCRIBE[pattern]:退订所有给定模式的频道
  • SUBSCRIBE channel[channel]：订阅给定的一个或多个频道的信息
  • UNSUBSCRIBE[channel【channeel…】]:指退订给定的频道

Redis主从复制

概念：

• 主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，master以写为主，slave以读为主

作用：读写分离，容灾恢复

• 配置方法：1.配从(库)不配主(库)

• 从库配置：slaveof 主库IP 主库端口 细节：每次从库与主库断开连接后都需要重新连接，可以将配置到redis.conf配置文件中。查看状态命令：Info replication

• 修改配置文件：1.拷贝多个redis.conf文件。2.开启守护线程daemonize 为yes。3.更改Pid文件名字

  4.指定端口，如果主机端口为6379从机则不能和主机配置端口冲突。4.更改log文件名字。5.更改Dump.rdb名字

• 配置策略：一主两仆，一个master两个slave。分别查看端口对应的日志。info replication可以查看当前机器对应状态。是否为主机和备机。

  • 薪火相传：上一个slave可以是下一个slave的master，slave同样可以接受其他slaves的连接和同步请求，那么改slave作为链条中下一个master，可以有效减轻master的写压力
  • 中途变更转向：会清楚之前的数据，重新建立拷贝最新的
  • slaveof新主库ip新主库端口哦
  • 反客为主：slaverof no one 使当前数据库停止与其他数据库的同步，转成主数据库。