CentOS-7下Redis主从复制+sentinel的搭建过程

1.单机下的问题

1.单机运行下的问题

从CentOS-7下安装Redis的详细过程(多实例)我们学会了redis的安装过程，尽管一台机器可以开启多个实例，但每个实例都是相关独立的，即每个实例都是一个单点。那么单点有什么问题呢？
1.单点故障。单机服务down掉之后，直接会导致整个业务线不可用；
2.单机的存储容量有限，我们每个redis最后分配的内存不要太大，能够是redis更加的灵活，但单机的容量是很有限；
3.单机的访问压力比较大。如果所有的app都连接到一个单机的redis上，并发过大，会造成单机访问量多大，哪怕redis可以撑住，但是单机的网络也会受到大的考验。

2.如何结果单机运行下的问题

既然单机运行下会产生很多问题，那么我们就进行扩展，进行1变多的扩展。但是1变多又会产生什么问题呢？
很明显，1变多会产生数据一致性和高可用的矛盾。为什么？
首先，要保证数据的强一致性，那么所有节点的数据都要保持一致，那么数据同步就要采用同步阻塞的方式进行，但是这样一旦有一个节点出问题，那么其他所有节点都要等待，就会导致服务不可用或者说不能高可用；
其次，如果我们考虑高可用的问题，那么我们就要使用异步的方式进行，但异步就不能保证数据的强一致性；
最后，我们再保证高可用的同时，可以采取某种措施，来保证数据最终的一致性。
上述这三种情况，我们可以采用以下的图来说明：

而目前redis的主从复制采用的第二种模式，即不能保证数据的强一致性。

3.CAP原则

从上述的阐述可以看出，数据一致性和高可用貌似就是两个矛盾体，要想保障高可用，那就要牺牲一部分的数据一致性；如果要保障数据的强一致性，那就要牺牲掉高可用。
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
有兴趣的同学可以深入的研究下，这里不再过多展开。

4.主从复制

根据上面单机锁暴露出的问题，我们利用主重复制，可以解决单机读压力过大的问题， 将读写分离，进一步提高redis的高可用。下面我们对主从复制的配置过程详细说一下。

2.主重复制

1.实验物料

我这次实验采用3台服务器，其中一个Master(主)，两个Slave(从)。

2.实验过程

1.首先在三台服务器上创建3个redis的实例，端口都为6379；这个在上篇博客《CentOS-7下安装Redis的详细过程(多实例)》已做了详细说明，在这里就不在过多解释了。
2.配置网络。第一步我们创建出来的redis实例，默认只有本机的127.0.0.1可以访问，所以我们为了方便实验，直接把bind设置为0.0.0.0，同时protected-mode 设置为no。所有的设置都是修改/etc/redis的6379.conf文件中（不同的安装，文件路径名称可以不同，根据自己情况查找），具体如下图：

3.在192.168.15.21下的redis的配置文件（6379.conf）配置追随的Maser

4.在192.168.15.22下的redis的配置文件（6379.conf）配置追随的Maser,同第三步一样；
5.启动Master(192.168.15.20:6379)的redis实例；然后分别启动Slave(192.168.15.21:6379)和Slave(192.168.15.22:6379)的两个实例，此时主从复制就完成了，是不是太简单了。

3.高可用（High Availability）

1.如何高可用？

从上面的主重复制配置过程，我们可以看到，虽然我们进行了主重复制来实现了水平方向的扩展，进一步实现了高可用，但是，我们的Master这时候又出现问题了，因为它现在是一个单点。假如这个Master服务挂掉，我们需要手动重现配置出一个主，进行故障转移，过程是比较耗时，并且这其中还要关注数据大量丢失的问题。那这时候我们如果有一个程序能够帮我们自动进行故障转移就好了。可是这时候又出现问题了，只要是程序，就有可能挂掉，监控程序也是一样，所以健康程序我们也做成集群。恰好，redis为我们提供了哨兵（sentinel)，来实现高可用。

2.哨兵主重切换

哨兵怎么样才能确认Master挂了？加入我们有一个哨兵，那肯定这一个哨兵就能直接决定主是不是挂了，因为它的比重就是100%。如果是两个呢？这时候如果两个哨兵都说Master挂了，我们就可以认为Master挂了;如果一个哨兵说Master挂了，另一个哨兵说Master没有挂，那这个时候各占一半，谁也说服不了谁，那么这时候就有可能出现两个Master,出现脑裂问题。再进一步，如果是三个哨兵呢？三个哨兵的时候，如果其中两个哨兵组成一个小的团体，另外一个哨兵自己组成一个小团体，那么这时候，如果两个哨兵说Master挂了，那么这时候可信度是很高的，因为是2:1，这时候就可以认为Master挂了，就可以从Slave中选出一个作为Master。所以我们只要过半，其实就可以采纳。上面的这些阐述，其实说明了一个问题，就是哨兵，我们也要在强一致性和高可用之间进行选择。

3.哨兵搭建

实验物料我们还是以上面的三台机器，每台机器起一个哨兵的实例。

配置文件如下：

port 36379
sentinel monitor mymaster 192.168.15.20 6379 2

三台服务器上的配置都一样就行。这里我们就配置最简单的配置，他还有很多的参数，具体的可以根据redis的官方文档自行配置。
配置完以后，就启动sentienl实例。用以下命令：

redis-server ./sentinel.conf --snetinel

这样我们的一个最简单哨兵就配置完成了。
注意：如果无法连接，可能就是防火墙没有关闭，一定要检查一下哦。其实我们启动每个实例后，可以用redis_cli连接一个各台服务器的redis，看是否能够联通。
如果不正之处，还请大家多多指教。