Redis学习笔记（2）

8.Redis的持久化

两种策略的选择：

• RDB持久化方式能够在指定的时间间隔内对数据进行快照存储。AOF持久化方式记录每次对服务器的写操作，当服务器重启时会重新执行这些写命令来恢复原始的数据，AOF命令以redis协议追加保存每次写操作到文件末尾。

• Redis能对AOF文件进行后台重写，使得AOF文件体积不会过大

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

• 官网建议如果使用，两种同时使用：

  在这种情况下，redis先载入AOF文件来恢复原始数据，因为通常AOF数据比RDB数据更完整。当RDB数据不正确时，服务器重启也只会加载AOF文件。RDB用于备份数据库，快速重启，以防万一。

• 性能建议
  

1. RDB（Redis DataBase）

   • 定义：在指定的时间间隔内将内存中的数据集快照写入磁盘，Snapshot快照，它恢复时是将快照文件直接读到内存里。

   • Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

   • Fork

     作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

   • RDB保存的是dump.rdb文件，保存和恢复的文件都可以在配置文件中修改。

   • 配置位置

     在redis.config文件中找到snapshotting

     

     注释已经说的很明确了，虽然是用英文…

     按我的理解，快照就是备份，什么时候备份呢？按配置文件默认的来说，就是900秒内至少有1个key变动；或者300秒内改变10个keys，或者60秒内10000个keys有变动，在这三种情况下，符合任意一种，就会产生备份。

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

     在客户端输入save命令，立刻备份。

   • 如何触发RDB快照

     • 配置文件中默认的快照配置：冷拷贝后重新使用
     • 命令save或者是bgsave
       • save时只管保存，其他不管，全部阻塞
       • bgsave：Redis会在后台异步进行快照操作，快照同时还可以相应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间
     • 执行flushall，也会产生dump.rdb文件，但里面是空的，无意义

   • 如何恢复

     将备份文件（dump.rdb）移动到redis安装目录并启动服务即可

     Config get dir获取目录

   • 优势

     • 适合大规模的数据恢复
     • 对数据完整性和一致性要求不高

   • 劣势

     • 在一定间隔时间做一次备份，所以如果redis意外宕机的话，就会丢失最后一次快照后的所有修改
     • Fork的时候，内存中的数据被复制了一份，需要较大的内存空间。像归并排序的时候有个临时数组。

   • 如何停止

     动态所有停止RDB保存规则的方法：redis-cli config set save “”

   • 总结

     • RDB是一个非常紧凑的文件
     • RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能
     • 与AOF相比，在恢复大的数据集的时候，RDB方式更快
     • 数据丢失风险大
     • RDB需要经常fork子进程来保存数据集到硬盘上，非常耗时，可能不会及时响应客户请求

2. AOF（Append Only File）

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

   • AOF保存的是appendonly.aof文件

   • 配置位置

   • AOF启动、修复、恢复

     • 正常恢复
       • 启动：设置Yes，修改默认的appendonly no，改为yes
       • 将有数据的aof文件复制一份保存到对应目录（config get dir）
       • 恢复重启redis然后重新加载
     • 异常恢复
       • 启动：设置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 always 同步持久化 每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性好。
     • 每修改同步（默认）：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，则有数据丢失
     • 不同步：appendfsync no 从不同步

   • 劣势

     • 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
     • Aof运行效率要慢于rdb，每秒同步策略效率较高，不同步效率和rdb相同

   • 总结

     • Aof文件是一个只进行追加的日志文件
     • Redis可以在AOF文件过大时，自动的在后台对AOF文件进行重写
     • AOF文件有序的保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常易读，对文件解析轻松
     • 对于相同的数据集来说，AOF文件体积通常大于RDB文件体积
     • 根据所使用的fsync策略，AOF的速度可能会慢于RDB

9.Redis的事务

定义：跟关系型数据库的事务差不多，跟操作系统的原语也差不多，具有串行性，顺序性，排他性，但是不具有原子性（比如下面的“冤头债主”）。

三个阶段：开启（MULTI）->入队->执行（EXEC）

三个特性：单独的隔离操作，没有隔离级别的概念，不保证原子性（部分支持）

• 常用命令
  

• 正常执行
  

• 放弃事务

  

• 全体连坐

  事务中间出现错误，那么整个事务中的语句都不执行

• 冤头债主

  跟上面的区别就是，上面是语句出错，比如语法错误，加入队列的时候就出错，那么一条都不执行；加入队列，执行的时候出错，其他语句正常执行。

  

• watch监控

  • 悲观锁（安全，并发度差），乐观锁，CAS

    
    
    CAS前几天学java多线程的学过。

  • 一旦执行EXEC，之前加的监控所都被取消掉了。

  • watch命令，类似于乐观锁，事务提交时，如果监控的key被改变，整个事务队列都不会被执行。

  • 通过watch命令在事务执行之前监控了多个keys，倘若在watch之后有任何key的值发生变化，EXEC命令执行的事务都被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

10.Redis的发布订阅（了解）

• 定义：进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接受消息

• 命令
  

11.Redis的复制（Master/Slave）

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

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

• 用法：

  1. 配从（库）不配主（库）
  2. 从库配置：slaveof主库IP主库端口
     • 每次与master断开之后，都需要重新连接，除非在redis.conf文件进行配置
     • Info replication
  3. 修改配置文件细节操作
  4. 常用3招
     • 一主二仆
     • 薪火相传
     • 反客为主

  ps：周阳老师这口诀6啊。

• 复制原理

• 哨兵模式（sentinel）

• 复制的缺点

12.Redis的Java客户端Jedis

之前API都用过了，导入相关JAR包，需要时再翻文档吧.