Redis几种集群模式

Peter20 等级 541 0 0

此文由转载 https://blog.csdn.net/wy0123/article/details/79583506

现在越来越多的项目都会利用到redis,多实例redis服务比单实例要复杂的多,这里面涉及到定位、容错、扩容等技术问题。我们常用sharding技术来对此进行管理,其集群模式主要有以下几种方式:

主从复制
哨兵模式
Redis官方 Cluster集群模式(服务端sharding)
Jedis sharding集群(客户端sharding)
利用中间件代理
我们现看看主从复制、和哨兵模式,这是其它集群的基础配置.

主从复制(Master-Slave Replication)
实现主从复制(Master-Slave Replication)的工作原理:Slave从节点服务启动并连接到Master之后,它将主动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后台存盘进程,同时收集所有接收到的用于修改数据集的命令,在后台进程执行完毕后,Master将传送整个数据库文件到Slave,以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后,Master主节点继续将所有已经收集到的修改命令,和新的修改命令依次传送给Slaves,Slave将在本次执行这些数据修改命令,从而达到最终的数据同步。

如果Master和Slave之间的链接出现断连现象,Slave可以自动重连Master,但是在连接成功之后,一次完全同步将被自动执行。

主从复制配置
修改从节点的配置文件:slaveof masterip masterport
如果设置了密码,就要设置:masterauth master-password
主从模式的优缺点
优点:

同一个Master可以同步多个Slaves。
Slave同样可以接受其它Slaves的连接和同步请求,这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。
Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间,客户端仍然可以提交查询或修改请求。
Slave Server同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis则返回同步之前的数据
为了分载Master的读操作压力,Slave服务器可以为客户端提供只读操作的服务,写服务仍然必须由Master来完成。即便如此,系统的伸缩性还是得到了很大的提高。
Master可以将数据保存操作交给Slaves完成,从而避免了在Master中要有独立的进程来完成此操作。
支持主从复制,主机会自动将数据同步到从机,可以进行读写分离。
缺点:

Redis不具备自动容错和恢复功能,主机从机的宕机都会导致前端部分读写请求失败,需要等待机器重启或者手动切换前端的IP才能恢复。
主机宕机,宕机前有部分数据未能及时同步到从机,切换IP后还会引入数据不一致的问题,降低了系统的可用性。
Redis的主从复制采用全量复制,复制过程中主机会fork出一个子进程对内存做一份快照,并将子进程的内存快照保存为文件发送给从机,这一过程需要确保主机有足够多的空余内存。若快照文件较大,对集群的服务能力会产生较大的影响,而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行,也就是网络波动都会造成主机和从机间的一次全量的数据复制,这对实际的系统运营造成了不小的麻烦。
Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题,运维人员在系统上线时必须确保有足够的空间,这对资源造成了很大的浪费。
其实redis的主从模式很简单,在实际的生产环境中是很少使用的,我也不建议在实际的生产环境中使用主从模式来提供系统的高可用性,之所以不建议使用都是由它的缺点造成的,在数据量非常大的情况,或者对系统的高可用性要求很高的情况下,主从模式也是不稳定的。

哨兵模式
该模式是从Redis的2.6版本开始提供的,但是当时这个版本的模式是不稳定的,直到Redis的2.8版本以后,这个哨兵模式才稳定下来,无论是主从模式,还是哨兵模式,这两个模式都有一个问题,不能水平扩容,并且这两个模式的高可用特性都会受到Master主节点内存的限制。

Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态,在Master主服务器发生故障的时候,可以实现Master和Slave服务器的切换,保证系统的高可用。

Sentinel(哨兵)进程的作用
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时,哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master;当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后,Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变,即,Master主服务器的redis.conf配置文件中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换。
Sentinel(哨兵)进程的工作方式
每个Sentinel(哨兵)进程以每秒钟一次的频率向整个集群中的Master主服务器,Slave从服务器以及其他Sentinel(哨兵)进程发送一个 PING 命令。
如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel(哨兵)进程标记为主观下线(SDOWN)
如果一个Master主服务器被标记为主观下线(SDOWN),则正在监视这个Master主服务器的所有 Sentinel(哨兵)进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
当有足够数量的 Sentinel(哨兵)进程(大于等于配置文件指定的值)在指定的时间范围内确认Master主服务器进入了主观下线状态(SDOWN), 则Master主服务器会被标记为客观下线(ODOWN)
在一般情况下, 每个 Sentinel(哨兵)进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
当Master主服务器被 Sentinel(哨兵)进程标记为客观下线(ODOWN)时,Sentinel(哨兵)进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
若没有足够数量的 Sentinel(哨兵)进程同意 Master主服务器下线, Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel(哨兵)进程发送 PING 命令返回有效回复,Master主服务器的主观下线状态就会被移除。
哨兵模式的优缺点
优点:

哨兵集群模式是基于主从模式的,所有主从的优点,哨兵模式同样具有。
主从可以切换,故障可以转移,系统可用性更好。
哨兵模式是主从模式的升级,系统更健壮,可用性更高。
缺点:

Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题,运维人员在系统上线时必须确保有足够的空间,这对资源造成了很大的浪费。
配置复杂
Redis官方 Cluster集群模式
Redis Cluster是一种服务器Sharding技术,3.0版本开始正式提供。
这里写图片描述
Redis几种集群模式
在这个图中,每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接,然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。

Redis集群数据分片
在redis的每一个节点上,都有这么两个东西,一个是插槽(slot)可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是:0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候,redis会根据crc16的算法得出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取操作。
Redis几种集群模式

还有就是因为如果集群的话,是有好多个redis一起工作的,那么,就需要这个集群不是那么容易挂掉,所以呢,理论上就应该给集群中的每个节点至少一个备用的redis服务。这个备用的redis称为从节点(slave)。那么这个集群是如何判断是否有某个节点挂掉了呢?

首先要说的是,每一个节点都存有这个集群所有主节点以及从节点的信息。

它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应,集群就认为这个节点宕机了,然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉,我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机,那么我们集群同样进入发力了状态。这就是我们的redis的投票机制,具体原理如下图所示:
Redis几种集群模式

投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉.
什么时候整个集群不可用(cluster_state:fail)?
如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
Redis 3.0的集群方案有以下两个问题。
一个Redis实例具备了“数据存储”和“路由重定向”,完全去中心化的设计。这带来的好处是部署非常简单,直接部署Redis就行,不像Codis有那么多的组件和依赖。但带来的问题是很难对业务进行无痛的升级,如果哪天Redis集群出了什么严重的Bug,就只能回滚整个Redis集群。
对协议进行了较大的修改,对应的Redis客户端也需要升级。升级Redis客户端后谁能确保没有Bug?而且对于线上已经大规模运行的业务,升级代码中的Redis客户端也是一个很麻烦的事情。
Redis Cluster是Redis 3.0以后才正式推出,时间较晚,目前能证明在大规模生产环境下成功的案例还不是很多,需要时间检验。

Jedis sharding集群
Redis Sharding可以说是在Redis cluster出来之前业界普遍的采用方式,其主要思想是采用hash算法将存储数据的key进行hash散列,这样特定的key会被定为到特定的节点上。

Redis几种集群模式

庆幸的是,Java Redis客户端驱动Jedis已支持Redis Sharding功能,即ShardedJedis以及结合缓存池的ShardedJedisPool

Jedis的Redis Sharding实现具有如下特点:

采用一致性哈希算法,将key和节点name同时hashing,然后进行映射匹配,采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时,不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配,影响量小。
为了避免一致性哈希只影响相邻节点造成节点分配压力,ShardedJedis会对每个Redis节点根据名字(没有,Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight,也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配,可以在增加或减少Redis节点时,key在各Redis节点移动再分配更均匀,而不是只有相邻节点受影响。
ShardedJedis支持keyTagPattern模式,即抽取key的一部分keyTag做sharding,这样通过合理命名key,可以将一组相关联的key放入同一个Redis节点,这在避免跨节点访问相关数据时很重要。
当然,Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容,当想要增加Redis节点时,尽管采用一致性哈希,毕竟还是会有key匹配不到而丢失,这时需要键值迁移。
作为轻量级客户端sharding,处理Redis键值迁移是不现实的,这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候,击穿缓存层,直接访问数据库层,会对系统访问造成很大压力。

利用中间件代理
中间件的作用是将我们需要存入redis中的数据的key通过一套算法计算得出一个值。然后根据这个值找到对应的redis节点,将这些数据存在这个redis的节点中。

常用的中间件有这几种

Twemproxy
Codis
nginx
具体用法就不赘述了,可以自行百度。

总结
客户端分片(sharding)需要客户端维护分片算法,这是一种静态的分片方案,需要增加或者减少Redis实例的数量,需要手工调整分片的程序。
利用中间件的情况则会影响到redis的性能,具体看中间件而定,毕竟所有请求都要经过中间件一层过滤
官方提供方案,现时点成功案例不多。

本文转自 https://blog.csdn.net/qq_35152037/article/details/84583573,如有侵权,请联系删除。

收藏
评论区

相关推荐

Redis集群详解
Redis集群详解Redis有三种集群模式,分别是: 主从模式 Sentinel模式 Cluster模式 三种集群模式各有特点,关于Redis介绍可以参考这里:Redis官网:https://redis.io/ ,最新版本5.0.4 主从模式 主从模式介绍主从模式是三种模式中最简单的,在主从复制中,数据库分为两类:主数据库(master)和从数据库(sl
JAVA通过Gearman实现MySQL到Redis的数据同步(异步复制)
MySQL到Redis数据复制方案 ----------------- 无论MySQL还是Redis,自身都带有数据同步的机制,像比较常用的 MySQL的Master/Slave模式 ,就是由Slave端分析Master的binlog来实现的,这样的数据复制其实还是一个异步过程,只不过当服务器都在同一内网时,异步的延迟几乎可以忽略。 那么理论上我们也可以
MySQL与Redis实现二级缓存
redis简介 ------- * Redis 是完全开源免费的,遵守BSD协议,是一个高性能的key-value数据库 * Redis 与其他 key - value 缓存产品有以下三个特点: * Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用 * Redis不仅仅支持简单的ke
ubuntu 安装 redis集群
计划部署三个虚拟机 三个master节点 三个slave节点: IP:192.168.26.133   port:7133(master)   port:8133(slave) IP:192.168.26.134   port:7134(master)   port:8134(slave) IP:192.168.26.135 port:7135(mas
NoSQL数据库Redis和MongoDB
redis简介 ------- 一些特点: * Redis的读写性能极高,并且有丰富的特性(发布/订阅、事务、通知等)。 * Redis支持数据的持久化(RDB和AOF两种方式),可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。 * Redis支持多种数据类型,包括:string、hash、list、set,zset、bitm
Redis Cluster集群
**一、环境说明** 服务器IP地址 服务器版本 Redis版本 Redis-master Redis-slave 10.10.18.10 centos7.5 5.0 6379 6380 10.10.18.11 centos7.5 5.0 6379 6380 10.10.18.12 centos7.5 5.0 6379
Redis Master
1 master/slave server 启动 =========================== 利用默认redis.conf配置文件启动master server,端口6379 。 ------------------------------------------ \[7304\] 29 Aug 09:57:26 - 0 clients
Redis sentinel.conf配置文件详解
redis-sentinel.conf配置项说明如下: --------------------------- 1.port 26379 sentinel监听端口,默认是26379,可以修改。 2.sentinel monitor <master-name> <ip> <redis-port> <quorum> 告诉sentinel去监听地址为ip:
Redis 集群演进探讨和总结
Redis为什么需要集群? 首先Redis单实例主要有单点,容量有限,流量压力上限的问题。 Redis单点故障,可以通过主从复制`replication`,和自动故障转移`sentinel`哨兵机制。 但Redis单`Master`实例提供读写服务,仍然有容量和压力问题,因此需要数据分区,构建多个`Master`实例同时提供读写服务(不仅限于从`rep
Redis3.0.6集群搭建
创建一个RedisCluster之前,我们需要有一些以cluster模式运行的Redis实例,这是因为cluster模式下Redis实例将会开启cluster的特征和命令。 现在我有2台Vbox搭建的CentOS6虚拟机【CentOS1(192.168.56.101)和CentOS2(192.168.56.102)】,准备在此上搭建Redis集群。 由于
Redis主从、哨兵
**之前安装了redis,但是单节点redis不可靠,现在搭建redis主从,提高可用性。** **一、搭建一主二从**   redis主从其实是读写分离,主节点写数据,从节点读数据。   1、准备三台redis机器。redis的密码需要一致,否则主从切换时会有问题。   2、选择两台,作为从机,编辑redis核心配置文件。 vim /us
Redis主从模式的常用类型
本文介绍Redis主从模式的常用类型。 Redis的可靠性主要有主从模式和集群模式。对于主从模式而言,Redis有以下方案: * Sentinel方案; * Keepalived方案。 Sentinel方案 ---------- 作为Redis主推的官方方案,主要的实现原理是通过引入哨兵sentinel节点,来投标决定master节点故障后,
Redis哨兵
Redis-Sentinel是redis官方推荐的高可用性解决方案, 当用redis作master-slave的高可用时,如果master本身宕机,redis本身或者客户端都没有实现主从切换的功能。 而redis-sentinel就是一个独立运行的进程,用于监控多个master-slave集群, 自动发现master
Redis简介
**Redis简介** Redis是完全开源免费的,遵守BSD协议,是一个高性能的key-value数据库 Redis与其他key-value缓存产品有以下三个特点: ◆Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载使用。 ◆Redis不仅仅支持简单的key-value类型的数据,同时还提供list,set,z
Redis集群策略之我见
集群的价值在于高可用,在于负载均衡,那么对Redis来说如何做到这一点呢?我想到一种方案。 由于Redis的同步机制是 master / slave 方式,而且 slave 还可以有 slave,那么就可以方便的实现链式结构。什么是链式结构?如下: **master -> slave -> slave -> slave ... ...**