Redis集群——主从复制以及哨兵模式

##主从复制的定义

Redis的主从复制表示将Redis的服务器分为主服务器（Master）以及多个从服务器（Slaves），其目的是减少主服务器的读取数据的压力。

1. 一个 Master 可以有多个该服务器的从服务器
2. Master 会一直将自己的数据同步更新到 Slaves 上保持主从同步
3. 只有 Master 可以执行写命令，而 Slaves 只能执行读的命令

下面来演示 Redis 的主从复制功能：

1. 首先我们启动一个 Redis 服务器，使用默认端口6379

2. 接下来我们启动一个Redis服务器在启动时就指定其 Master （也可以启动后再手动指定） ./redis-server --port 6380 --slaveof 127.0.0.1 6379

可以看到从服务器已经连接到了主服务器，接下来我们使用客户端连接主服务器写入几个值

然后我们连接从服务器去看看

我们可以看到虽然我们没有在从服务器上面写入数据，但是从服务器已经自动的从主服务器上面复制了数据下来 ，我们再尝试在从服务器上面写入数据。

可以看到此时该服务器上是不允许写入数据的。

##主从复制的问题以及哨兵模式的引入 上面我们是通过手动去指定主从服务器的，而且只有主服务器是才可以写入数据，这里有个问题如果主服务器挂了，例如断电了，服务器崩了，那么这个集群也就挂了，所以我们需要一个可以在主服务器挂了的时候有一个机制可以自动的维护这个集群，所以这里 Redis 提供了一个哨兵的机制来保证集群的正常使用。

哨兵 Sentinel的作用是：

1. 当主服务器挂了的时候，Sentinel 将会从从服务器中选一个自动提升其为主服务器
2. 在步骤1后将其他的从服务器设置为新的主服务器的从服务器
3. 主服务器重新上线后，哨兵会使其变为一个从服务器。
4. Sentinel 的默认端口是26379

当然 Sentinel 也有一个问题，如果 sentinel 本身挂掉的话，那么这个监管机制就没了，所以，在一般情况下，我们可以创建多个 Sentinel 进程来同时监管一个 Master 服务器，这些 Sentinel 之间是可以通信的，他们会交换彼此的监控信息，通过投票的机制来确认主服务器是否现在是属于崩溃状态，同时利用投票机制来从从服务器中选取新的主服务器。这样也算是保证了 Sentinel 的监管有效性，所以一般哨兵的数量都会是奇数的情况。

下面演示一下这个过程

1. 首先启动一个主服务器以及两个从服务器

启动一个主服务器

启动两个从服务器

搭建Sentinel 创建sentinel.conf文件

这里 Sentinel 的配置信息格式如下 Sentinel monitor <sentinelname> <监视的主机地址> <主机地址的端口号> <quorum> 这里解释一下这个 quorum 根据翻译该单词的意思为 法定人数，该意思为监视你主服务器的 Sentinel 投票时当有 quorum指定的票数通过时即为通过，这里为了简单演示我设置了一个 Sentinel 因此 quorum我这里设置为 1 。

启动Sentinel

这里我们可看到Sentinel已经自动发现其监视的主服务器下面的从服务器 6380 和6381

然后我们去停掉6379主服务器

这时我们去查看Sentinel的日志，我们可以看到Sentinel检测到主服务器已经挂掉了，同时给自己投一票确认状态同时提升从服务器6380为新的主服务器

我们使用客户端去6380的服务器上看一下，我们可以看到此时是可以写数据的。

再去6381的服务器上看一下，此时我们发现他还是一个从服务器

##最后总结一下 Redis 的主从复制解决了数据的读写分离的问题，使业务的读的请求分发到众多的从服务器中去，同时也保证了数据的一致性。哨兵机制则保证了集群的高可用性。

但是主从复制+哨兵机制还有一个问题没有解决，那就是写的请求仍然在主服务器上，因此，如果业务上写数据的请求比较频繁的话，那么主从复置+哨兵机制仍然没有解决问题，这里我们就需要 Redis 自带的原生集群模式了，这个下一篇讨论。