您现在的位置:主页 > 科技 > 为什么不搞集群服务也能实现Redis高可用?
科技

为什么不搞集群服务也能实现Redis高可用?

字号+ 作者: 千百度自媒体 来源:dbaplus社群 2019-02-12 08:32 我要评论(0)    

为什么不搞集群服务也能实现Redis高可用?

为什么不搞集群服务也能实现Redis高可用?

基于内存的Redis应该是目前各种Web开发业务中最为常用的Key-Value数据库了。

我们经常在业务中用其存储用户登陆态(Session存储),加速一些热数据的查询(相比较MySQL而言,速度有数量级的提升),做简单的消息队列(LPUSH和BRPOP)、订阅发布(PUB/SUB)系统等等。规模比较大的互联网公司,一般都会有专门的团队,将Redis存储以基础服务的形式提供给各个业务调用。

不过任何一个基础服务的提供方,都会被调用方问起的一个问题是:你的服务是否具有高可用性?

最好不要因为你的服务经常出问题,导致我这边的业务跟着遭殃。最近我所在的项目中也自己搭了一套小型的“高可用”Redis服务,在此做一下自己的总结和思考。

一、可能出现的异常

首先我们要定义一下对于Redis服务来说怎样才算是高可用,即在各种出现异常的情况下,依然可以正常提供服务。或者宽松一些,出现异常的情况下,只经过很短暂的时间即可恢复正常服务。所谓异常,应该至少包含了以下几种可能性:

【异常1】某个节点服务器的某个进程突然down掉(例如某开发手残,把一台服务器的Redis-Server进程kill了)。

【异常2】某台节点服务器down掉,相当于这个节点上所有进程都停了(例如某运维手残,把一个服务器的电源拔了;例如一些老旧机器出现硬件故障)。

【异常3】任意两个节点服务器之间的通信中断了(例如某临时工手残,把用于两个机房通信的光缆挖断了)。

其实以上任意一种异常都是小概率事件。

而做到高可用性的基本指导思想就是:多个小概率事件同时发生的概率可以忽略不计。只要我们设计的系统可以容忍短时间内的单点故障,即可实现高可用性。

对于搭建高可用Redis服务,网上已有了很多方案,例如Keepalived、Codis、Twemproxy、Redis Sentinel。其中Codis和Twemproxy主要是用于大规模的Redis集群中,也是在Redis官方发布Redis Sentinel之前twitter和豌豆荚提供的开源解决方案。

我的业务中数据量并不大,所以搞集群服务反而是浪费机器了。最终在Keepalived和Redis Sentinel之间做了个选择,选择了官方的解决方案Redis Sentinel。

Redis Sentinel可以理解为一个监控Redis Server服务是否正常的进程,并且一旦检测到不正常,可以自动地将备份(slave)Redis Server启用,使得外部用户对Redis服务内部出现的异常无感知。我们按照由简至繁的步骤,搭建一个最小型的高可用的Redis服务。

二、探索参考方案

方案1:单机版Redis Server,无Sentinel

为什么不搞集群服务也能实现Redis高可用?

一般情况下,我们搭的个人网站,或者平时做开发时,会起一个单实例的Redis Server。调用方直接连接Redis服务即可,甚至Client和Redis本身就处于同一台服务器上。

这种搭配仅适合个人学习娱乐,毕竟这种配置总会有单点故障的问题无法解决。一旦Redis服务进程挂了,或者服务器1停机了,那么服务就不可用了。并且如果没有配置Redis数据持久化的话,Redis内部已经存储的数据也会丢失。

方案2:主从同步Redis Server,单实例Sentinel

为什么不搞集群服务也能实现Redis高可用?

为了实现高可用,解决方案1中所述的单点故障问题,我们必须增加一个备份服务,即在两台服务器上分别各启动一个Redis Server进程,一般情况下由master提供服务,slave只负责同步和备份。

与此同时,再额外启动一个Sentinel进程,监控两个Redis Server实例的可用性,以便在master挂掉的时候,及时把slave提升到master的角色继续提供服务,这样就实现了Redis Server的高可用。

这基于一个高可用服务设计的依据,即单点故障本身就是个小概率事件,而多个单点同时故障(即master和slave同时挂掉),可以认为是(基本)不可能发生的事件。

对于Redis服务的调用方来说,现在要连接的是Redis Sentinel服务,而不是Redis Server了。常见的调用过程是,Client先连接Redis Sentinel并询问目前Redis Server中哪个服务是master,哪些是slave,然后再去连接相应的Redis Server进行操作。

当然目前的第三方库一般都已经实现了这一调用过程,不再需要我们手动去实现(例如Nodejs的ioredis,PHP的predis,Golang的go-redis/redis,JAVA的jedis等)。

然而,我们实现了Redis Server服务的主从切换之后,又引入了一个新的问题,即Redis Sentinel本身也是个单点服务,一旦Sentinel进程挂了,那么客户端就没办法链接Sentinel了。所以说,方案2的配置并无法实现高可用性。

方案3:主从同步Redis Server,双实例Sentinel

为什么不搞集群服务也能实现Redis高可用?

为了解决方案2的问题,我们把Redis Sentinel进程也额外启动一份,两个Sentinel进程同时为客户端提供服务发现的功能。对于客户端来说,它可以连接任何一个Redis Sentinel服务,来获取当前Redis Server实例的基本信息。

通常情况下,我们会在Client端配置多个Redis Sentinel的链接地址,Client一旦发现某个地址连接不上,会去试图连接其他的Sentinel实例,这当然也不需要我们手动实现,各个开发语言中比较热门的Redis连接库都帮我们实现了这个功能。

我们预期是:即使其中一个Redis Sentinel挂掉了,还有另外一个Sentinel可以提供服务。

然而,愿景是美好的,现实却是很残酷的。如此架构下,依然无法实现Redis服务的高可用。

方案3示意图中,红线部分是两台服务器之间的通信,而我们所设想的异常场景(【异常2】)是,某台服务器整体down机,不妨假设服务器1停机,此时,只剩下服务器2上面的Redis Sentinel和slave Redis Server进程。

这时,Sentinel其实是不会将仅剩的slave切换成master继续服务的,也就导致Redis服务不可用,因为Redis的设定是只有当超过50%的Sentinel进程可以连通并投票选取新的master时,才会真正发生主从切换。本例中两个Sentinel只有一个可以连通,等于50%并不在可以主从切换的场景中。

你可能会问,为什么Redis要有这个50%的设定?

转载请注明出处: 自媒体新闻网 >> 《为什么不搞集群服务也能实现Redis高可用?》
当前文章链接地址:http://www.qbdzmt.com/keji/37073.html >>已有人阅读过此文章

  

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

相关文章
  • 为什么我不发朋友圈了?

    为什么我不发朋友圈了?

    2020-05-30 09:40

  • 年轻人为什么创业会失败?有哪四点?

    年轻人为什么创业会失败?有哪四点?

    2020-05-09 12:22

  • 为什么人年龄大了更容易不开心?

    为什么人年龄大了更容易不开心?

    2020-05-09 12:18

  • 为什么大多数创业公司熬不过三年?

    为什么大多数创业公司熬不过三年?

    2020-04-30 08:54

网友点评
你的评论可以一针见血! 如是广告,评论将无法显示,@博主微信/QQ:80747084
  • 全部评论(0
    还没有评论,快来抢沙发吧!
最新文章
  • 《幸福工厂》脱离Epic独占上架Steam 6月9日发售

    《幸福工厂》脱离Epic

  • 赫兹宣布破产 买便宜二手车的机会来了

    赫兹宣布破产 买便宜

  • 少儿编程发展趋势怎么样?现状如何?

    少儿编程发展趋势怎么

  • 何猷君悼念何鸿燊 配哭泣表情包

    何猷君悼念何鸿燊 配

  • 2020年卖头盔赚钱吗?要不要做这个生意?

    2020年卖头盔赚钱吗?

  • 为什么我不发朋友圈了?

    为什么我不发朋友圈了

  • 华纳音乐重启IPO 估值千亿

    华纳音乐重启IPO 估值

  • 5G到来有什么新的C创业商机?

    5G到来有什么新的C创

本文作者:千百度自媒体网
千百度自媒体网
千百度自媒体网给大家推荐最热门的搞笑幽默段子、实时新闻、娱乐新闻、创业、自媒体、科技、体育、游戏、社