Redis持久化、备份和主从配置
一、持久化方式
Redis提供了两种数据备份的方式，一种是RDB，另外一种是AOF。
| RDB | AOF | |
| 开启/关闭 | 开启：默认开启；关闭：把配置文件中所有的save注释就是关闭了 | 开启：在配置文件中appendonly:yes即是开启了aof；no为关闭 |
| 同步机制 | 可以指定某个时间内发生多少个命令进行同步，比如1分钟内发生2次命令，就做一次同步 | 每秒同步或者每次发生命令后同步 |
| 存储内容 | 存储的是Redis里具体的值 | 存储的是执行的更新操作的命令 |
| 存储文件的路径 | 根据dir以及dbfilenname来指定路径和具体的文件名 | 根据dir以及appendfilename来指定具体的路径和文件名 |
| 优点 |
（1）存储数据文件时会进行压缩，文件体积比aof小； （2）因为存储的是Redis具体的值，并且会经过压缩，因此在恢复的时候速度比aof快； （3）非常适合用备份。 |
（1）aof策略的备份机制是每分钟或者每发生写操作的时候都会同步，因此即使服务器故障，最多只会丢失1秒的数据； （2）aof存储的是Redis命令，并且是直接追加到aof文件后面，因此每次备份的时候只要添加新的数据进去就可以了； （3）如果aof文件比较大了，那么Redis会进行重写，只保留最小的命令集合。 |
| 缺点 |
（1）rdb在多少时间内发生了多少写操作的时候就会触发同步机制，因为采用压缩机制，rdb在同步的时候都重新保存整个Redis中的数据，因此一般会设置5分钟才保存一次数据，在这种情况下，一般服务器故障，会造成至少5分钟的数据丢失； （2）在数据保存进rdb的时候，Redis会fork出一个子进程用来同步，在数据量比较大的时候，可能非常耗时。 |
（1）aof文件因为没有压缩，因此比rdb体积大； （2）aof是在每秒或者每次写操作都进行备份，因此如果并发量比较大，效率可能会有点慢； （3）aof文件因为存储的是命令，因此在灾难恢复的时候Redis会重新运行aof中的命令，因此恢复速度比不上rdb。 |
1、rdb持久化
实现RDB持久化的方式有两种
（1）save，bgsave
save，同步的方式，持久化操作完成前，系统会被阻塞
bgsave，异步方式
（2）依赖提前做好的计划任务来实现
异步：子进程来完成持久化操作，持久化会将快照中的内容写入到一个临时文件中，当持久化完成了，那么就将这个临时文件改名成dump.rdb
rdb持久化参数介绍
save 900 1 #900秒和至少1个键改变才会被保存 save 300 10 #300秒和至少10个键改变才会被保存 save 60 10000 #60秒和至少10000个键改变才会被保存 stop-writes-on-bgsave-error yes #错误发生时停止写入 rdbcompression yes #启用压缩 rdbchecksum yes #检验 dbfilename dump.rdb #rdb文件名 dir /var/lib/redis #rdb文件保存路径
2、AOF持久化
AOF比rdb方式更可靠，如果想要启动aof持久化，只要启动appendonly yes即可。
appendonly yes #是否启用aof持久化 auto-aof-rewrite-percentage 100 #当aof文件的大小增张了指定比例的时候，执行一次重写操作 auto-aof-rewrite-min-size 64mb #指定aof文件做重写最小值 appendfilename "appendonly.aof" #aof持久化信息保存在哪个文件中（相当于mysql的二进制日志文件） # appendfsync always #一旦执行了操作，会立刻将操作的语句记录到aof文件中 appendfsync everysec #每秒向aof文件进行一次写入操作 # appendfsync no #不主动向aof执行写入操作，由系统自行判断何时向磁盘执行写入操作 no-appendfsync-on-rewrite no aof-load-truncated yes
二、Redis主从复制
主节点：可读可写；从节点：只读不写
Redis的主从复制，可以实现一个主节点master可以有多个从节点slave节点，一个slave节点也可以作为下面很多从节点的主节点，类似于mysql的级联复制。
Redis的主从复制策略是通过其持久化的rdb文件来实现的，其过程是先dump出rdb文件，将rdb文件传输给slave，然后再将dump后的操作实时同步到slave中。让从服务器(slave server)成为主服务器(master server)的复制品。
1、拷贝一份Redis配置文件为slave-6380.conf
[root@bi6 redis-5.0.0]# cp redis.conf slave-6380.conf
2、编辑slave-6380.conf文件
[root@bi6 redis-5.0.0]# vim slave-6380.conf 69 bind 192.168.11.6 70 slaveof 192.168.11.6 6379 #指定主节点 93 port 6380
3、编辑主配置文件
[root@bi6 redis-5.0.0]# vim redis.conf bind 192.168.11.6
4、重启主节点
[root@bi6 redis-5.0.0]# redis-server redis.conf [root@bi6 redis-5.0.0]# redis-cli -h 192.168.11.6 -p 6379 192.168.11.6:6379> get name "bi"
5、重启从节点
[root@bi6 ~]# redis-server redis-5.0.0/slave-6380.conf [root@bi6 ~]# redis-cli -h 192.168.11.6 -p 6380 192.168.11.6:6380> get name "bi"
三、多实例（同主从）
多实例就是一台服务器上安装多个redis服务器，这样可以更大程度的利用有限资源，在做一些实验的时候也是强烈建议使用多实例的方式，以节省内存消耗。
多实例的启动需要用到redis-server + 配置文件 的方式启动，而不能再使用systemctl restart redis。
另外多实例的登录需要指定-p ip地址，-p指定端口号。
步骤：
1、创建目录，主要存放每个实例的数据，如配置文件，日志文件，pid文件，rdb文件等
2、复制配置文件到创建的实例目录下
3、修改每个实例的配置文件
必须修改的地方：bind监听的地址、端口号、开启后台启动、pid文件保存位置、日志文件保存位置、rdb文件保存位置
bind 192.168.11.6 protected-mode yes port 6380 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize yes supervised no pidfile /redis/6380/redis_6380.pid loglevel notice logfile /redis/6380/redis.log ...
四、高可用
Redis高可用即哨兵模式，可以实现对主节点及从节点的监控，当节点出现故障的时候可以实现通知的功能，也可以实现故障转移，失败接管，当主节点出现故障的时候，从节点就可以来接替主节点，实现主从节点的切换。这个时候原本是从节点的服务器，就晋升为主节点了。
主节点发生故障，进行了主从的切换之后，如果修复好原来的主节点，再次启用的话，原来的主节点就成为了从节点。
1、在主节点查看
可以使用info replicationc查看主从信息，在主节点进行操作
192.168.11.6:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=192.168.11.6,port=6380,state=online,offset=1497,lag=0 master_replid:0c33819e00bb6132c5fdb11c3e57bd78d3fe2d35 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:1497 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:1497
2、修改监控端的配置文件
[root@bi6 redis-5.0.0]# vim sentinel.conf 17 protected-mode no #关闭保护模式 21 port 26379 #端口号为26379（默认） 67 # sentinel monitor <master-name> <ip> <redis-port> <quorum>
#注：quorum指几个主机同意可以故障切换，这里是1表示，只要一个主机同意故障切换就会切换
84 sentinel monitor mymaster 192.168.11.6 6379 1 #添加主节点信息
3、启动监控节点
[root@bi6 redis-5.0.0]# redis-server sentinel.conf --sentinel
[root@bi6 ~]# ss -tnl State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:26379 *:* LISTEN 0 128 192.168.11.6:6379 *:* LISTEN 0 128 192.168.11.6:6380 *:* LISTEN 0 128 *:22 *:* LISTEN 0 128 :::26379 :::* LISTEN 0 128 :::22 :::*
4、登录监控端、查看主/从服务端信息
[root@bi6 ~]# redis-cli -h 192.168.11.6 -p 26379 #登录监控端
192.168.11.6:26379> sentinel masters #查看主服务端信息
1) 1) "name"
2) "mymaster"
3) "ip"
4) "192.168.11.6"
5) "port"
6) "6379"
7) "runid"
8) "ab924650ae917f3187b511b4ad5e7173ef01a639"
9) "flags"
10) "master"
...
192.168.11.6:26379> sentinel slaves mymaster #查看从服务端信息
1) 1) "name"
2) "192.168.11.6:6380"
3) "ip"
4) "192.168.11.6"
5) "port"
6) "6380"
7) "runid"
8) "01cada6b7d9d540d380f2a3bbdba548566dc6d84"
9) "flags"
10) "slave"
...
5、测试
[root@bi6 ~]# ps aux |grep redis #查看Redis的各个实例的pid root 12149 0.2 1.0 159516 10132 ? Ssl 15:14 0:05 redis-server 192.168.11.6:6379 root 12187 0.2 1.3 163100 13324 ? Ssl 15:15 0:05 redis-server 192.168.11.6:6380 root 12229 0.3 0.8 153884 8308 pts/0 Sl+ 15:48 0:02 redis-server *:26379 [sentinel] root 12256 0.0 0.7 24720 7436 pts/2 S+ 15:51 0:00 redis-cli -h 192.168.11.6 -p 26379 root 12282 0.0 0.0 112728 972 pts/3 R+ 15:58 0:00 grep --color=auto redis [root@bi6 ~]# kill 12149 #关闭Redis主节点进程
192.168.11.6:26379> sentinel masters #再次查看主节点，已经变成了6380端口了
1) 1) "name"
2) "mymaster"
3) "ip"
4) "192.168.11.6"
5) "port"
6) "6380"
7) "runid"
8) "01cada6b7d9d540d380f2a3bbdba548566dc6d84"
9) "flags"
10) "master"
注意：现在再把之前的主节点重启启动的话，之前的主节点会变成现在的主节点的从节点，即之前的主机点故障之后再启动已经变成从节点了。
