这里简单说一下redis的sentinel(哨兵)和Twemproxy !
一.sentinel
要谈哨兵,必定要谈到主从复制(master-slave),
当没有主从复制时,大量的请求会加重服务器的负担(如下图)
为了降低对主服务器的读压力,做几个主服务器的复制品,部分请求就会被分担到从服务器,从而降低对主服务器的读压力(如下图)
这样是不是很机智? 但是也存在问题,当主服务器宕机或者下线了,所有请求不就得延迟了?直到等人工来重启服务器,在现在的社会,这种延迟是不可容忍的,所以需要系统自动处理这件事情.
这就是哨兵所做的事情.
其实哨兵不是重启主服务器,而是将从服务器提升为主服务器,集群几乎不会受到影响(如下图),一个哨兵也可以,下面是一个哨兵网络
宕机的s1的被重新启动后只会变成从服务器,不会变成主服务器,此时的主服务器仍是s2(如下图)
主从解决了服务器的读压力,哨兵解决了服务器宕机的问题,还没有解决写的压力
二.Twemproxy
Twemproxy 就可以解决写压力,一个Twemproxy里面有多个服务池,每个服务池监管者一些redis服务器
所有的写请求先经过Twemproxy,再分配给各个服务器(如下图),下图只有一个Twemproxy,也可以有多个
这里说一下当请求的redis服务器无法写处理时 ,Twemproxy的处理(如下图)
注:
①.客户端向Twemproxy 正常请求,Twemproxy转向 服务器A写请求,
③.Twemproxy向服务器A请求异常,其他的正常.
②.多次(次数可以设定)请求服务器A失败.请求会被其他正常的服务器接受处理
④.服务器A重启后,能正常继续处理写请求,
总结:
1.哨兵解决了读压力中的主服务器宕机问题:
2.Twemproxy解决了写压力的服务器宕机问题
