redis_主从复制、哨兵模式、群集模式

• 一.Redis群集三种模式
• • 1.redis主从复制
  • • 1）概述
  • 2)redis主从复制作用
  • • 3）Redis主从复制流程
    • 4)redis主从复制的搭建
    • 1.环境配置
    • 2.安装redis(主从机器)
    • 3台主从服务器执行相同操作：
    • 3.修改master节点redis配置文件
    • • 192.168.133.10
    • 4.修改slave节点redis配置文件
    • • 192.168.133.20、192.168.133.30
    • 5.验证主从效果
    • • master节点上看日志
    • master节点上验证从节点
  • 二.redis 哨兵模式
  • • 1.哨兵模式原理
    • 2.哨兵模式主要功能
    • 3.哨兵监控系统过程
    • 4.哨兵模式下故障迁移
    • 5.优先级排序：
    • 6.优缺点
    • 哨兵结构由两部分组成:
    • 7.哨兵模式搭建
    • 1）修改redis配置文件(所有节点操作)
    • 2)启动哨兵模式
    • 3)查看哨兵模式信息
    • 4）模拟故障
    • 5）验证结果
    • 三.redis集群模式
    • 组成：
    • 故障转移
    • 作用：
    • 1.搭建redis集群模式
    • 1)创建并复制相关文件
    • • 2）修改配置文件，开启群集功能
    • 3）启动redis节点
    • 4）启动集群
    • 5）测试集群
    • 总结：
    • • 主从复制：
      • 哨兵模式：
    • 集群模式：
    • 为什么要用 Redis？
    • • 为什么要用缓存?
    • redis为什么这么快

一.Redis群集三种模式

主从复制
 哨兵模式
 群集模式

1.redis主从复制

1）概述

主从复制：将一台redis服务器的数据，
 复制到其他的redis服务器

• 前者称为主节点(Maste),后者称为从节点(slave）
• 数据的复制是单向的，只能由主节点到从节点

默认情况下，每台redis服务器都是主节点

• 一个主节点可用有多个从节点，但一个从节点只能有一个主节点

2)redis主从复制作用

• 数据冗余：主从复制，实现了数据的热备份
• 故障恢复：当主节点出现问题时，可由从节点提供服务，实现快速故障恢复
• 负载均衡：在主从复制的基础上，配合读写分离，主节点提供写服务，从节点提供读服务（redis写数据在主节点，redis读数据在从节点上），分担服务器负载，可通过多个节点分担读负载，可大大提高redis服务器并发量
• 高可用：主从复制是哨兵和集群的基础

3）Redis主从复制流程

• 1.启动一个slave机器进程，它会向master机器发送 sync command命令，请求同步连接
• 2.无论第一次连接还是重新连接，master机器都会启动一个后台进程，执行RDB操作，将快照数据保存到数据文件中，同时master会记录修改数据所有命令，并缓存在数据文件中
• 3 后台进程完成缓存操作，master会向slave发送数据文件，slave将数据文件保存到硬盘上，加载到内存中，接着master会将修改数据所有操作 发送给slave,若slave出现故障导致宕机，则恢复正常后，自动重新连接
• 4 master收到slave端机器连接后，将完整数据文件发送给slave端机器，如果master收到多个同步请求，master在后台启动一个进程保存数据文件，然后发给slvae段机器，保证slave正常

4)redis主从复制的搭建

1.环境配置

2.安装redis(主从机器)

systemctl stop firewalld
setenforce 0
yum install -y gcc gcc-c++ make
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
cd /opt/redis-5.0.7/utils
./install_server.sh
回车四次，下一步需要手动输入
Please select the redis executable path [] /usr/local/redis/bin/redis-server      
ln -s /usr/local/redis/bin/* /usr/local/bin/
netstat -natp | grep redis

3台主从服务器执行相同操作：

3.修改master节点redis配置文件

192.168.133.10

vim /etc/redis/6379.conf
bind 0.0.0.0                        #70行，修改bind 项，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

4.修改slave节点redis配置文件

192.168.133.20、192.168.133.30

vim /etc/redis/6379.conf
bind 0.0.0.0                        #70行，修改bind 项，0.0.0.0监听所有网卡
daemonize yes                        #137行，开启守护进程
logfile /var/log/redis_6379.log        #172行，指定日志文件目录
dir /var/lib/redis/6379                #264行，指定工作目录
replicaof 192.168.184.10 6379        #288行，指定要同步的Master节点IP和端口
appendonly yes                        #700行，开启AOF持久化功能
/etc/init.d/redis_6379 restart

5.验证主从效果

master节点上看日志

tail -f /var/log/redis_6379.log

master节点上验证从节点

redis-cli info replication

二.redis 哨兵模式

哨兵：起到监控，解决了故障自动切换，投票机制
没有解决写操作负载均衡

1.哨兵模式原理

• 主要是监控redis,master,slave进程，出现故障时，通过投票机制选择新的master,并将所有slave连接到新的master

2.哨兵模式主要功能

哨兵：监控，自动故障转移，通知

• 监控：监控检测redis,master,slave进程是否正常
• 消息通知：redis有故障，作为报警通知给管理员
• 故障转移：master节点故障，会转移slave节点
• 配置中心：故障发生，通知客户端新的master地址

3.哨兵监控系统过程

• 1）配置哨兵主节点配置信息
• 2）哨兵节点和主节点建立两条连接命令向从节点info命令和订阅连接
• 3）发送频道消息，用于投票
• 4）所有哨兵都能接受到消息，对消息进行分析提取，解析

4.哨兵模式下故障迁移

• 主观下线：请求交互过程中，超过很长时间没有回应，进行主观下线
• 客观下线：主节点处于主观下线，哨兵会进行询问，是不是主观下线，超过配置节点认为是主观下线，会标记为客观下线
• master选举：主节点客观下线，哨兵节点会发起选举，超过半数以上节点返回该节点标记为leader情况下，会有该leader对故障进行迁移
• 故障迁移：从节点选出新的主节点

5.优先级排序：

• 通讯正常，优先级相同是选择offset最大的
  1.将该节点设置成新主节点（master)
  2.将其他的从节点设置成新的主节点复制
  3.将旧的主节点变成新的主节点

6.优缺点

优点：高可用，基于主从模式，有所有主从模式的优点，主从可自动切换，系统更健壮(可抗更多高并发，抗更多的压力)

缺点：难以支持在线扩容，集群扩容上线，在线扩容比较复杂

哨兵结构由两部分组成:

哨兵节点和数据节点：

• 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据

• 数据节点：主节点和从节点都是数据节点。

  哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，所有节点上都需要部署哨兵模式，哨兵模式会监控所有的 Redis 工作节点是否正常，当 Master 出现问题的时候，因为其他节点与主节点失去联系，因此会投票，投票过半就认为这个 Master 的确出现问题，然后会通知哨兵间，然后从 Slaves 中选取一个作为新的 Master。

7.哨兵模式搭建

环境配置：

1）修改redis配置文件(所有节点操作)

Master：192.168.133.10
Slave1：192.168.133.20
Slave2：192.168.133.30
vim /opt/redis-5.0.7/sentinel.conf
#17行，关闭保护模式
protected-mode no
#21行，Redis哨兵默认的监听端口
port 26379
#26行，指定sentinel为后台启动
daemonize yes
#36行，指定日志存放路径
logfile "/var/log/sentinel.log"
#65行，指定数据库存放路径
dir "/var/lib/redis/6379"
#84行，修改 指定该哨兵节点监控192.168.163.10:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel monitor mymaster 192.168.163.10 6379 2
#113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel down-after-milliseconds mymaster 30000
#146行，故障节点的最大超时时间为180000（180秒）
sentinel failover-timeout mymaster 180000

2)启动哨兵模式

• 先启动master,再启动slave

Master：192.168.133.10
Slave1：192.168.133.20
Slave2：192.168.133.30

cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

3)查看哨兵模式信息

Master：192.168.133.10

redis-cli -p 26379 info Sentinel

4）模拟故障

Master：192.168.133.10

ps aux | grep redis
#杀死 Master 节点上redis-server的进程号，模拟故障
kill -9

5）验证结果

master:192.168.133.10

tail -f /var/log/sentinel.log

三.redis集群模式

• redis的哨兵模式基本已经可以实现高可用，读写分离，这种模式每台redis服务器都存储相同的数据，浪费内存资源，redis3.0上加入了cluster集群模式，实现了redis的分布式存储，每台redis节点存储着不同的内容
• 集群部署最少要3太master节点，最好使用3主3从六个节点的模式

组成：

• cluster集群由多个redis服务器组从的分布式网络服务群集，群集中有多个master主节点，每一个主节点都可读可写，节点之间会相互通信，两两相连，redis集群五中中心节点
• 可给每一个主节点添加从节点，主节点和从节点直接遵循主从模型的特性，当用户需要处理更多请求的时候，添加从节点可扩展系统的读性能

故障转移

• redis集群的主机节点内置了类似redis
• sentinel的节点故障检测和自动故障转移功能，当集群中某个主节点下线时，集群中其他在线主节点会注意到，对已经下线的主节点进行故障转移

故障转移方法：和redis sentinel进行故障转移的方法基本一样，
不同的是，集群里面，故障转移是由集群中其他在线的主节点负责进行的，所有集群不必另外使用redis sentinel

作用：

• 1.数据分区：数据分区(或称数据分片)是集群最核心的功能。
  集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。
  Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。
• 2.高可用：集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任一节点发生故障时，集群仍然可以对外提供服务。

1.搭建redis集群模式

redis的集群一般需要6个节点，3主3从。
先在六台服务器上安装redis数据库

这里使用不同的节点只是想说redis集群模式可以指定端口，不是只能使用6379端口，如果不想改的话也可以全都使用一个端口，这样创建目录和修改配置的时候更方便，所有节点除了监听的ip不一样以外没什么不同。

1)创建并复制相关文件

所有节点

#创建文件，文件名要根据端口创建，方便区别
cd /etc/redis/
mkdir -p redis-cluster/redis6371 
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6371/
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6371/

2）修改配置文件，开启群集功能

所有节点
先设置一个节点

cd /etc/redis/redis-cluster/redis6371
vim redis.conf
#69行，修改bind项，监听自己的IP
bind 192.168.163.11
#88行，修改，关闭保护模式
protected-mode no
#92行，修改，redis监听端口
port 6371
#136行，以独立进程启动
daemonize yes
#699行，修改，开启AOF持久化
appendonly yes
#832行，取消注释，开启群集功能
cluster-enabled yes
#840行，取消注释，修改，群集名称文件设置
cluster-config-file nodes-6371.conf
#846行，取消注释，群集超时时间设置
cluster-node-timeout 15000

在这个节点上配置好的文件复制过去

scp /etc/redis/redis-cluster/redis6371/redis.conf root@192.168.133.10:/etc/redis/redis-cluster/redis6372/redis.conf
scp /etc/redis/redis-cluster/redis6372/redis.conf root@192.168.133.20:/etc/redis/redis-cluster/redis6373/redis.conf
scp /etc/redis/redis-cluster/redis6373/redis.conf root@192.168.133.30:/etc/redis/redis-cluster/redis6374/redis.conf
scp /etc/redis/redis-cluster/redis6374/redis.conf root@192.168.133.40:/etc/redis/redis-cluster/redis6375/redis.conf
scp /etc/redis/redis-cluster/redis6375/redis.conf root@192.168.133.50:/etc/redis/redis-cluster/redis6376/redis.conf

其他服务器上：

cd /etc/redis/redis-cluster/redis6372
vim redis.conf
#69行，修改bind项，监听自己的IP
bind 192.168.133.20
#92行，修改，redis监听端口
port 6372
#840行，取消注释，修改，群集名称文件设置
cluster-config-file nodes-6372.conf

3）启动redis节点

所有节点

#每台服务器进入对应的文件中，执行命令
cd /etc/redis/redis-cluster/redis6371/
redis-server redis.conf
ps -ef |  grep redis

4）启动集群

Master1 192.168.133.10:6371

redis-cli --cluster create 192.168.133.10:6371 192.168.133.20:6372 192.168.133.30:6373 192.168.133.40:6374 192.168.133.50:6375 192.168.133.60:6376 --cluster-replicas 1

5）测试集群

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

总结：

redis集群三种模式：主从复制，哨兵模式，集群模式

主从复制：

• 主从复制：将一台redis服务器的数据，
  复制到其他的redis服务器
• redis主从复制作用：数据冗余、故障恢复、负载均衡、高可用

哨兵模式：

哨兵模式：监控，自动故障转移，通知，没有解决写操作负载均衡，投票机制

• 监控过程：
• 1.需要配置哨兵的主节点配置信息
  2.哨兵节点和主节点建立两条连接命令向从节点发送info命令和订阅连接
  3.发送频道消息，用于投票
  4.所有哨兵都能接受到消息，对消息进行分析提取，解析

集群模式：

• cluster集群：哈希槽的方式进行分配
  多个redis服务器组成的的分布式网络服务集群
  故障转移和哨兵模式基本一样
• 作用：数据分区，高可用

为什么要用 Redis？

为什么要用缓存?

• 高性能：操作缓存直接操作内存，速度快
• 高并发：直接操作缓存，请求大于直接访问数据库的
  数据库中部分数据转移到缓存中，大部分请求直接到缓存，不经过数据库

redis为什么这么快

• 1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速
• 2、数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；
• 3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
• 4、使用多路 I/O 复用模型，非阻塞 IO
• 5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；