Redis主从复制(二)
上篇文章和小伙伴们一起搭建了redis主从复制环境，但是还不完善，本文我想再和小伙伴们聊聊主从复制环境搭建的一些细节。
本文是Redis系列的第十一篇文章，了解前面的文章有助于更好的理解本文：
1.Linux上安装Redis
2.Redis中的五种数据类型简介
3.Redis字符串(STRING)介绍
4.Redis字符串(STRING)中BIT相关命令
5.Redis列表与集合
6.Redis散列与有序集合
7.Redis中的发布订阅和事务
8.Redis快照持久化
9.Redis之AOF持久化
10.Redis主从复制(一)
本文接上文，所用三个redis实例和上文一致，这里就不再赘述三个实例搭建方式。
一场接力赛
在上篇文章中，我们搭建的主从复制模式是下面这样的：
实际上，一主二仆的主从复制，我们可以搭建成下面这种结构：
搭建方式很简单，在前文基础上，我们只需要修改6381的master即可，在6381实例上执行如下命令，让6381从6380实例上复制数据，如下：
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
OK此时，我们再看6379的slave，如下：
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=0,lag=1
master_replid:4a38bbfa37586c29139b4ca1e04e8a9c88793651
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0只有一个slave，就是6380，我们再看6380的信息，如下：
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:70
slave_priority:100
slave_read_only:1
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=70,lag=0
master_replid:4a38bbfa37586c29139b4ca1e04e8a9c88793651
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:70
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:706380此时的角色是一个从机，它的主机是6379，但是6380自己也有一个从机，那就是6381.此时我们的主从结构如下图：
哨兵模式
结合上篇文章，我们一共介绍了两种主从模式了，但是这两种，不管是哪一种，都会存在这样一个问题，那就是当主机宕机时，就会发生群龙无首的情况，如果在主机宕机时，能够从从机中选出一个来充当主机，那么就不用我们每次去手动重启主机了，这就涉及到一个新的话题，那就是哨兵模式。
所谓的哨兵模式，其实并不复杂，我们还是在我们前面的基础上来搭建哨兵模式。假设现在我的master是6379，两个从机分别是6380和6381，两个从机都是从6379上复制数据。先按照上文的步骤，我们配置好一主二仆，然后在redis目录下打开sentinel.conf文件，做如下配置：
sentinel monitor mymaster 127.0.0.1 6379 1其中mymaster是给要监控的主机取的名字，随意取，后面是主机地址，最后面的2表示有多少个sentinel认为主机挂掉了，就进行切换（我这里只有一个，因此设置为1）。好了，配置完成后，输入如下命令启动哨兵：
redis-sentinel sentinel.conf然后启动我们的一主二仆架构，启动成功后，关闭master，观察哨兵窗口输出的日志，如下：
小伙伴们可以看到，6379挂掉之后，redis内部重新举行了选举，6380重新上位。此时，如果6379重启，也不再是扛把子了，只能屈身做一个slave了。
注意问题
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。因此我们还需要集群来进一步提升redis性能，这个问题我们将在后面说到。
OK,redis主从复制问题我们就介绍这么多，更多资料小伙伴们可以参考官方文档http://www.redis.net.cn/tutorial/3501.html。小伙伴在看官方文档时，有什么问题欢迎留言讨论。
更多资料请关注公众号：