Redis分布式集群实战（2）——搭建redis主从同步及哨兵模式
上一篇介绍了Redis基础知识，以及与mysql，memcached区别。此篇搭建Redis主从同步。
文章目录
- 一、Redis主从同步
- 1、主从复制概念
- 2、特点
- 3、实验
- 二、搭建哨兵模式
一、Redis主从同步
1、主从复制概念
主从复制模型中，有多个redis节点。
其中，有且仅有一个为主节点Master。从节点Slave可以有多个。
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。
2、特点
（1）主节点Master可读、可写.
（2）从节点Slave只读。（read-only）
因此，主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。
实验环境：
本实验搭建主从同步，一主两备
server1虚拟机作主Redis缓存数据库:
ip为：172.25.76.1
关闭防火墙及selinux
server2虚拟机作备Redis缓存数据库:
ip为：172.25.76.2
关闭防火墙及selinux
server3虚拟机作备Redis缓存数据库:
ip为：172.25.76.3
关闭防火墙及selinux
3、实验
主Redis（server1）上：
yum install -y gcc -y #下载GNU编译器套件gcc
tar zxf redis-5.0.3.tar.gz #解压redis安装包
cd redis-5.0.3 进入解压目录
make #编译
make install #安装
cd utils/
./install_server.sh #执行redis安装服务脚本
vim /etc/redis/6379.conf #编辑配置文件
70 bind 0.0.0.0 #修改监听端口
/etc/init.d/redis_6379 restart #开启redis
netstat -antlp #查看开启端口
步骤一：下载GNU编译器套件gcc
步骤二：解压redis安装包
步骤三：进入解压目录，进行编译
步骤四：安装
步骤五：安装redis，安装完会自动启动
步骤六：修改配置文件/etc/redis/6379.conf中的监听端口，所有人均可连接
步骤七：重启redis，查看端口
备Redis（server2）上：
yum install -y gcc -y #下载GNU编译器套件gcc
tar zxf redis-5.0.3.tar.gz #解压redis安装包
cd redis-5.0.3 进入解压目录
make #编译
make install #安装
cd utils/
./install_server.sh #执行redis服务脚本
vim /etc/redis/6379.conf #编辑配置文件
bind 0.0.0.0 #修改监听端口
slaveof 172.25.12.1 6379 #文件最后一行添加主redis信息
systemctl start redis_6379 #开启redis
netstat -antlp #查看开启端口
步骤一：下载GNU编译器套件gcc
步骤二：解压redis安装包，并进行编译安装
步骤三：修改监听端口，在文件最后一行加入主redis信息
步骤四：重启redis，查看端口
备Redis（server3）上：
yum install -y gcc -y #下载GNU编译器套件gcc
tar zxf redis-5.0.3.tar.gz #解压redis安装包
cd redis-5.0.3 进入解压目录
make #编译
make install #安装
cd utils/
./install_server.sh #执行redis服务脚本
vim /etc/redis/6379.conf #编辑配置文件
bind 0.0.0.0 #修改监听端口
slaveof 172.25.12.1 6379 #文件最后一行添加主redis信息
systemctl start redis_6379 #开启redis
netstat -antlp #查看开启端口
vim /etc/redis/6379.conf
测试：
二、搭建哨兵模式
此实验在上一个实验基础上进行。
1、哨兵模式解决的问题
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。
2、哨兵模式概述
Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
这里的哨兵有两个作用：
通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件(/etc/redis/sentinel.conf)，让它们切换主机。
用文字描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。
监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel系统，互相通信并交换彼此关于被监视服务器的信息，下图中3个Sentinel监控着Master1和它的2个Slave
例如：
在Server1 掉线后：
升级Server2 为新的主服务器：
当server1服务器重新上线后：
3、哨兵sentinel工作原理
Sentinel状态持久化
snetinel的状态会被持久化地写入sentinel的配置文件中。每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。这意味着，可以安全的停止和重启sentinel进程。
Sentinel作用：
1）Master状态检测
2）如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave。
3）Master-Slave切换后，主redis配置文件6379.conf、备redis配置文件6379.conf和主备redis的sentinel.conf的内容都会发生改变，即主redis的6379.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。
Sentinel工作方式（每个Sentinel实例都执行的定时任务）
1）每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个PING命令。
2）如果一个实例（instance）距离最后一次有效回复PING命令的时间超过 own-after-milliseconds 选项所指定的值，则这个实例会被Sentinel标记为主观下线。
3）如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4）当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。
5）在一般情况下，每个Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
6）当Master被Sentinel标记为客观下线时，Sentinel 向下线的 Master 的所有Slave发送 INFO命令的频率会从10秒一次改为每秒一次。
7）若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。 若 Master重新向Sentinel 的PING命令返回有效回复，Master的主观下线状态就会被移除。
三个定时任务
sentinel在内部有3个定时任务
1）每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的：
a）发现slave节点
b）确认主从关系
2）每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道(sentinel:hello)。sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。
3）每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。
4、 Sentinel配置文件
至少包含一个监控配置选项，用于指定被监控Master的相关信息
Sentinel monitor ,例如
sentinel monitor mymaster 127.0.0.1 6379 2
监控mymaster主服务器，服务器ip和端口，将这个主服务器判断为下线失效至少需要2个Sentinel同意，如果多数Sentinel同意才会执行故障转移
Sentinel会根据Master的配置自动发现Master的Slaves
Sentinel默认端口号未26379
5、搭建哨兵模式
主Redis（server1）上：
cp sentinel /etc/redis/ #将redis安装目录下哨兵配置文件复制到/etc/redis/
vim /etc/redis/sentinel.conf
17 protected-mode no ##关闭保护模式,便于测试。如果你不关闭保护模式，启动哨兵的时候，无法正常运行。还有个解决办法就是你设置密码，但是一般都不设置redis的密码。麻烦，我每次连接还得输入密码。在部署中，可以设置密码。）
121 sentinel monitor mymaster 172.25.76.1 6379 2 ##配置监听的master信息,这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，172.25.76.1代表监控的主服务器，6379代表端口，后面的2表示投票机制，至少有2个节点认为master挂了，才会切换
146 sentinel down-after-milliseconds mymaster 10000 ##改为10s，表示master挂后10s会切换
####注意注意：一定要先scp到slave节点上再启动
scp sentinel.conf server2:/etc/redis/ #将修改好的配置文件传给从redis，此时需要保证本机解析文件/etc/hosts里边配置好了server2的域名解析
scp sentinel.conf server3:/etc/redis/
redis-server /etc/redis/sentinel.conf --sentinel ##开启哨兵
步骤一：将哨兵配置文件复制到/etc/redis/，并修改配置文件
步骤二：将修改好的配置文件拷贝给slave
步骤三：开启哨兵
在备redis（server2）上：
开启哨兵：
redis-server /etc/redis/sentinel.conf --sentinel
在备redis（server3）上：
查看配置文件：
开启哨兵：
redis-server /etc/redis/sentinel.conf --sentinel
主Redis（server1）上：
redis-cli
info #查看master信息
redis-cli -p 26379
info #查询master哨兵信息
注意启动的顺序。首先是主机（server1）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。
模拟故障测试：
主Redis（server1）上：
备Redis（server2）上：
备Redis（server3）上：
主Redis（server1）上：
主redis上线：
备Redis（server2）上：
其中+sdown表示哨兵主观认为主数据库停止服务了，+odown表示哨兵客观认为主数据库停止服务了。try-failover表示哨兵开始进行故障恢复，经过一系列操作后failover-end表示哨兵完成了故障恢复。最后输出的+slave信息表示故障恢复后新的主从结构，主数据库由原来的6379变为现在的6381,6380和6382变为6381的从数据库。
此时会发现mster和slave的redis配置文件6379.conf和哨兵配置文件sentinel.conf内容均发生变化：
主Redis（server1）上：
vim /etc/redis/6379.conf
vim /etc/redis/sentinel.conf
备Redis（server2）上：
vim /etc/redis/6379.conf
vim /etc/redis/sentinel.conf
备Redis（server3）上：
vim /etc/redis/6379.conf
vim /etc/redis/sentinel.conf
