环境：
1、服务器使用CentOs7系统
2、Redis使用5.0.8版本
3、四台服务器
将192.168.100.4这一台做为master主数据库，其余三台做为slave从库
| IP | 功能 |
|---|---|
| 192.168.100.4 | master |
| 192.168.100.5 | slave |
| 192.168.100.6 | slave |
| 192.168.100.7 | slave |
部署前的准备工作：
1、关闭服务器防火墙
systemctl stop firewalld
2、每台机器redis.conf 配置文件 注释bind命令，或者改成bind 0.0.0.0
# bind 127.0.0.1
3、开启守护进程和设置Redis日志路径
daemonize yes //如果是docker安装redis,就不用开启守护模式了。
logfile "/var/log/redis/redis.log"
开始部署主从复制
在redis老版本里，主从复制的配置选项是 slaveof 后续版本里用的是replicaof
现在分别进入192.168.100.5,100.6,100.7 这三台服务器，进入它们各自的Redis配置文件里，
Redis在服务器的目录是/usr/local/server/redis/
cd /usr/local/server/redis/conf
vi redis.conf
找到下面的replicaof命令
#replicaof <masterip> <masterport>
replicaof 192.168.100.4 6379
#因为使用requirepass 设置了密码 为lafenfen，需要添加一下密码
master auth lafenfen
这两项配置完成后，主从复制就完成了。 192.168.100.4 是master 服务器，不需要配置。
启动Redis服务
现在启动Redis服务，先从master主数据库服务器开始。然后在启动slave从数据库服务器。
cd /usr/local/server/redis/bin
./redis-cli ../config/redis.conf # 如果没有开启守护模式 ，记得启动进后面添加 &
四台服务器启动完毕后，检查Redis是否启动成功
ps aux|grep redis|grep -v 'grep'
显示有Redis进程信息，Redis服务启动成功
root 14884 0.1 0.1 158504 3468 ? Ssl Jun11 13:36 ./redis-server 127.0.0.1:6379
现在登陆192.168.100.4 master数据库服务器，检查主从复制是否成功。
cd /usr/local/server/redis/bin
./redis-cli
auth lafenfen
//运行这个命令，可以查看当前Redis服务的工作角色
info replication
如果主从复制成功，会显示当前Redis节点的角色是 master
会看到slave从数据库的连接信息，有三个。说明配置成功。
如果登陆其余三台服务器，运行 info replication 命令，会看到当前角色是
role:slave
主从复制配置选项
主从复制的部署工作很简单，完成部署后，需要了解几个配置选项
在前面的操作里，使用了replicaof 和masterauth
接下来有这些内容：
1.传输延迟优化
repl-disable-tcp-nodelay no
nodelay 其实是英语 no delay 意思是不要延迟。
| 选项值 | 说明 |
|---|---|
| yes | 优先考虑节省带宽，会造成主从延迟，最长大概在40毫秒左右 |
| no | 默认值，主从之间传输数据会非常及时，延迟将变小。但会消耗更多的带宽 |
如果生产环境要求低延迟，就将此选项设置为no.
2.主从数据一致性
当master结点异步传输RDB文件到slave库进行数据同步时，slave库在重新加载RDB文件，执行数据同步操作的同时，也可以接受客户端请求，返回数据。
那么此时，问题来了，slave库是给旧的数据，还是等待主从数据同步完成后，在返回最新数据。
replica-serve-stale-data yes
| 选项值 | 说明 |
|---|---|
| yes | 直接给客户端返回数据，不需要等待master同步完成 |
| no | 在主从之间的同步没有完成时，从数据库将拒绝客户端请求，并将返回一个错误提示“SYNC with master in progress” |
所以对于主从延迟要求特别高的情况下，将此选项设置为no,每次等待同步完成后，才返回数据。
需要注意的地方，当设置选项为no时,在slave 库执行下面这些命令将不会引发报错：
INFO、replicaOF、AUTH、PING、SHUTDOWN、REPLCONF、ROLE、CONFIG、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE、PUBLISH、PUBSUB、COMMAND、POST、HOST:和LATENCY
3.从库是否只读
这个选项默认值为yes,代表slave库只能读操作，不能写操作。
如果想让slave库可写，将该配置项改为no，就可以了。
replica-read-only yes(默认)
但是就算从数据库可以支持写入，当主数据库同步数据时，也会清除这些数据。
主从搭配的架构里，主数据库负责写入，从数据库负责读取。因此从数据库基本不需要写入东西。
4.积压队列
在Redis2.8版本开始，支持增量复制。它的意思就是主从结点因意外情况断开连接，当重新连接后，master库并不一定要将全部的数据都同步过去。它可以根据需要，只将断开连接的这段时里的数据，同步过去。这样大大增加了效率。
执行增量复制的前提条件有这么几步：
（1）每次master同步数据的时候，会将命令记录到backlog(积压队列)，并记录命令的偏移量。
（2）slave库也会记录偏移量
（3）slave库还会记录下master主库的执行ID（如果master重启，这个执行ID就会发生变化）
当主从重连时，slave库发出PSYNC请求，后面会接上master的运行ID和最新的命令偏移量。
master主机会检查运行ID和偏移量，如果这两个都有记录，那么就执行增加复制。如果没有，就还是会执行一次全量同步。
下面的两个配置项，决定了积压队列的大小，还有队列数据的释放时间。
repl-backlog-size 1mb
repl-backlog-ttl 3600 单位是s ，在1小时后，积压队列里的数据在内存释放。
5、设置从数据库优先级
这个选项，是配置哨兵使用的，当master崩溃的时候，哨兵会从其余的slave从节点选择一台做新的master主数据库，此时给从数据库设置优先级。会优先将优先级高的slave节点选做master.
这个配置项里 值越低，代表优先级越高。 可以用10，15，20，50，来配置。
但一定不要选0.
replica-priority 100
6、主从复制安全保障
在现有架构体，使用的是一主三从结构，为了保障同步的安全性，有下面两个配置。
min-replicas-to-write 的作用是 当slave从节点与master主节点网络不通，或者slave节点崩溃了。当少于2台时，master主节点将停止写入，直到与master相连接的slave节点恢复2个或2个以上。
min-replicas-max-lag 表示允许从数据库失去连接的最短时间，从数据库会发送 REPLCONF ACK 命令来检查是否和主数据库连接，如果超过10秒无法连通，证明失去连接，那么min-replicas-to-write的数值就会减1.
min-replicas-to-write 2
min-replicas-max-lag 10 （单位：秒）
这两个选项默认是关闭的，建议在分布式系统中，可以打开它并进行合理配置，可以降低主从架构中因为网络分区导致的数据不一致问题。
其余的几项配置，有需要时可以查看redis.conf配置里的英文注释。或者其它博主提供的文档。
当master崩溃后的人工操作
在很多教程里，Redis主从复制这块讲到，为了减轻master节点的写压力。可以关闭master的持久化(RDB,AOF) ,使用slave从节点的RDB存储数据。
当master崩溃时，人工重启的顺序是：
1、从其它的slave节点里选择一台当新的master ，比如我选择192.168.100.5
2、登陆192.168.100.5，输入命令：
./redis-cli
auth 密码
replicaof no one //这条命令是断开主从连接，让当前的slave节点变成master
然后，分别进入其余三台机器，将redis.conf 里的replicaof 选项配置为
replicaof 192.168.100.5 6379
然后重启Redis服务让它生效。 这样人工操作完成。
那么假如你之前，真的把192.168.100.4的持久化关闭了。在重启服务时，又先进行了master主机服务重启。那么master重启后，会读取本地的RDB文件，这时候的RDB存储肯定是之前的旧数据，读取后，master又会同步到其它的从节点，这就会造成数据丢失。
当架构里的节点数量少时，人工操作，到也没什么。如果机器很多，人工操作会慢，还有可能会造成错误。
于是哨兵诞生了，它是一种独立的进程，可以监控master和slave 节点，当master崩溃时，会进行自动选择，和新master服务启动。
接下来我们学习一下哨兵的部署操作。
哨兵的部署操作
哨兵是独立的进程，在当前的架构里，有1个master和3个slave, 我可以开启4个sentinel（哨兵）进程，保障监控工作。
在/usr/local/server/redis/config 目录下，文件 sentinel.conf 是哨兵的配置文件。
配置内容我把它分成了两块来操作
1.基础部分
port 端口号，注意每个配置文件里的端口号都要不一样，不能重复。
daemonize=yes 设置为yes,以守护进程运行
logfile "/var/log/server/sentinel.log" 配置日志,方便后期观察
注意每台服务器上的哨兵进程的端口号，都要单独配置，不要重复。
2.哨兵选项
主要是下面的这五个选项
//juju 是自定义的监控主数据库起的名字，默认系统用mymaster
//192.168.100.4 是master 的IP，6379 端口号
//3 代表的含义是，当100.4这台服务器崩溃时，哨兵们会进行报告，当有至少3个哨兵报告说，发现100.4 崩溃时
//哨兵机制就会重新选择一台新的机器当master
sentinel monitor juju 192.168.100.4 6379 3
//配置新密码lafenfen是密码
sentinel auth-pass juju lafenfen
//根据设置的时间，哨兵节点将向主从数据节点和其它哨兵节点，发通ping命令，
//如果超过这个时间没有得到回复，就判定对方节点已经出故障。
//单位是毫秒，默认是30秒，我这边调整了10秒
sentinel down-after-milliseconds juju 10000
//当哨兵启动了新的master节点后，
//其余的slave从属节点会向master发送复制要求，这个配置项将决定
//每次master会向多少个slave节点发送复制操作，建议不要太大，会增加master的网络和磁盘开销。
sentinel parallel-syncs juju 1
//处理故障转移整个过程的超时时间,默认是3分钟
sentinel failover-timeout juju 180000
现在开启哨兵服务，使用下面的命令
./redis-sentinel ../config/sentinel.conf
出现sentinel代表哨兵服务启动成功
测试哨兵功能
来到192.168.100.4 服务器，通过kill -9 杀死redis服务，
然后可以观察slave从数据库服务器上的日志，
/var/log/server/redis.log 会显示连接master失败
/var/log/server/sentinel.log 会显示当前哨兵的处理过程。
大概过了 sentinel down-after-milliseconds juju 10000 这个选项的设置时间后。也可能更快，或者更慢。
日志显示master连接成功。或者在sentinel.log 里也能看到更换了新的master节点。关于日志这块的显示内容，没有粘贴。
也可以登陆redis服务后，通过info replication 命令查看当前角色。
注意事项
当哨兵程序进行完故障转移后，会在sentinel.conf配置文件底部做一些重写记录。
如果你想修改哨兵配置，当停止哨兵程序后，修改完相关配置项，记住一定要把这些生成的配置内容，删除掉。否则可能会造成master出现故障后，无法实现自动切换的问题。
当时操作环境的时候，就遇到了这个问题。后来查了资料后才发现是重新写入的记录造成了影响。
至此完成。
使用哨兵后，客户端的应用程序，也要做一些修改。这块的内容后续会传入博客里做记录。
