一、主从集群的介绍

redis的主从复制集群为了提高效率降低客户端等待时长，主从间的数据同步采用的是弱一致性的策略，即客户端请求发到主机后，不论是否同步到备机，都认为此次请求是成功的，这样虽然效率上提高了，但是数据一致性却得不到保障；所以redis提供了一个min-replicas-to-write参数用来配置，至少有几台从机与主机保持连接时主机才能执行写入操作，一定程度上维护了数据的一致性；
其次，使用redis主从复制集群主要是为了解决单点故障问题，从机相当于主机的备份，且只提供读不提供写入功能，为的是在主机故障导致不能对外提供服务时从机能快速接替从而实现集群的高可用；而集群间主从的切换显然不能通过人工来完成，所以redis提供了一个哨兵的概念，顾名思义，哨兵即负责监控放哨，当主机不可用时迅速从从机中选出一个主机来，而这又涉及到以下两个方面；

1、如何判断redis集群的master不可用
判断master不可用使用的是过半机制，即当哨兵集群中某一个哨兵发现master不可用时，会向集群其他哨兵发送is-master-down-by-addr指令询问master是否真的挂了，集群其他哨兵收到指令后会根据自身与master的连接情况判断是否真的挂了，然后给第一个哨兵作出响应，是否赞成master挂了；当超过集群数量一半加1的机器认为master挂了那么就投票通过，即认为redis集群的master真的挂了，需要进行选主操作；所以哨兵也应该是集群部署的，单个部署的话与主机是一对一的关系，不稳定性太大容易造成误判
2、哨兵发现master挂了过后又是如何给redis集群做主从个切换的呢(哨兵的选主)
当第一个发现master挂了的哨兵收到其他哨兵的响应确认master挂了后，会继续发送一个请求，希望自己成为哨兵的leader来进行redis集群的主从切换操作，此时该哨兵被称为候选者；集群中的所有哨兵都只有一次投票机会，投给自己或者别人，需要注意的是只有候选者才能将票投给自己；哨兵之间的选主使用的是Raft算法

注意：
1、一般最先发现master挂了的哨兵会作为哨兵集群选主的候选者，会自动投给自己一票
2、如果同一时点有两个哨兵同时发现master挂了，那么就会有两个候选者，他们都投给自己一票，需要注意的是集群中的每个哨兵只有一次投票机会，所以两个候选者之外的哨兵肯定只会给两个候选者中的一个投票

二、主从集群的安装部署

我在安装步骤里做了一些笔记，大概也囊括了主从复制的大部分特性，并且也贴上了关键命令执行的图片，所以我就不拎出来单独介绍了

1、环境准备

1、先在linux下安装redis，这里我就不贴教程了，我安装的是redis-5.0.5版本
2、进入redis安装目录下的utils文件夹，执行 ./install_server.sh命令然后无脑回车，自动安装redis服务，做集群的话则第一遍默认执行6379，第二遍第三遍可以把端口号换成6380和81，这样我们主机里就有三个redis服务了
3、安装完后执行service redis_6379 stop、service redis_6380 stop和service redis_6381 stop分别停掉这三台主机，因为后续演示我们需要前台阻塞运行查看日志
4、在任意目录下创建一个文件夹testRedis，然后把/etc下的redis的配置文件复制过来，因为我们集群测试会给一堆配置，所以另外复制一份，不动系统本身的配置，命令如下
- mkdir testRedis
- cd testRedis
- cp /etc/redis/* ./
5、编辑/testRedis下的三个配置文件，将
- daemonize置为no，使redis服务前台运行，方便观察日志；
- 注释掉 logfile /var/log/redis_6379.log使其前台打印
- appendonly置为no，关闭aof使其只使用rdb，具体原因后面会分析
上面的配置完成后，表示接下来启动的redis实例是会前台阻塞运行且不使用aof的持久化方式
6、启动三个redis实例
- redis-server ~/testRedis/6379.conf
- redis-server ~/testRedis/6380.conf
- redis-server ~/testRedis/6381.conf
7、启动三个reids-cli连接三个实例
- redis-cli -p 6379
- redis-cli -p 6380
- redis-cli -p 6381
8、通过命令的方式使6380和6381作为slave追随6379
- 老版本命令 slaveof 127.0.0.1 6379
- 新版本(5.0)命令 replicaof 127.0.0.1 6379
注意：
1、主从集群搭建完毕后，在6379set数据后80和81就能同步过去了，但是默认情况下80、81是不能写入的，会报 READONLY You can’t write against a read only slave的错误；并且从机第一次追随主机时是会flush掉本身所有数据的，会全量同步主机的数据过来；
9、模拟从机下线
- 6381下线重启仍追随6379，不开启aof，命令如下：
  redis-server ~/testRedis/6381.conf –replicaof 127.0.0.1 6379
- 6381下线重启仍追随6379，同时开启aof，命令如下：
  redis-server ~/testRedis/6381.conf –replicaof 127.0.0.1 6379 –appendonly yes

1、由上面两个图可以看到，开启aof时从机(6381)是会先flush掉自身数据重新从master(6379)身上全量同步数据的，所以从效率上来说增量同步肯定优于全量同步的
2、从机下线重启后仍然追随原主机(即下线前做过主从同步)的话，如果从机重启时未开启aof，那么会做增量同步，否则则会进行全量同步；因为rdb中会记录原主机信息而aof不会；

10、模拟主机下线
直接终止6379的进程，那么此时6380和81会报Error condition on socket for SYNC: Connection refused错误，并且均只能提供读服务不能提供写入能力，所以此时可以人为的让6380或6381使自己作为master，命令如下
- replicaof no one
  然后再使另一个实例追随新的matster，这样redis集群又可以对外提供服务了，但是这种靠人为选主并切换终究不靠谱，所以就要用到哨兵模式，用来监控，当master挂了的时候能快速的响应，重新选主，使集群快速可用
11、集群相关的配置
- replica-serve-stale-data yes 从机同步主机数据期间是否将自己原本的旧数据对外暴露，默认对外暴露
- replica-read-only yes 从机是否开启只读模式，默认从机只读
- repl-diskless-sync no 主机以何种方式将rdb文件同步给备机，yes表示主机生成rdb后直接通过网络IO将数据发给备机；no的话表示主机先将rdb通过磁盘IO落本机磁盘再通过网络传送给备机；默认为先落磁盘再发送给从机
- repl-backlog-size 1mb
  增量复制的大小；即当从机同步完后主机会维护一个增量数据的队列，从机下次备份时可以拿着offset从队列里直接取增量数据；默认是1m，但是需要根据业务的写入量来确定该值大小；因为如果业务写入过多，从机下线恢复这段时间写入超过默认的1m的话，那么只使用增量同步的话就会丢失数据了
- min-replicas-to-write 3
  可以理解成master能否执行写入操作的一个限制条件；当有指定个数的从机与主机保持连接时master才能执行写操作；默认为当有3个从机与master保持连接master才能执行写入操作,否则master不对外提供写入能力；这样虽然不能保证所有的从机都能同步到master的数据，但是可以保证至少有几个从机存活master才能执行写入操作，避免丢失过多数据；值为0表示关闭该限制
- min-replicas-max-lag 10
  从机是否与主机保持连接的标准；默认为延迟小于10s的从机才被认为是健康的，是与主机保持连接的

三、哨兵集群搭建

1、由于哨兵我们也搭建一个集群，所以创建三个哨兵的配置文件，在testRedis下执行以下命令
- vi 26379.conf，按i输入：
- port 26379
- sentinel monitor mymaster 127.0.0.1 6379 2
一个redis哨兵集群可以监控多个redis集群，所以mymaster表示redis集群的名称，后面跟redis集群master的ip和端口；最后一个数字2表示redis集群中几个实例通过后投票有效，即我们常说的过半加1后的那个值，因为我的redis集群只有三台机器，所以这个值为3/2+1=2
- cp 26379.conf 26380.conf 复制26379的配置，修改26380.conf里的port为26380
- cp 26379.conf 26381.conf 复制26379的配置，修改26381.conf里的port为26381
2、启动redis集群中的各个实例，以6379为主6380和6381为slave追随6379
3、启动哨兵集群
- redis-server ./26379.conf –sentinel
- redis-server ./26380.conf –sentinel
- redis-server ./26381.conf –sentinel
上图，哨兵配置文件只配置了redis集群的主机ip和端口，但是哨兵启动后却获取了整个redis集群所有实例的信息，是因为redis集群中从机追随主机时主机已经知道从机的信息了，所以哨兵通过获取主机信息既能获取从机的信息
另外，哨兵又是如何获取其他哨兵的信息的呢？这是因为其使用了redis本身的发布订阅功能；即在redis集群的master上发布各哨兵信息，哨兵们自行订阅，可以通过在redis任意实例上执行PSUBSCRIBE * 来观察哨兵之间的交互信息，如图：
4、当redis集群的master下线后哨兵集群是会自动修改自身的配置文件，将sentinel monitor mymaster后面换成最新的master的ip加端口，并且还会在配置文件后追加识别到的redis的其他从机和其他哨兵信息，如图

至此，redis的主从复制集群介绍完毕，如有纰漏还望指正！后续会继续更新redis的分片集群……