Redis（4）- Redis持久化与主从

---

前言

主要包括Redis持久化机制，Redis主从搭建配置，Redis同步说明，多种拓扑方式说明

---

一、Redis持久化

1、RDB方式

1.手动触发

save：阻塞当前Redis，一直到Redis持久化完成，如果内存实例太大，造成长时间阻塞，线上不建议使用
bgsave：redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;

2.RDB文件操作

#设置RDB文件保存路径：config set dir /usr/local/redis
dir ./  #默认
#备份
bgsave
#恢复
将dump文件放在redis.conf文件同层级目录下，重启redis即可
优点：
	1、压缩后的二进制文，保存的dump文件是全量数据，适用于灾难备份
	2、全量恢复速度快，加载RDB恢复数据比AOP快
缺点：
	1、每次fork进行备份耗费资源，且全量数据不适于频繁备份
	2、保存后的二进制文件，存在老版本不兼容新版本rdb问题

2、AOF方式

	针对RDB不适用于实时持久化，Redis提供AOF持久化

#设置AOF持久化开启  redis.conf配置
appendonly yes #默认为 no 不开启
#aof持久化默认文件名
appendfilename "appendonly.aof"
#开启aof持久化 ， set aaa 111 
#aof文件数据
*2
$6
SELECT
$1
0
*3
$3
set
$3
aaa
$3
111

1.AOF持久化流程

1，所有的写入命令(set hset)会append追加到aof_buf缓冲区中
2，AOF缓冲区向硬盘做sync同步
3，随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩
4，当redis服务重启，可load加载AOF文件进行恢复

2.AOF配置

appendonly yes           #启用aof持久化方式
# appendfsync always 每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec   #每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐
# appendfsync no       #完全依赖os，性能最好,持久化没保证（操作系统自身的同步）
no-appendfsync-on-rewrite  yes  #正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100  #aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb   #aof文件,至少超过64M时,重写

3.AOF恢复

1. 设置appendonly yes；
2. 将appendonly.aof放到dir参数指定的目录；
3. 启动Redis，Redis会自动加载appendonly.aof文件。

4.redis数据恢复RDB与AOF加载流程

二.Redis主从

1 Redis主从配置

 port 6380 #指定端口
 slaveof <masterip> <masterport>
 slaveof 192.168.42.120 6379  #作为6379的从节点
 masterauth <master-password>
 masterauth 123456  #主节点密码
 slave-read-only yes #设置从节点只读不写(默认)
#从节点写，报错
192.168.42.120:6380> set aaa 111
(error) READONLY You can't write against a read only slave.

启动从节点，主从开始同步

1300:S 29 Jan 00:01:31.036 * DB loaded from disk: 0.109 seconds
1300:S 29 Jan 00:01:31.036 * Ready to accept connections
1300:S 29 Jan 00:01:31.036 * Connecting to MASTER 192.168.42.120:6379
1300:S 29 Jan 00:01:31.036 * MASTER <-> SLAVE sync started
1300:S 29 Jan 00:01:31.036 * Non blocking connect for SYNC fired the event.
1300:S 29 Jan 00:01:31.037 * Master replied to PING, replication can continue...
1300:S 29 Jan 00:01:31.037 * Partial resynchronization not possible (no cached master)
1300:S 29 Jan 00:01:31.038 * Full resync from master: 532154de49377a752fa98fb45af774e790ceacaf:0
1300:S 29 Jan 00:01:31.187 * MASTER <-> SLAVE sync: receiving 175 bytes from master
1300:S 29 Jan 00:01:31.187 * MASTER <-> SLAVE sync: Flushing old data
1300:S 29 Jan 00:01:31.255 * MASTER <-> SLAVE sync: Loading DB in memory
1300:S 29 Jan 00:01:31.256 * MASTER <-> SLAVE sync: Finished with success

2 主从复制

a方式一

新增redis6380.conf配置
在6380增加 slaveof <masterip> <masterport> 
masterauth 12345678

b方式二

# ./redis-server -- slaveof <masterip> <masterport>  作为redis ip port的从节点启动
[root@localhost redis]# ./redis-server redis6380.conf  --slaveof 192.168.42.119 6379 --masterauth 12345678

c,查看状态：info replication

192.168.42.119:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.42.119,port=6381,state=online,offset=474,lag=1
master_replid:57dbefe090d04d94d2d426059de6ec49a070a887
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:474
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:474
192.168.42.119:6379> 

d,断开主从复制：在slave节点，执行6380:>slaveof no one

192.168.42.119:6381> 
192.168.42.119:6381> slaveof no one
1387:M 12 Feb 14:23:40.777 # Setting secondary replication ID to 57dbefe090d04d94d2d426059de6ec49a070a887, valid up to offset: 559. New replication ID is 46508dcbd14f9d4ee2923bd51cffca3f5a7415e4
1387:M 12 Feb 14:23:40.777 # Connection with master lost.
1387:M 12 Feb 14:23:40.777 * Caching the disconnected master state.
1387:M 12 Feb 14:23:40.777 * Discarding previously cached master state.
1387:M 12 Feb 14:23:40.777 * MASTER MODE enabled (user request from 'id=3 addr=192.168.42.119:49650 fd=9 name= age=135 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')
OK
192.168.42.119:6381> 1375:M 12 Feb 14:23:40.777 # Connection with slave 192.168.42.119:6381 lost.

e,断开后再变成主从复制：6381:> slaveof 192.168.42.119 6379

192.168.42.119:6381> get aaa
"123"
192.168.42.119:6381> get aaa
"133"

f,数据较重要的节点，主从复制时使用密码验证： requirepass

masterauth 12345678

e,从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致    

repl-disable-tcp-nodelay no # 是否关闭延迟 默认关闭
传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭
参数关闭时：
     无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，
参数启用时：
     主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

主从复制原理

执行slaveof masterip port后，
与主节点连接，同步主节点的数据,6381:>info replication：查看主从及同步信息

（配置完slaveof 192.168.42.119 6379）slave 6381启动

redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制

• 全量复制：
  一般用于初次复制场景（第一次建立SLAVE后全量）
• 部分复制：
  网络出现问题，从节点再次连主时，主节点补发缺少的数据，每次数据增加同步
• 心跳：
  主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

三、Redis主从拓扑

1、一主一从

2、一主多从

3、树状主从