首页 > 数据库 >Redis集群模式

Redis集群模式

时间:2024-07-14 14:54:29浏览次数:24  
标签:Redis redis 模式 6379 集群 192.168 master 节点

一、Redis集群方式

主从模式、哨兵模式、集群模式(cluster)

主从复制:解决数据备份,读写分离。但是无法实现自动化故障转移,无法对master进行扩容。

哨兵模式:实现自动化故障恢复。在读写分离下,单节点导致服务不可用。

集群模式:解决负载均衡以及存储问题。

模式

版本

优点

缺点

主从模式

redis2.8之前

1、解决数据备份问题
2、做到读写分离,提高服务器性能

1、master故障,无法自动故障转移,需人工介入
2、master无法实现动态扩容

哨兵模式

redis2.8级之后的模式

1、Master 状态监测
2、master节点故障,自动切换主从,故障自愈
3、所有slave从节点,随之更改新的master节点

1、slave节点下线,sentinel不会对其进行故障转移,连接从节点的客户端因为无法获取到新的可用从节点
2、master无法实行动态扩容

redis cluster模式

redis3.0版本之后

1、有效的解决了redis在分布式方面的需求
2、遇到单机内存,并发和流量瓶颈等问题时,可采用Cluster方案达到负载均衡的目的
3、可实现动态扩容
4、P2P模式,无中心化
5、通过Gossip协议同步节点信息
6、自动故障转移、Slot迁移中数据可用
7、自动分割数据到不同的节点上
8、整个集群的部分节点失败或者不可达的情况下能够继续处理命令

1、架构比较新,最佳实践较少
2、为了性能提升,客户端需要缓存路由表信息
3、节点发现、reshard操作不够自动化
4、不支持处理多个keys的命令,因为这需要在不同的节点间移动数据
5、Redis 集群不像单机 Redis 那样支持多数据库功能, 集群只使用默认的 0 号数据库, 并且不能使用 SELECT index 命令

 二、集群模式简介

       集群中的节点分为主节点和从节点;只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。

       redis集群采用master-slave的方式,即1个master节点可以包含多个slave节点,slave节点主要对master节点的数据进行备份,如果master节点挂了,可以启动salve节点替换掉原先的master节点,作为新的master节点。redis集群使用投票容错机制,如果集群中超过半数以上的节点投票认为某节点挂了,那么这个节点就会被认为挂掉了,所以,在设置redis集群时,最少的master节点为3个,如果每一个master节点都添加一个slave节点的话,搭建一个redis集群总共需要6个节点,即3个master节点,3个slave节点。

     redis集群没有统一的入口,客户端连接集群的时候,连接集群中的任意节点即可。

     redis集群的运用主要是针对海量数据+高并发+高可用的场景。

三、数据分片方式

      经过CRC16哈希到一个指定的Node上,这个过程即redis cluster的分片,集群内部将所有的key映射到16384个Slot中,集群中的每个Redis Instance负责其中的一部分的Slot的读写。

      集群客户端连接集群中任一Redis Instance即可发送命令,当Redis Instance收到自己不负责的Slot的请求时,会将负责请求Key所在Slot的Redis Instance地址返回给客户端,客户端收到后自动将原请求重新发往这个地址,对外部透明。一个Key到底属于哪个Slot由 (HASH_SLOT = CRC16(key) mod 16384) 决定。只有master节点会被分配槽位,slave节点不会分配槽位。

    具体的分片方式有客户端分片、代理分片和Twemproxy 代理分片机制。

(一)客户端分片

        客户端分片方案是将分片工作放在业务程序端。程序代码根据预先设置的路由规则,直接对多个 Redis 实例进行分布式访问。这样的好处是,群集不依赖于第三方分布式中间件,实现方法和代码都自己掌控,可随时调整,不用担心踩到坑。这实际上是一种静态分片技术,Redis 实例的增减,都得手工调整分片程序。基于此分片机制的开源产品,现在仍不多见。

        这种分片机制的性能比代理式更好(少了一个中间分发环节),但缺点是升级麻烦,对研发人员的个人依赖性强,需要有较强的程序开发能力做后盾。如果主力程序员离职,可能新的负责人会选择重写一遍。所以这种方式下可运维性较差,一旦出现故障,定位和解决都得研发人员和运维人员配合解决,故障时间变长。因此这种方案,难以进行标准化运维,不太适 合中小公司。

(二)代理分片

        代理分片方案是将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求,根据路由规则,将这些请求分发给正确的 Redis 实例并返回给业务程序。这种机制下,一般会选用第三方代理程序(而不是自己研发)。因为后端有多个 Redis 实例,所以这类程序又称为分布式中间件。这种分片机制的好处是业务程序不用关心后端 Redis实例,维护起来也方便。虽然会因此带来些性能损耗,但对于 Redis 这种内存读写型应用,相对而言是能容忍的。这是比较推荐的集群实现方案。像 Twemproxy、Codis 就是基于该机制的开源产品的其中代表,应用非常广泛。

 1.Twemproxy 代理分片机制

       Twemproxy 是一种代理分片机制,由 Twitter 开源。Twemproxy 作为代理,可接受来自多个程序的访问,按照路由规则,转发给后台的各个 Redis 服务器,再原路返回。这个方案顺理成章地解决了单个 Redis 单实例问题。当然 Twemproxy 本身也是单点,需要用Keepalived 做高可用方案。在很长的时间内,Twemproxy 是应用范围最广、稳定性最高、最久经考验的分布式中间件。 

       这种分片方式无法平滑地扩容/缩容,增加了运维难度。当业务量突增需要增加 Redis 服务器或业务量萎缩需要减少 Redis 服务器时,Twemproxy 都无法平滑地进行扩容或缩容等操作。

       Twemproxy 代理分片机制对运维操作不友好,甚至没有控制面板。由于使用了中间件代理,相比客户端直接连接服务器方式,性能上有所损耗,实测性能效果降低了 20%左右。

2.Codis 代理分片机制

     Codis 由豌豆荚于 2014 年 11 月开源,基于 Go 语言和 C 语言开发,是近期涌现的、国人开发的优秀开源软件之一,现已广泛用于豌豆荚的各种 Redis 业务场景。从各种压力测试来看,Codis 的稳定性符合高效运维的要求。

     Codis 引入了 Group 的概念,每个 Group 包括 1 个 Redis Master 及至少 1 个 RedisSlave,这是和 Twemproxy 的区别之一。这样做的好处是,如果当前 Master 有问题,则运维人员可通过 Dashboard“自助式”切换到 Slave,而不需要小心翼翼地修改程序配置文件。

(二)服务器端分片

        服务器端分片是 Redis 官方的集群分片技术。Redis-Cluster 将所有 Key 映射到 16384个 slot 中,集群中每个 Redis 实例负责一部分,业务程序是通过集成的 Redis-Cluster 客户端进行操作。客户端可以向任一实例发出请求,如果所需数据不在该实例中,则该实例引导客户端自动去对应实例读写数据。Redis-Cluster 成员之间的管理包括节点名称、IP、端口、状态、角色等,都通过节点与之间两两通讯,定期交换信息并更新。

四、多slave选举

在多个slave情况下如果一个master宕机,需要基于Raft协议选举方式来实现的新主的选举。步骤如下:

  1. 当从节点发现自己主master下线后,从节点广播故障切换请求。master向节点投票。
  2. master进行投票,master向slave返回故障切换请求,表示支持slave成为新的master。
  3. slave根据请求统计有多少master支持。
  4. 集群里有N个master,slave收到N/2 +1票时,成为新的master。
  5. 若没有足够的支持票数,则重新选举。

五、案例分析

 (一)安装Redis

[root@localhost ~]# systemctl stop firewalld

[root@localhost ~]# setenforce 0

[root@localhost ~]# yum -y install gcc* zlib-devel

[root@localhost ~]# tar xvzf redis-5.0.14.tar.gz

[root@localhost ~]# cd redis-5.0.14/

[root@localhost redis-5.0.14]# make

[root@localhost redis-5.0.14]# make PREFIX=/usr/local/redis install

[root@localhost ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/

[root@localhost redis-5.0.14]# cd /root/redis-5.0.14/utils/

[root@localhost utils]# ./install_server.sh

(二)修改配置文件

[root@localhost ~]# vim /etc/redis/6379.conf

 bind 0.0.0.0 ##62行

protected-mode yes

port 6379

tcp-backlog 511

timeout 0

tcp-keepalive 300

daemonize yes

supervised no

pidfile /var/run/redis_6379.pid

loglevel notice

logfile /var/log/redis_6379.log

appendonly yes                                                 ##开启 aof 持久化

cluster-enabled yes                                      ##722行,去掉注释符,表示启用群集

cluster-config-file nodes-6379.conf                        ##730行,去掉注释

cluster-node-timeout 15000                               ##736行,去掉注释

cluster-require-full-coverage no                   ##813行,去掉注释,将yes改为no

备注:

开启Cluster:cluster-enabled yes

集群配置文件:cluster-config-file nodes-7000.conf。这个配置文件不是要我们去配的,而是Redis运行时保存配置的文件,所以我们也不可以修改这个文件。

集群超时时间:cluster-node-timeout 15000。结点超时多久则认为它宕机了。

槽是否全覆盖:cluster-require-full-coverage no。默认是yes,只要有结点宕机导致16384个槽没全被覆盖,整个集群就全部停止服务,所以一定要改为no

[root@localhost ~]# /etc/init.d/redis_6379 restart

[root@localhost ~]# netstat -anpt | grep 6379

tcp        0      0 192.168.10.101:6379     0.0.0.0:*               LISTEN      20315/redis-server  

tcp        0      0 192.168.10.101:16379    0.0.0.0:*               LISTEN      20315/redis-server

(三)创建redis群集

redis-cli --cluster create --cluster-replicas 1 192.168.10.101:6379 192.168.10.102:6379 192.168.10.103:6379 192.168.10.104:6379 192.168.10.105:6379 192.168.10.106:6379

(四)测试群集

[root@localhost ~]# redis-cli -h 192.168.10.106 -p 6379 -c

192.168.10.106:6379> set centos 7.3

192.168.10.106:6379> get centos

192.168.10.106:6379> quit

[root@localhost ~]# redis-cli -h 192.168.10.105 -p 6379 -c

192.168.10.105:6379> get centos

192.168.10.105:6379> quit

(五)集群信息查看

[root@localhost ~]# redis-cli

192.168.10.106:6379> cluster nodes

(六)添加节点

方法一

[root@localhost ~]# redis-cli -c -p 6379 cluster meet 192.168.10.107 6379

OK

[root@localhost ~]# redis-cli

127.0.0.1:6379> cluster nodes

注意:

添加完后此新节点是master的角色

方法二

redis-cli --cluster add-node 192.168.10.109:6379 192.168.10.107:6379

注意:

10.109是要新添加的节点,10.107是当前集群中的任意一个节点

(七)修改新节点称为其他节点从节点

[root@localhost ~]# redis-cli -h 192.168.10.109 -p 6379

192.168.10.109:6379> cluster replicate 5472bbc9226737ca2199e146080ddaa41686a694

让10.109称为10.107的从节点,此ID是10.107的ID

(八)重新分配槽位

重新分片基本上意味着将slot 重新分配,就像集群创建一样,它是使用 redis-cli 实用程序完成的。

注意:平均分配所有的槽位,使用以下命令会自动降16384个槽位自动分配给集群的每一个master,不用手动指定槽为分配。

redis-cli --cluster rebalance --cluster-threshold 1 --cluster-use-empty-masters 192.168.10.101:6379

只需要指定一个老的节点(10.21.108.174:3001),redis 会自动查找其他节点。

(九)删除节点 

1.清除10.109的槽位信息

[root@localhost ~]# redis-cli -h 192.168.10.109 -p 6379

192.168.10.109:6379> flushall

OK

192.168.10.109:6379> cluster reset

OK

2.删除10.109的节点

redis-cli --cluster del-node 192.168.10.101:6379 fe75330d96c2c3af9c5a02b9819d66b2e8a48da2

注意:

此ID为10.107的ID

标签:Redis,redis,模式,6379,集群,192.168,master,节点
From: https://blog.csdn.net/zheshijiuyue/article/details/140375453

相关文章

  • C++ PImpl模式、指向实现的指针、PImpl Idiom、隐藏实现细节
    C++PImpl模式、指向实现的指针、PImplIdiom、隐藏实现细节flyfishPImpl全称是“PointertoImplementation”,在中文中通常翻译为“指向实现的指针”或者“指向实现”。PImpl是一种编程技巧,通常用于C++中,通过这种技术,可以隐藏类的实现细节,达到信息隐藏和二进制兼容......
  • 记录些Redis题集(2)
    Redis的多路IO复用多路I/O复用是一种同时监听多个文件描述符(如Socket)的状态变化,并能在某个文件描述符就绪时执行相应操作的技术。在Redis中,多路I/O复用技术主要用于处理客户端的连接请求和读写操作,以实现高并发、高性能的服务。Redis支持多种多路I/O复用机制,包括select、poll......
  • 记录些Redis题集(4)
    Redis通讯协议(RESP)Redis通讯协议(RedisSerializationProtocol,RESP)是Redis服务端与客户端之间进行通信的协议。它是一种二进制安全的文本协议,设计简洁且易于实现。RESP主要用于支持客户端和服务器之间的请求响应交互。RESP的主要特点:简单性:协议的设计非常简单,易于理......
  • 记录些Redis题集(1)
    Redis内存淘汰触发条件的相关配置如下:Redis通过配置项maxmemory来设定其允许使用的最大内存容量。当Redis实际占用的内存达到这一阈值时,将触发内存淘汰机制,开始删除部分数据以释放内存空间,防止服务因内存溢出而异常。Redis内存淘汰策略可在配置文件redis.conf中通过maxmemory......
  • 0180-进入 64 位模式
    环境Time2022-11-12WSL-Ubuntu22.04QEMU6.2.0NASM2.15.05前言说明参考:https://os.phil-opp.com/entering-longmode目标从保护模式切换到长模式。定位代码段因为当前还是执行的32的指令,所以需要执行跳转,重新选择GDT,这里给代码段加了一个标记。gdt64:dq0......
  • 0177-长模式检查
    环境Time2022-11-12WSL-Ubuntu22.04QEMU6.2.0NASM2.15.05前言说明参考:https://os.phil-opp.com/entering-longmode//目标定义一个长模式检查函数,验证CPU是否支持长模式。长模式也就是64位模式。定义栈需要先定义栈信息,后面的检查需要使用栈。section.bss......
  • 在Linux中,apache有几种工作模式,分别介绍下其特点,并说明什么情况下采用不同的工作模式?
    在Linux中,Apache服务器支持多种工作模式,每种模式都有其特定的应用场景和优缺点。Apache的三种主要工作模式是:Prefork、Worker和Event。以下是对这三种工作模式的详细介绍及其适用场景:1.Prefork模式特点:非线程型、预派生:Prefork模式使用多个子进程来处理请求,每个子进程仅有一......
  • 在Linux中,我们都知道FTP协议有两种工作模式,它们的大概的⼀个工作流程是怎样的?
    在Linux中,FTP(FileTransferProtocol,文件传输协议)协议支持两种工作模式:主动模式(ActiveMode)和被动模式(PassiveMode)。这两种模式在数据传输的发起和连接建立的方式上存在显著差异。以下分别详细说明这两种模式的工作流程:一、主动模式(ActiveMode)建立控制连接:客户端首先通过TC......
  • Redis:高性能的开源缓存数据库
    简介:Redis(RemoteDictionaryServer)是一个基于内存的开源缓存数据库,常用于缓存、消息队列、分布式锁等场景。它被设计成快速、可靠且易于使用的数据库系统,具有高性能、高可用、可扩展性等特点。本篇博客将介绍Redis的基本原理、常见应用场景以及优势。Redis的基本原理Redis......
  • Redis存储原理与数据模型
    Redis存储结构存储转换redis-value编码stringint:字符串长度小于等于20切能转成整数raw:字符串长度大于44embstr:字符串长度小于等于44listquicklist(双向链表)ziplist(压缩链表)hashdict(字典):节点数量大于512或者字符串长度大于64ziplist(压缩链表):节点数......