Redis持久化+主从

Redis是内存数据库，如果不将内存中的数据库状态报错到磁盘，那么一但服务器进程退出，服务器中的数据状态也会消失，所以Redis提供了持久化功能

RDB（redis database）

 在指定的时间间隔内将内存中的数据快照写入磁盘（snapshot）,恢复时将快照文件读到内存中。

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

触发机制

* 满足save规则触发

* 执行flushall命令也会触发

* 退出redis触发

备份就会自动在启动目录下生成一个dump.rdb文件，恢复只需要将dump.rdb文件放在redis启动目录下启动即可，redis启动会自动检查并恢复

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin/redis"  #如果在此目录下存在dump.rdb文件，在此目录下启动时会自动恢复其数据

手动触发Redis进行RDB持久化的命令有两种：

　　1、save

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

　　显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。

　　2、bgsave

　　执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

优点：

 1).RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

 2).生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作.

缺点：

1). 每次运行都要执行fork操作创建子进程，会占用一定的内存空间

2).需要一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

AOF(Append Only File)

 

 以日志的形式来记录每个写的操作，将Redis执行过的所有指令记录下了（读操作不做记录），只允许追加文件不可以改写，Redis启动时会读取该文件重新构建数据。简单来说就是Redis重启的的话就根据日志文件的内容将指令重前到后执行一次已完成数据的恢复。默认是不开启的

[root@localhost redis]# sed -n  "1253p"  redis.conf 
appendonly yes

重启即生效

如果AOF文件有错误Redis是启动不起来的，需要修复AOF文件 redis-check-aof （删除错误的那一段数据）

redis-check-aof --fix  appendonly.aof

优点：

1).每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好。

2).每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失。

3).不同步：appendfsync no 从不同步

缺点：

1).相对于数据文件来说，AOF远远大于RDB，修复数据也比RDB慢

2）.效率比RDB慢

主从复制

主从原理

slave启动成功连接到master后会发送一个sync命令，master服务器收到sync命令,执行bgsave命令生成RDB文件，并记录后面执行的所有命令，bgsave执行完后，master发送数据文件到slave，完成同步

全量同步：全量复制一般只发生在slave初始阶段，slave需要将master上的所有数据复制一份。

增量同步: slave全量复制master后，master将所有新搜集到的数据依次传给slave

主（master）和 从（slave）部署在不同的服务器上，当主节点服务器写入数据时会同步到从节点的服务器上，一般主节点负责写入数据，从节点负责读取数据

主从复制的作用：

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余
• 故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的恢复故障
• 负载均衡：当在主从复制的基础上，配合读写分离，由主节点提供写服务，由从节点提供读取服务（即写redis数据时应用连接主节点，读redis数据是应用连接从节点），分担服务器负载，尤其是在写多读少的场景下，通过多个从节点分担读负载，可以大大提高redis服务器的并非量
• 高可用： 主从复制还是哨兵和集群能够实现实施的基础

默认情况下，每一台redis服务器都是主节点，只需要配置从库

使用replication查看当前信息

127.0.0.1:6379> info replication
# Replication
role:master  #角色
connected_slaves:0  #没有slave
master_failover_state:no-failover
master_replid:423217f804ae9af29dafa9b65a427396beedf364
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

配置主从模式

创建redis配置文件

从Redis的配置pid、端口、rdb、aof文件需要更改为主配置不同。

aof默认是关闭的，如果开启就需要修改

[root@localhost redis]# cp redis.conf  redis6380.conf 
[root@localhost redis]# cp redis.conf  redis6381.conf 

#修改配置文件 redis6391.conf也一样修改
[root@localhost redis]# vim redis6380.conf 
port 6380
pidfile /var/run/redis_6380.pid
logfile "redis6380.log"
replicaof 192.168.248.130 6379



#启动服务
[root@localhost redis]# redis-server redis.conf 
[root@localhost redis]# redis-server redis6380.conf 
[root@localhost redis]# redis-server redis6381.con

查看状态

192.168.248.130:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.248.130,port=6380,state=online,offset=56,lag=1
slave1:ip=192.168.248.130,port=6381,state=online,offset=56,lag=1


192.168.248.130:6380> info replication
# Replication
role:slave
master_host:192.168.248.130
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4

192.168.248.130:6381> info replication
# Replication
role:slave
master_host:192.168.248.130
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7

测试主写入数据，是否能在从中看到

192.168.248.130:6379> set name  master
OK

192.168.248.130:6380> keys *
1) "name"
192.168.248.130:6380> get name
"master"

192.168.248.130:6381> keys *
1) "name"
192.168.248.130:6381> get name
"master"

测试先启动主写入数据后，在启动从

[root@localhost redis]# redis-cli -h 192.168.248.130 -p 6379
192.168.248.130:6379>
192.168.248.130:6379> set  key slave
OK
192.168.248.130:6379> keys *
1) "key"
2) "name"

#启动从服务器查看日志 
2105:S 24 Apr 2021 20:21:19.746 * Successful partial resynchronization with master.
2105:S 24 Apr 2021 20:21:19.746 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization