13.Redis的持久化，集群

redis 应用场景： 

                                1.热点数据得缓存

                                2.限时任务

                                3.计算器--incr decr

                                4.分布式锁。==setnx

                                5.排行榜---sort set

1、redis的持久化定义

   持久化：把内存中的数据保存到磁盘的过程就是持久化。防止数据丢失

1.1redis持久化的方式

（1）第一种：RDB  快照模式   在一定时间间隔内，对当前redis内存中的数据进行拍照存储

（2）第二种：AOF  日志追加   每次执行的写命令，都会通过一个函数write记录到日志中

1.2RDB快照模式

（1）什么时候会触发EDB模式

三种方式：①save    ② bgsave    ③通过配置文件

默认保存的文件名：dump.rdb

1.save

2.bgsave

bgsave都属于手动触发

(2)save 和bgsave的区别

 save模式

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止

执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。

 bgsave模式

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体流程如下：

具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。 

修改配置文件属于自动触发

3.自动触发

需要指定配置文件---一般不建议改---采用默认值----底层自动执行bgsave命令

改完配置文件后需要重启redis服务 

1.3 rdb数据恢复

只需要把dump.rdb文件放入指定目录，当redis服务启动时，会读取dump.rdb文件，并加载到内存中剪切到根目录下，再剪切回来的方式恢复数据

 

1.4  AOF持久化

它会把每个写命令通过write函数记录到日志文件中，默认该持久化没有开启，需要修改配置文件来开启AOF模式

 不可以删除 appendoblydir 

 1.5 RDB和AOF优缺点

（1）RDB的优点 ：数据恢复速度快

                     缺点：数据完整性差

（2）AOF的优点：数据完整性强 ---->最多丢失最后一条写命令

                     缺点：数据恢复速度慢---->它需要把日志文件中所有命令执行一遍   

         若两个同时开启：默认恢复数据时采用AOF

2、redis的集群

  2.1问什么使用集群

可以减少单机压力，解决单机故障问题 

2.2 第一种集群方式  主从模式

配置主从模式----->配从不配主

模拟：一台Linux系统，启动三台redis服务，依靠端口号：6390主节点 6391和6392从节点

（1）复制三个redis配置文件放入master-slave目录

 

  （2）修改三个配置文件

       ① #设置所有的ip允许连接该redis服务
              bind 0.0.0.0 -::1

       ② # 关闭保护模式
             protected-mode no
             port 6390

       ③ dbfilename dump6390.rdb
           # AOF日志文件的名称
           appendfilename "appendonly6390.aof"

     (3)启动三台redis

 

 

 (4)三台客户端访问redis响应的服务器

redis-cli -p 6390

redis-cli -p 6391

redis-cli -p 6392

 

  (5)查看redis角色

   info replication 

  它们之间暂无主从关系

（6）配置主从关系 ---->只修改从节点

slaveof主节点ip  主节点port

slaveof  127.0.0.1 6390

 

 

 (7)在主节点里添加数据

总结：

①如果主节点挂掉，从节点是否可以代替注解点？    ---->不会

②如果新增一个从节点，该从节点是否可以把之前的数据同步过来?   --->可以

③从节点是否可以进行写操作？    ----->不能，从节点只能读不能写

④主节点是否可以进行读写操作？   ----->可以

2.3第二种集群模式---哨兵模式

上面的主从模式缺点：如果主节点宕机后，从节点无法上位，该redis服务就无法执行写操作了。

 

（1）修改sentinel.conf文件

# sentinel monitor 名称随便起 主节点ip 主节点port  2：获取哨兵的票数
sentinel monitor mymaster 127.0.0.1 6390 1

 

 

 （2）开启哨兵模式

 redis-sentinel sentinel.conf 

（3）演示：主节点挂掉

6390客户端shutdown

 原来的主节点回来后----->它会变成从节点

 2.4第三种集群模式---集群模式

哨兵模式的缺点：它只有一个主节点---如果现在写操作并发高，那么还会导致主节点压力过大。

去中心化

（1）主备6台redis服务器，6个服务中不能有数据
             主节点  7001 7002 7003

             从节点  7004 7005 7006

    修改配置文件

    bind 0.0.0.0 -::1

    port 7001

   daemonize yes

   # 打开aof 持久化

   appendonly yes

  dbfilename dump7001.rdb

  appendfilename "appendonly7001.aof"

  # 开启集群

  cluster-enabled yes

  # 集群的配置文件,该文件自动生成

  cluster-config-file nodes-7001.conf

  #集群的超时时间

  cluster-node-timeout 5000   （5秒）

bind 0.0.0.0 -::1
 
port 7001
 
daemonize yes
 
appendonly yes
 
dbfilename dump7001.rdb
 
appendfilename "appendonly7001.aof"
 
cluster-enabled yes
 
cluster-config-file nodes-7001.conf
 
cluster-node-timeout 5000

(2)创建一个文件夹，放配置文件

  (3)开启如上6台redis服务器

  查看6台redis服务器的进程

 （4）为6台redis配置槽以及主从关系
        redis-cli --cluster create --cluster-replicas 1

           192.168.xxx.xxx:7001

           192.168.xxx.xxx:7002

           192.168.xxx.xxx:7003

           192.168.xxx.xxx:7004

           192.168.xxx.xxx:7005

           192.168.xxx.xxx:7006

           -- --cluster-replicas 1：

从节点的个数  （  xxx.xxx表示本机的ip地址。）

（5） 验证

   语法： redis-cli -c -h 127.0.0.1 -p 7001