数据库
首页 > 数据库> > Redis的这些拓展方案,用过一条的就是大牛!

Redis的这些拓展方案,用过一条的就是大牛!

作者:互联网

前言

Redis大家都不陌生,就算是没用过,也都听说过了。

作为最广泛使用的KV内存数据库之一,在当今的大流量时代,单机模式略显单薄,免不了要有一些拓展的方案。

笔者下文会对各种方案进行介绍,并且给出场景实现 等等概述,还会提到一些新手常见的误区。

正文

先从基础的拓展方式开始,这样更便于理解较高级的模式。

ps: 本文背景是以笔者落笔时官网最新稳定版5.0.8为准,虽然还没写完就变成了6.0.1。

分区

> 概述

分区(Partitioning)是一种最为简单的拓展方式。

在我们面临单机存储空间瓶颈时,第一点就能想到像传统的关系型数据库一样,进行数据分区。

或者假设手中有N台机器可以作为Redis服务器,所有机器内存总和有256G, 而客户端正好也需要一个大内存的存储空间。

我们除了可以把内存条都拆下来焊到一个机器上,也可以选择分区使用,这样又拓展了计算能力。

单指分区来讲,即将全部数据分散在多个Redis实例中,每个实例不需要关联,可以是完全独立的。

> 使用方式

> 缺点

同为开发者,深知我们虽然总能“曲线救国”的完成一些当前环境不支持的功能,但是总归要麻烦一些。

主从

> 概述数据迁移

常说的主从(Master-Slave),也就是复制(Replication)方式,怎么称呼都可以。

同上面的分区一样,也是Redis高可用架构的基础,新手可能会误以为这类基础模式即是“高可用”,这并不是十分正确的。

分区暂时能解决单点无法容纳的数据量问题,但是一个Key还是只在一个实例上,在大流量时代显得不那么可靠。

主从就是另一个纬度的拓展,节点将数据同步到节点,就像将实例“分身”了一样,可靠性又提高了不少。

 

 

图画的有些夸张了,主要还是想体现结构灵活,是一主一从,还是一主多从,还是一主多从多从... 看你心情

有了“实例分身”,自然就可以做读写分离,将读流量均摊在各个从节点。

> 使用方式

 

高手云集的时代,聊天软件难免要备上这么一张表情包。

这表情包和使用方式有什么关系呢?首先看看使用方式:

  1. 作为主节点的Redis实例,并不要求配置任何参数,只需要正常启动
  2. 作为从节点的实例,使用配置文件或命令方式REPLICAOF 主节点Host 主节点port即可完成主从配置

是不是和表情包一样,“dalao”没动,我去“抱大腿”。

这样一个主从最小配置就完成了,主从实例即可对外提供服务。

命令里的“主节点”是相对的,slave也可以抱slave大腿,也就是上文提到的结构灵活

> 缺点

哨兵

> 概述

主从的手工故障转移,肯定让人很难接受,QQ购买平台自然就出现了高可用方案-哨兵(Sentinel)。我们可以在主从架构不变的场景,直接加入Redis Sentinel,对节点进行监控,来完成自动的故障发现转移。并且还能够充当配置提供者,提供主节点的信息,就算发生了故障转移,也能提供正确的地址。哨兵本身也是Redis实例的一种,但不作为数据存储方使用,启动命令也是不一样的。

虽然图有些复杂,看起来像要召唤光能使者。

其实实际使用起来是很便捷的。

> 使用方式

Sentinel的最小配置,一行即可:

1sentinel monitor <主节点别名> <主节点host> <主节点端口> <票数>
只需要配置master即可,然后用redis-sentinel <配置文件> 命令即可启用。

Redis官网提到的“最小配置”是如下所示,除了上面提到的一行,还有其它的一些配置:

1sentinel monitor mymaster 127.0.0.1 6379 2
2sentinel down-after-milliseconds mymaster 60000
3sentinel failover-timeout mymaster 180000
4sentinel parallel-syncs mymaster 1
5
6sentinel monitor resque 192.168.1.3 6380 4
7sentinel down-after-milliseconds resque 10000
8sentinel failover-timeout resque 180000
9sentinel parallel-syncs resque 5

这是因为官网加了一个修饰词,是“典型的最小配置”,把重要参数和多主的例子都写出来了,照顾大家CV大法的时候,不要忘记重要参数,其实都是有默认值的。

正如该例所示,设置主节点别名就是为了监控多主的时候,与其额外配置项能够与其对应, 以及sentinel一些命令,如SENTINEL get-master-addr-by-name就要用到别名了。哨兵数量建议在三个以上且为奇数,在Redis官网也提到了各种情况的“布阵”方式,非常值得参考。

> 更多

既然是高可用方案,并非有严格意义上的“缺点”,还需配合使用场景进行考量。

      不过最后这点也是笔者猜测,并没有听说过出现这种案例,可不必深究。

集群

> 概述

Redis Cluster是官方在3.0版本后推出的分布式方案。

对开发者而言,“官方支持”一词是大概率非常美好的,小到issue,大到feature。自定义去解决问题,成本总是要高一些。

有了官方的正式集群方案,从请求路由、故障转移、弹性伸缩几个纬度的使用上,将更为容易。

Cluster不同于哨兵,是支持分区的。有说法Cluster是哨兵的升级,这是不严谨的。

二者纬度不一样,如果因为Cluster也有故障转移的功能,就说它是哨兵的升级款,略显牵强。

Cluster在分区管理上,使用了“哈希槽”(hash slot)这么一个概念,一共有16384个槽位,每个实例负责一部分,通过CRC16(key)&16383这样的公式,计算出来key所对应的槽位。

 

虽然在节点key二者中又引入了的概念,看起来不易理解,实际上因为颗粒度更细了,减少了节点的扩容和收缩难度,相比传统策略还是很有优势。

当然,“槽”是虚拟的概念,节点自身去维护“槽”的关系,并不是要真正下载启动个“槽服务”在跑。

> 使用方式

Redis的各种玩法,都是从配置文件着手,集群也不例外。

1cluster-enabled yes
2cluster-config-file "redis-node.conf"
关键配置简洁明了,有两步

集群配置文件(cluster-config-file)为内部使用,可以不去指定,Redis会帮助创建一个。启动还是普通的方式redis-server redis.conf

首先以集群方式启动了N台Redis实例,这当然还没完事。

接下来的步骤笔者称为“牵线搭桥分配槽”,听起来还算顺口。

“牵线搭桥分配槽”的方式也在不断升级,从直接用原始命令来处理,到使用脚本,以及现在的Redis-cli官方支持,使用哪种方式都可以。

1redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \
2127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
3--cluster-replicas 1
上方的命令即是Redis官网给出的redis-cli的方式用法,一行命令完成“三主三从”以及自动分配槽的操作。

这样集群就搭建完成了,当然,使用官方提供的check命令检查一下,也是有必要的。

1redis-cli --cluster check 127.0.0.1:7001
> 更多

结尾

趣谈

在写“主从”方案的时候,发现有一个有趣的事情:

笔者开始是记得主从的关键命令是SLAVEOF,后来查阅官方的时候,发现命令已经更改为REPLICAOF,虽然SLAVEOF还能用。

官网的一些描述词汇,有的地方还是Slave,也有些是用Replication。

好奇的笔者查了一下相关的资料,并看了些Redis作者antirez的有关此时博客,发现已经是两年前的事情了。

其实就是“Slave”这个变量名给了一些人机会,借此“喷”了一波作者,作者也做出了一部分妥协。

有兴趣的盆友可以自己搜搜看,技术外的东西就不做评价了,看个乐呵就行。

笔者的主要目的还是:看官方文档的时候,别让不同的“词汇”迷惑了。

END

本文对Redis这些拓展方案都作出了大致描述。

具体使用上,还需留意详细配置,以及客户端支持等综合情况来考量。

标签:Redis,分区,大牛,主从,实例,使用,节点,用过
来源: https://www.cnblogs.com/ludongguoa/p/15267029.html