Redis集群方案怎么做?大牛给你介绍五种方案!

Redis集群方案

Redis数据量日益增大,而且使用的公司越来越多,不仅用于做缓存,同时趋向于存储这块,这样必促使集群的发展,各个公司也在收集适合自己的集群方案,目前行业用的比较多的是下面几种集群架构,大部分都是采用分片技术,解决单实例内存增大带来的一系列问题。

本篇文章简单介绍五种方案:

官方cluster方案

twemproxy代理方案

哨兵模式

codis

客户端分片

官方cluser方案

从redis 3.0版本开始支持redis-cluster集群,redis-cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他节点连接。redis-cluster是一种服务端分片技术。

redis-cluster架构图

redis-cluster特点:

每个节点都和n-1个节点通信,这被称为集群总线(cluster bus)。它们使用特殊的端口号,即对外服务端口号加10000。所以要维护好这个集群的每个节点信息,不然会导致整个集群不可用,其内部采用特殊的二进制协议优化传输速度和带宽。

redis-cluster把所有的物理节点映射到[0,16383]slot(槽)上,cluster负责维护node--slot--value。

集群预分好16384个桶,当需要在redis集群中插入数据时,根据CRC16(KEY) mod 16384的值,决定将一个key放到哪个桶中。

客户端与redis节点直连,不需要连接集群所有的节点,连接集群中任何一个可用节点即可。

redis-trib.rb脚本(rub语言)为集群的管理工具,比如自动添加节点,规划槽位,迁移数据等一系列操作。

节点的fail是通过集群中超过半数的节点检测失效时才生效。

整个cluster被看做是一个整体,客户端可连接任意一个节点进行操作,当客户端操作的key没有分配在该节点上时,redis会返回转向指令,指向正确的节点。

为了增加集群的可访问性,官方推荐的方案是将node配置成主从结构,即一个master主节点,挂n个slave从节点。如果主节点失效,redis cluster会根据选举算法从slave节点中选择一个上升为master节点,整个集群继续对外提供服务。

twemproxy代理方案

twemproxy代理架构图:

Redis代理中间件twemproxy是一种利用中间件做分片的技术。twemproxy处于客户端和服务器的中间,将客户端发来的请求,进行一定的处理后(sharding),再转发给后端真正的redis服务器。也就是说,客户端不直接访问redis服务器,而是通过twemproxy代理中间件间接访问。降低了客户端直连后端服务器的连接数量,并且支持服务器集群水平扩展。

twemproxy中间件的内部处理是无状态的,它本身可以很轻松地集群,这样可以避免单点压力或故障。

twemproxy又称nutcracker,起源于推特系统中redis、memcached集群的轻量级代理。

Github源码地址(https://github.com/twitter/twemproxy)

从上面架构图看到twemproxy是一个单点,很容易对其造成很大的压力,所以通常会结合keepalived来实现twemproy的高可用。这时,通常只有一台twemproxy在工作,另外一台处于备机,当一台挂掉以后,vip自动漂移,备机接替工作。关于keepalived的用法可自行网上查阅资料。

哨兵模式

Sentinel哨兵

Sentinel(哨兵)是Redis的高可用性解决方案:由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器以及这些主服务器下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器。

例如:

在Server1掉线后:

升级Server2为新的主服务器:

Sentinel的工作方式

每个Sentinel以每秒钟一次的频率向它所知的Master、Slave以及其他Sentinel实例发送一个PING命令。

如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值,则这个实例会被Sentinel标记为主观下线。

如果一个Master被标记为主观下线,则正在监视这个Master的所有Sentinel要以每秒一次的频率确认Master的确进入了主观下线状态。

当有足够数量的Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态,则Master会被标记为客观下线。

在一般情况下,每个Sentinel会以每10秒一次的频率向它所知的所有Master、Slave发送INFO命令。

当Master被Sentinel标记为客观下线时,Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次。

若没有足够数量的Sentinel同意Master已经下线,Master的客观下线状态就会被移除。若Master重新向Sentinel的PING命令返回有效值,Master的主观下线状态就会被移除。

codis

codis是一个分布式的Redis解决方案,由豌豆荚开源,对于上层的应用来说,连接codis proxy和连接原生的redis server没什么明显的区别,上层应用可以像使用单机的redis一样使用,codis底层会处理请求的转发,不停机的数据迁移等工作,所有后边的事情,对于前面的客户端来说是透明的,可以简单的认为后边连接的是一个内存无限大的redis服务。

客户端分片

分区的逻辑在客户端实现,由客户端自己选择请求到哪个节点。方案可参考一致性哈希,这种方案通常适用于用户对客户端的行为有完全控制能力的场景。

总结:没有最好的方案,只有最合适的方案。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏性能与架构

查看操作系统负载

当我们系统有问题的时候,不要急于去调查我们代码 首先要看的是操作系统的报告,看看操作系统的CPU利用率,看看内存使用率,看看操作系统的IO,还有网络的IO,网络...

3406
来自专栏hadoop学习

标题:DKhadoop大数据处理平台监控数据介绍

2018年国内大数据公司50强榜单排名已经公布了出来,大快以黑马之姿闯入50强,并摘得多项桂冠。Hanlp自然语言处理技术也荣膺了“2018中国数据星技术”奖。...

622
来自专栏数据和云

深入剖析 Group Replication内核的引擎特性

小编寄语 主库master与从库slave的切换不管是主动的还是被动的都需要外部干预才能进行,这与数据库内核本身是按照单机来设计的理念悉悉相关,并且数据库系统本...

3708
来自专栏about云

Hadoop 2.x与3.x 22点比较:3.x将节省大量存储空间

1.Hadoop3.x通过什么方式来容错? 2.Hadoop3.x存储开销减少了多少? 3.Hadoop3.x MR API是否兼容hadoop1.x?

1162
来自专栏无题

软负载中心与集中配置管理

软负载中心两个最基础的职责 聚合地址信息 生命周期感知->需要能对服务的上下线自动感知,并且根据这个变化去更新服务地址数据 软负载中心两个最基础的职责 聚合...

2844
来自专栏IT技术精选文摘

分布式消息队列

一、消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系...

20010
来自专栏后端技术探索

大型网站架构系列:消息队列

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件...

621
来自专栏云原生架构实践

部署模式 - 每个主机一个服务实例

已经通过微服务架构的分解模式(参考按业务领域分解模式划分微服务),将整个应用程序划分为多个独立的微服务。

694
来自专栏Java学习网

大型网站架构系列:消息队列

大型网站架构系列:消息队列 一、消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最...

3349
来自专栏hadoop学习笔记

大快DKH大数据基础数据平台的监控参数说明

2018年国内大数据公司50强榜单排名已经公布了出来,大快以黑马之姿闯入50强,并摘得多项桂冠。Hanlp自然语言处理技术也荣膺了“2018中国数据星技术”奖。...

1022

扫码关注云+社区