redis 链式、晋升、哨兵模式

和普通的主从结构有什么不同?为什么?怎么配置?

 

一、链式

1.为什么要使用链式?

我的理解:首先需要搞明白redis主从同步的原理,感谢:

http://blog.csdn.net/sk199048/article/details/50725369

如果使用一主多从的结构:

1

一旦有新的slave加入,就会产生全量同步。一旦有写入等操作,就会发生增量同步。因为所有slave的同步都由master进行处理,只要slave的数量一多,将极大地加重master的负担。所以上次那种一主多从的结构是不太适合生产环境的。

所以,提出了一种链式的解决方法。链式结构中的master和slave是相对而言的。

1

slave1是slave2的master,slave1同步master之后,slave2会继续同步slave1。这样串联起来,可以减轻master的压力。但是完全的链式结构也会产生问题,每次同步都有相应的操作,需要时间。那么多个slave就会放大这个时间,产生延迟。

所以同时也需要一些并联,产生了级联结构,差不多类似这样:

1

到这里好像有些跑题了…

2.如何配置

和之前配制方法是一样的,只是结构要注意。举个例子:

三个配置文件,一个master:6379,一个slave1:6380,一个slave2:6381。

(1)将slave1设为master的从库

(2)将slave2设为slave1的从库

之后redis-cli链接一下6380,就会发现slave1既是master的从库,也是slave2的master。

3.如果master挂掉了

如果把master:6379给shutdown掉,那么slave1:6380的master_link_status就会变成down,等待master重新上线。期间可以正常查询,但是无法插入了。

如果master:6379重新上线,那么slave1:6380的master_link_status恢复为up,可以继续正常工作。

二、晋升

1.为什么要使用晋升?

我的理解:晋升是一种容灾机制。

普通的redis主从,master挂掉之后,整个服务就挂掉了,必须等master上线,才能重新建立主从。但是很多情况下,服务是不能挂的,能不能有这样一种方法,master一挂掉,立马让一个slave顶替上去呢?这个就是晋升。

但是,晋升是需要人工手动进行晋升的。

2.如何配置

晋升的slave需要使用命令slaveof no one和salveof,在配置文件中是无法配置的。需要人工进行晋升。

举个例子:

三个配置文件,一个master:6379,一个slave1:6380,一个slave2:6381。

(1)手工晋升salve1

将slaveof设置为没有任何从库(即设为master)

(2)手工重新设置slave(这里是slave2)

3.如果master重新上线了

那么之前的master(master:6379)将是一个独立的服务,本身作为一个master,而且没有任何slave。

三、哨兵模式

1.为什么使用哨兵模式

我的理解:从上面的晋升可以看出,万一master挂掉了,那么就需要手工晋升slave,保障服务继续运行。

但是这样就会有一些问题:如何在master挂掉的第一时间马上恢复redis服务。人工晋升工作量可能会比较大,耗时会比较长。在生产环境中,redis往往有自检,重启之后需要第一时间回到集群中,人工晋升如何保障这一点?

所以就有这样的需求:当master挂掉之后,需要马上选出一个slave作为新的master,保障服务继续运行。当之前挂掉的master重启后,需要第一时间变成当前master的slave。

所以需要使用哨兵模式。

2.如何配置

(1)新建一个sentinel.conf文件

不知道为什么,我这里已经有现成的sentinel.conf文件了。如果没有,就要新建一个,然后配置:

(2)启动哨兵服务

执行命令:

这里并没有启动master的redis-server,等下需要手动启动。

3.如果master挂掉了

哨兵将自动检测到master挂掉的事件,然后进行一次选举,选出master的其中一个slave作为新的master,继续服务。

如果之前的master重启了,那么哨兵将自动检测到重启的事件,然后把之前的master作为现在的master的一个slave,加入到服务中。

四、总结

似乎基本上采用的都是哨兵模式。需要好好理解为什么。下次尝试使用redis实现一下消息队列/使用redis集群。

发表评论

电子邮件地址不会被公开。 必填项已用*标注