Redis学习-第三节

Redis学习-第三节 Redis持久化 *** 作 RDB和AOF同时开启时，默认使用AOF RDB（Redis Database） 1.简介

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

2.执行过程

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

3.配置文件（SNAPSHOTTING部分）

• stop-writes-on-bgsave-error yes：当Redis无法写入磁盘时，关闭Redis写 *** 作，推荐yes
• rdbcompression yes：对于存储到磁盘的快照，可以设置是否进行压缩，为true，Redis会采用LZF算法进行压缩。推荐true
• rdbchecksum yes：存储快照后，可以让Redis采用CRC64算法进行数据校验，但是会增大10%左右性能消耗，推荐true
• save 60 10000：在60秒内，有10000key发生改变，进行RDB *** 作，save用于配置触发RDB的条件（使用的是bgsave指令）

4.save VS bgsave

• save：save只管保存，不管其他，全部阻塞。手动保存。不建议
• bgsave：Redis在后台异步进行快照 *** 作，快照同时还可以响应客户端请求
• lastsave：可以获取最后一次执行快照时间

5.RDB优点

• RDB是一个二进制压缩文件，存储效率高
• RDB存储的是某个时间节点的数据，非常适合数据备份，全量复制等场景
• RDB恢复数据比AOF快

6.RDB缺点

• 无法做到实时持久化，可能会丢失数据
• bgsave *** 作每次执行fork *** 作创建子进程，要牺牲部分性能
• Redis各版本的RDB文件格式不统一，数据可能无法兼容

AOF（Append only File） 1.简介

• 以日志形式记录Redis的所有写 *** 作（增量保存），只追加文件，不改写文件。
• Redis启动之初会读取该文件重新构建数据，就是将文件中的所有写指令从前到后重新执行一遍，已完成数据恢复工作。

2.执行过程

（1）客户端的请求写命令会被append追加到AOF缓冲区
（2）AOF缓冲区会根据AOF持久化策略【always，everysec，no】将 *** 作sync同步到磁盘的AOF文件中
（3）AOF文件大小超过超过重写策略或手动重写时，会对AOF文件rewrite（重写），压缩AOF文件容量。
（4）Redis服务重启时，会load加载AOF文件中的写 *** 作，达到数据恢复的目的。

3.配置文件

• appendonly no：开启AOF
• appendfilename “appendonly.aof”：自定义AOF文件名称
• appendfsync always：始终同步，每次Redis写 *** 作都会立刻记入日志，性能较差但数据完整性好。
• appendfsync everysec：每秒同步，每秒记录一次日志
• appendfsync no：Redis不主动记录，将记录时机交给 *** 作系统
• no-appendfsync-on-rewrite no：不写入AOF文件，只写进AOF缓存，用户请求不会阻塞，但是肯能会丢失数据（降低数据安全性，提高性能）
• no-appendfsync-on-rewrite yes：会写入AOF文件，但遇到重写 *** 作可能会发生阻塞（数据安全，性能降低）

4.Rewrite压缩

• AOF文件采用文件追加的方式，文件会越来越大，为避免此种情况，新增了重写机制，当AOF文件大小超过设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
• AOF过大时，会fork一条子进程重写文件，就是先写文件，在rename
• Redis4.0以后的重写，就是将RDB的快照，以二进制形式附加在新的AOF文件头部，作为已有的历史数据。
• auto-aof-rewrite-percentage 100； auto-aof-rewrite-min-size 64mb：当AOF文件大小达到上次重写文件2倍时，且文件大小大于64M时触发重写。
• 重写流程：
  （1）bgrewriteaof触发重写，判断是否存在bgsave和bgrewriteaof在运行，如果有，等待结束后再执行。
  （2）主进程fork子进程执行重写 *** 作，保证主线程不会被阻塞。
  （3）子进程遍历Redis内存中数据到临时文件，客户端写请求同时写入aof_buf缓冲区aof_rewrite_buf重写缓冲区保证原AOF文件完整性和新AOF文件生成期间新的数据不会丢失。
  （4）子进程写完新的AOF文件，通知主进程，父进程更新统计信息；主进程将aof_rewrite_buf中的数据写入新的AOF文件
  （5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写

5.AOF优点

• 基于日志形式记录写 *** 作，适用于灾难性的误删除紧急恢复
• 丢失数据概率低

6.AOF缺点

• 比RDB占用更多的磁盘空间
• 恢复数据慢
• 存在性能压力

Redis主从复制 1.主从复制作用

• 读写分离，性能扩展
• 容灾快速恢复

2.一主两从 配置过程

（1）建立新的文件夹redisconf，将redis配置文件redis.conf放到文件夹下
（2）建立三个节点配置文件文件，分别命名为redis6379.conf（主）、redis6380.conf（从）、redis6381conf（从）。
（3）分别在配置文件添加如下内容(不同端口，只需将如下内容中的端口信息修改即可)：

include /redisconf/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

（4）使用redis-server redis6379.conf、redis-server redis6380.conf、redis-server redis6381.conf命令启动服务
（5）在6380、6381两个节点上执行slaveof 主节点ip 主节点端口（如slaveof 127.0.0.1 6379）
（6）使用连接redis，使用info replication命令查看当前节点信息
主节点：

从节点：

特点

• 主节点挂掉：从节点等待主节点重新启动
• 从节点挂掉：需要重新执行slaveof，并且从节点会从主节点重新获取所有数据

3.主从复制原理

（1）Slave启动成功连接到Master后会发送一个sync命令。
（2）Master接到命令后，会将主服务器数据进行持久化到rdb文件中，并将文件发送给Slave（全量复制）
（3）Slave接收到数据文件后，会读取rdb文件加载数据。
（4）主服务器每次进行写 *** 作之后，和从服务器进行数据同步（增量复制）
（5）重新连接一次Master，就会进行一次全量复制

4.薪火相传

（1）上一个Slave可以是下一个Slave的Master，但是本质上它还是从节点，并不是主节点
（2）可以有效的减小Master的写压力，去中心化，降低风险。
（3）风险：一旦某个Slave挂掉，在它之后的所有从节点都不能进行数据同步

5.反客为主（哨兵模式）

在薪火相传的基础之上，当主节点挂掉之后，可手动执行slave no one命令使从节点晋升为主节点，也可设置为自动，也就是哨兵模式

配置过程（在上述一主二从的配置基础之上，进行配置）

（1）在redisconf文件夹下，建立sentinel.conf文件
（2）sentinel.conf文件内容：

sentinel monitor mymaster 127.0.0.1 6379 1

（3）启动哨兵：redis-sentinel /redisconf/sentinel.conf

特点

（1）当Master挂掉之后，哨兵会在Slave中选举一个作为新的Master，选举条件为：

• 优先级靠前的：redis.conf文件中的slave-priority配置项，值越小，优先级越高
• 偏移量最大的：获取原Master数据最全的Slave
• runid最小的：每个redis实例启动之后都会生成一个40位的runid
  （2）并将挂掉的Master作为新Master的Slave

Redis集群

redis扩容，并发写 *** 作分摊

1.配置文件

（1）关闭AOF

appendonly no

（2）开启集群配置

• cluster-enabled yes：打开集群模式
• cluster-config-file nodes-6379.conf：设置节点配置文件名称
• cluster-node-timeout 15000：设置节点失联时间，超过该时间，集群自动进行主从切换
  （3）本地模拟建立六个节点，端口分别为6379，6380，6381，6389，6390，6391，按照上述修改配置文件，分别启动实例
  （4）redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6389 127.0.0.1:6390 127.0.0.1:6391使用该命令建立集群

2.插槽

• 一个Redis集群包含16384个插槽，数据库中每个key都属于这些插槽中的一个
• 集群中主节点会分别负责部分插槽，如三主三从的集群：
  主节点A：0-5460
  主节点B：5461-10922
  主节点C：10923-16383
• 主要使通过CRC16（key）算法计算key所属插槽，再根据插槽找到归属节点，然后存放数据

3.故障恢复

• 如果主节点挂掉，从节点自动晋升为主节点，有原主节点启动后，会称为新主节点的从节点
• 如果负责某段插槽的主从节点全部关掉，则需要看配置文件中cluster-require-full-coverage配置项：
  为yes：整个集群挂掉
  为no：则这段插槽数据全部不可用，也无法存储

4.Jedis *** 作集群

package com.zj.util;

import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;

import java.util.HashSet;


public class JedisClusterDemo {
    public static void main(String[] args) {
        HashSet set = new HashSet();
        set.add(new HostAndPort("127.0.0.1", 6379));
        JedisCluster jedisCluster = new JedisCluster(set);
        String set1 = jedisCluster.set("b1", "b100");
        System.out.println(set1);
        System.out.println(jedisCluster.get("b1"));
    }
}