redis@IT·互联网程序员

利用redis-sentinel实现redis主从高可用设计

2017-08-28  本文已影响111人  狼笔头

redis最简单的使用方式就是启动一个redis实例,然后客户端直接连到这个redis实例进行操作,很多业务场景单个redis实例便可以满足内存及请求的需求。然而在实际应用当中,尤其是在线上环境中,可用性非常重要,显然单一的redis实例可用性就很难保证,无论是进程挂了还是机器挂了等等各种原因很容易就会导致单一redis实例不可用。为了提供高可用的能力,redis本身提供了redis-sentinel服务。

redis-sentinel工作方式

详细的redis-sentinel内容可以参考官网的文档sentinel。在这里我们简单的介绍一下:

+--------+                   +--------+
| Master |---------+---------| Slave  |
+--------+         |         +--------+
                   |
      +------------+--------------+    
      |            |              |
+-----------+ +-----------+ +-----------+
| Sentinel1 | | Sentinel2 | | Sentinel3 |
+-----------+ +-----------+ +-----------+

每个Sentinel都会和Master、Slave以及其它Sentinel通讯,检测各实例的存活情况,如果发现Master实例挂掉了,则各Sentinel之间会协商根据规则选出一个Slave来变为Master。这样就使得redis服务可以继续使用。

从服务端来讲,redis-sentinel引入解决了单个redis实例挂掉之后不能提供服务的问题。但是对客户端来说由于redis-sentinel的引入,可能导致redis的主从切换,因此直接给客户端redis实例地址的话则可能因为主从的切换而导致redis地址不是预期的地址。为了完全的实现高可用我们还需要解决这个问题,那解决这个问题常见的就有以下三种方案:

客户端方案

在redis客户端中支持redis-sentinel,通过redis-sentinel来发现redis实例。

优点:

缺点:

LVS方案

采用LVS虚IP,在redis-sentinel发生主从切换后也执行虚IP漂移操作。

优点:

缺点:

代理方案

在客户端和redis服务端之间加一层代理,代理通过redis-sentinel来发现redis实例

优点:

缺点:

方案选择

在实际应用环境中,要选择一种高可用方案除了考虑高可用本身更应考虑以下几点:

因此综合的来看,选择代理方案是一种比较折衷稳妥的方案,原因主要如下:

那么选用代理方案的话,也需要正视它的缺点:

支持redis-sentinel的代理predixy

上一篇下一篇

猜你喜欢

热点阅读