redis主从复制、哨兵和集群

redis主从复制、哨兵和集群

  一、redis持久化

    1.1持久化的功能

     Redis是内存数据库，数据都是存储在内存中，为了避免服务器断电等原因导致Redis进程异常退出后数据的永久丢失，需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;

当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。

    1.2redis持久化方式

      RDB持久化（Redis DataBase） :原理是将Reids在内存中的数据库记录定时保存到磁盘上。

      AOF持久化(append only file) :原理是将Reids的操作日志以追加的方式写入文件，类似于MySQL的binlog。

  二、RDB持久化

    2.1触发条件

      RDB 持久化触发条件分为手动触发和自动触发两种

      手动触发

      save命令和bgsave命令都可以生成RDB文件。

      save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。

      而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程 (即Redis主进程) 则继续处理请求。

      bgsave命令执行过程中，只有fork 子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用。往往生产环境 bgsave       依然不允许轻易使用

      自动触发

      在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化。

vim /etc/redis/6379.conf
--219行--以下三个save条件满足任意一个时，都会引起bgsave的调用
save 900 1 :当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 :当时间到300秒时， 如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 :当时间到60秒时，如果redis数据发生了至少10000次变化， 则执行bgsave
--242行--是否开启RDB文件压缩
rdbcompression yes
--254行--指定RDB文件名
dbfilename dump.rdb
--264行--指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379

  三、AOF持久化

      RDB持久化是将进程数据写入文件，而AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录; 当Redis重启时优先执行AOF文件中的命令来恢

复数据。 与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

Redis服务器默认开启RDB，关闭AOF: 要开启AOF，需要在配置文件中配置:

vim /etc/ redis/ 6379. conf
- 700行--修改， 开启AOF
appendonly yes
--704行--指定A0F文件名称
appendfilename "appendonly.aof"
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes

/etc/init.d/redis_6379 restart
ls /var/lib/redis/6379/

    3.1RDB和AOF的优缺点

    RDB持久化 优点：RDB文件紧凑，体积小，网络传输快，适合全量复制;恢复速度比AOF快很多。当然，与AOF相比， RDB最重要的优点之一是对性能的影响相对较小。

    缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。此

外，RDB文件需要满足特定格式，兼容性差(如老版本的Redis不兼容新版本的RDB文件)。 对于RDB持久化，一方面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据

也会带来IO压力。

    AOF持久化 与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。 对于AOF持久化，向硬盘写数据的频率大大提高(everysec策略

下为秒级)，IO压力更大，甚至可能造成AOF追加阻塞问题。 AOF文件的重写与RDB的bgsave类似，会有fork时的阻塞和子进程的I0压力问题。相对来说，由于AOF向硬盘中写数据的频率更高，因此

对Redis主进程性能的影响会更大。

  四、redis主从复制

    4.1主从复制作用

      数据冗余:主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

      故障恢复:当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复;实际上是一种服务的冗余。

      负载均衡:在主从复制的基础.上，配合读写分离，可以让主节点提供写服务，由从节点提供读服务〈即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点)，分担服务器负载;

尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

      高可用基石:除了上述作用以外，主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。

    4.2主从复制流程

      若启动一个Slave机器，则它会向Master机器发送一个"sync command"命令，请求同步连接。从发给主无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快

照保存到数据文件中（执行rdb操作），同时Master还会记录修改数据的所有命令并缓存在数据文件中。

      后台进程完成缓存操作之后，Master机器就会向Slave机器发送数据文件存储，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若slave出现故障导致宕机，则恢复

正常后会自动重新连接。

      Master机器收到Slave端机器的连接后，将其完整的数据文件发送给slave端机器，如果Master同时收到多个slave发来的同步请求，则Master会在后台启动一个进程以保存数据文件，然

后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。

    4.3搭建redis主从复制

      4.3.1实验括朴

      4.3.2实验准备

      master：192.168.224.100

      slave1：192.168.224.101

      slave2：192.168.224.102

      redis安装包版本：redis-5.0.7

      4.3.3安装redis

systemctl stop firewalld
#关闭防火墙
setenfroce 0
yum install gcc gcc-c++ make -y
#安装编译工具
cd /opt
tar xf redis-5.0.7.tar.gz
#解压安装包
cd redis-5.0.7/
make && make prefix=/usr/local/redis install
cd utils/
./install_server.sh
.....一直回车
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server
#把配置文件改为/usr/local/redis/bin/redis-server

master节点

vim /etc/redis/6379.conf

bind 0.0.0.0
#第70行修改监听地址为0.0.0.0
daemonize yes
#第137行开启守护进程
logfile /var/log/redis_6379.log
#第172行指定日志文件
dir /var/lib/redis/6379
#第264行指定工作目录
appendonly yes
#第700行开启AOF持久化功能

/etc/init.d/redis_6379 restart
#重启服务

slave节点
vim /etc/redis/6379.conf

bind 0.0.0.0
#第70行修改监听地址为0.0.0.0
daemonize yes
#第137行开启守护进程
logfile /var/log/redis_6379.log
#第172行指定日志文件
dir /var/lib/redis/6379
#第264行指定工作目录
replicaof 192.168.224.100 6379
#第288行添加masterIP地址和端口号
appendonly yes
#第700行开启AOF持久化功能

/etc/init.d/redis_6379 restart
#重启服务

      4.3.4验证实验效果

tail -f /var/log/redis_6379.log
#查看redis日志文件
Replica 192.168.224.101:6379 asks for synchronization
Replica 192.168.224.102:6379 asks for synchronization

  五、redis哨兵模式

    5.1哨兵模式原理

      哨兵(sentinel):是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的Master并将所有Slave连接到新的 Master。所以整个运行哨

兵的集群的数量不得少于3个节点。

    5.2哨兵模式作用

      监控:哨兵会不断地检查主节点和从节点是否运作正常。

      自动故障转移:当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

      通知提醒：哨兵可以将故障转移的结果发送给客户端。

    5.3搭建哨兵模式

      5.3.1实验括朴

       5.3.2实验准备

      master：192.168.224.100

      slave1：192.168.224.101

      slave2：192.168.224.102

      redis安装包版本：redis-5.0.7

       5.3.3搭建哨兵

systemctl stop firewalld
#关闭防火墙
setenfroce 0
vim /opt/redis-5.0.7/sentinel.conf
#切换到哨兵配置文件中

protected-mode no								
#第17行关闭保护模式
port 26379										
#第21行Redis哨兵默认的监听端口
daemonize yes									
#第26行指定sentinel为后台启动
logfile "/var/log/sentinel.log"					
#第36行指定日志存放路径
dir "/var/lib/redis/6379"						
#第65行指定数据库存放路径
sentinel monitor mymaster 192.168.224.100 6379 2	
#第84行修改指定该哨兵节点监控192.168.224.100:6379这个主节点。
sentinel down-after-milliseconds mymaster 30000
#第113行判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000
#第146行故障节点的最大超时时间为180000（180秒）

      5.3.4启动哨兵模式

先启动master节点，再启东slave节点
cd /opt/redis-5.0.7/
#切换到redis目录下
redis-sentinel sentinel.conf &
#启动哨兵模式

      5.3.5验证实验效果

将master节点服务器挂起，到slave1输入命令查看
redis-cli -p 26379 info Sentinel
#查看主节点服务器，已经切换到192.168.224.102为master节点

  六、集群模式

    6.1集群工作原理

     在哨兵sentinel机制中，可以解决redis高可用问题，即当master故障后可以自动将slave提升为master，从而可以保证redis服务的正常使用，但是无法解决redis单机写入的瓶颈问

题，即单机redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素。

      Redis Cluster特点如下：

      所有Redis节点使用(PING机制)互联，集群中某个节点的是否失效，是由整个集群中超过半数的节点监测都失效，才能算真正的失效客户端不需要proxy即可直接连接redis，应用

程序中需要配置有全部的redis服务器IPredis cluster把所有的redis node 平均映射到 0-16383个槽位(slot)上，读写需要到指定的redisnode上进行操作，因此有多少个redisnode相当于

redis 并发扩展了多少倍，每个redis node 承担16384/N个槽位Redis cluster预先分配16384个(slot)槽位，当需要在redis集群中写入一个key -value的时候，会使用CRC16(key)取余16384

之后的值，决定将key写入哪一个槽位从而决定写入哪一个Redis节点上，从而有效解决单机瓶颈。

    6.2搭建集群

      6.2.1括朴图

cd /etc/redis/
mkdir -p redis-cluster/redis600{1..6}
for i in {1..6}; do cp /opt/redis-5.0.7/redis.conf  /etc/redis/redis-cluster/redis600$i; cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/red
redhat-release  redis/          
for i in {1..6}; do cp /opt/redis-5.0.7/redis.conf  /etc/redis/redis-cluster/redis600$i; cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
> done
cd redis-cluster/
ls
redis6001  redis6002  redis6003  redis6004  redis6005  redis6006
cd redis6006
ls
redis-cli  redis.conf  redis-server

      6.2.2修改配置文件

cd /etc/redis/redis-cluster/redis6001
vim redis.conf
#69行，注释掉，默认监听所有网卡
#bind 192.168.224.100
#88行，修改，关闭保护模式
protected-mode no
#92行，修改，redis监听端口
port 6001
#136行，以独立进程启动
daemonize yes
#699行，修改，开启AOF持久化
appendonly yes
#832行，取消注释，开启群集功能
cluster-enabled yes
#840行，取消注释，修改，群集名称文件设置
cluster-config-file nodes-6001.conf
#846行，取消注释，群集超时时间设置
cluster-node-timeout 15000
cd /etc/redis/redis-cluster/redis6001
vim redis.conf 
vim redis.conf 
cp redis.conf /etc/redis/redis-cluster/redis6002
cp redis.conf /etc/redis/redis-cluster/redis6003
cp redis.conf /etc/redis/redis-cluster/redis6004
cp redis.conf /etc/redis/redis-cluster/redis6005
cp redis.conf /etc/redis/redis-cluster/redis6006

cd /etc/redis/redis-cluster/redis6002
vim redis.conf

#92行，修改，redis监听端口
port 6002
#840行，取消注释，修改，群集名称文件设置
cluster-config-file nodes-6002.conf

      6.2.3启动redis节点

[root@node2 redis6006]# for d in {1..6}
> do
> cd /etc/redis/redis-cluster/redis600$d
> redis-server redis.conf 
> done
ps -ef |  grep redis

      6.2.4启动集群

redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
#六个实例分为三组，每组一主一从，前面的做主节点，后面的做从节点。下面交互的时候 需要输入 yes 才可以创建。

      6.2.5测试群集

redis-cli  -p 6001 -c   
#加-c参数，节点之间就可以互相跳转	
cluster slots			
#查看节点的哈希槽编号范围
set name xyk
cluster keyslot xyk	
#查看name键的槽编号

   七、总结

  主从复制：主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。
  缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

  哨兵：在主从复制的基础上，哨兵实现了自动化的故障恢复。
  缺陷：写操作无法负载均衡；存储能力受到单机的限制；哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要对从节点做额外的监控、切换操作。

  集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。