NoSQL之Redis集群
一：Redis集群方式
Redis有三种模式:分别是主从复制、哨兵模式、Clustter
1：主从模式
主从复制是高可用Redis的基础,哨兵和群集都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单故障恢复。
缺陷:故障恢复无法自动化,写操作无法负载均衡,存储能力受到单机的限制。
2：哨兵模式
在主从复制的基础上,哨兵实现了自动化的故障恢复。
缺陷:写操作无法负载均衡,存储能力受到单机的限制,哨兵无法对从节点进行自动故障转移;在读写分离场景下,从节点故障会导致读服务不可用,需要对从节点做额外的监控、切换操作。
3：集群模式
通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。
Redis-Cluster是在Redis3.0版中推出,支持 Redis分布式集群部署模式,采用无中心分布式架构。所有的Redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。节点的fail是通过集群中超过半数的*节点检测失败时才生效。客户端与Redis节点直连,不需要中间代理层。客户端也不需要连接集群所有节点,连接集群中任何一个可用节点即可,这样即减少了代理层,也大大提高了Redis集群性能
RedisCluster通过创建多个副本来保证数据的可靠性。每个分片都有一个主节点和多个从节点,主节点负责处理读写操作,而从节点则复制主节点的数据。当主节点发生故障时,从节点会自动切换为主节点,提供读写服务。这样可以确保即使发生节点故障,系统仍然能够继续提供服务,保证数据的高可用性。
| 模式 | 版本 | 优点 | 缺点 |
| 主从模式 | 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号数据库，并且不能使用 SELECTindex 命令 |
二：集群模式简介
集群,即RedisCluster,是Redis3.0开始引入的分布式存储方案。集群由多个节点(Node)组成,Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点;只有主节点负责读写请求和集群信息的维护:从节点只进行主节点点数据和状态信息的复制。
redis集群采用master-slave的方式,即1个master节点可以包含多个slave节点,slave节点主要对master节点的数据进行备份,如果master节点挂了,可以启动salve节点替换掉原先的master节点,作为新的master节点。redis集群使用投票容错机制,如果集群中超过半数以上的节点投票认为某节点挂了,那么这个节点点就会被认为挂掉了,所以在设置redis集群时,最少的master节点为3个,如果每一一个master节点都添加一个slave节点的话,搭建一个redis集群总共需要6个节点,即3个masster节点,3个slave节点。redis集群没有统一的入口,客户端连接集群的时候,连接集群中的任意节点即可。
Redis集群是一个由多个主从节点群组成的分布式服务集群,它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式,这种集群模式没有中心节点,可水平扩展,据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式,且集群配置非常简单。redis集群的运用主要是针对海量数据+高并发+高可用的场景。
三：数据分片方式
对象保存到redis之前先经过CRC16哈希到一个指定的1Node上,这个过程即rediscluster的分片,集群内部将所有的key映射到16384个Slot中,集群中的每个RedisInstance负责其中的一部分的Slot的读写。集群客户端连接集群中任一Redis Instance即可发送命令,当RedisInstance收到自己不负责的Slot的话情求时,会将负责请求Key所在Slot的RedisInstance地址返回给客户端,客户端收到后自动将原请求重新发往这个地址,对外部透明。一个Key到底属于哪个Slot由(HASH_SLOT= CRC16(key) mod 16384)决定,也就是先对key进行哈希,然后对哈希值%16384习求余数算出槽位号。只有master节点会被分配槽位,slave节点不会分配槽位。
RedisCluster通过哈希算法将数据分散到多个节点上,实现数据的分片。每个节点负责管理一部分数据,并提供相应的读写操作。分片机制可以将数据均匀地分布在多个节点上,提高系统的并发处理能力。当某个节点发生故障时,只会影响该节点上的数据,而不会影响整个系统的可用性。具体的分片方式有客户端分片、代理分片和Twemproxy代理分片机制。
1：客户端分片
客户端分片方案是将分片工作放在业务程序端。程序代码根据预先设置的路由规则,直接对多个Redis实例进行分布式访问。这样的好处是,群集不依赖于第三方分布式中间件,实现方法和代码都自己掌控,可随时调整,不用担心踩到坑。这实际上是一种静态分片技术,Redis实例的增减,都得手工调整分片程序。基于此分片机制的开源产品,现在仍不多见。
这种分片机制的性能比代理式更好(少了一个中间分发环节),但缺点是升级麻烦,对研发人员的个人依赖性强,需要有较强的程序开发能力做后盾。女果主力程序员离职,可能新的负责人会选择重写一遍。所以这种方式下可运维性较差,一旦出现故障,定位和解决都得研发人员和运维人员配合解决,故障时间变长。因此这种方案,难以进行标准化运维,不太适合中小公司。
2：代理分片
代理分片方案是将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求,根据路由规则,将这些请求分发给正确的Redis实例并返回给业务程序。这种机制下,一般会选用第三方代理程序(而不是自己研发)。因为后端有多个Redis实例,所以这类程序又称为分布式中间件。这种分片机制的好处是是业务程序不用关心后端Redis实例,维护起来也方便。虽然会因此带来些性能损耗,但对于Redis这种内存读写型应用,相对而言是能容忍的。这是比较推荐的集群实现方案。像Tvwemproxy、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的稳定性符合高效运维的要求。实测Codiss集群业务处理性能改善很多,最初集群处理数据性能要比Twemproxy差20%左右,现在比Twemproxy好很多。并且Codis具有可视化运维管理界面。因此综合方面会优于Twemproxy很多。。目前越来越多的公司选择Codis。
Codis引入了Group的概念,每个Group包括1个Redis Master 及至少1个RedisSlave,这是和Twemproxy的区别之一。这样做的好处是,如果当前Master有问题,则运维人员可通过Dashboard"自助式"切换到Slave,而不需要/小心翼翼地修改程序配置文件。
为支持数据热迁移(AutoRebalance),出品方修改了Redis Server源码,并称之为CodisServer。Codis采用预先分片(Pre-Sharding)机制,事先规定分成1024个slots(也就是说,最多能支持后端1024个CodisServer),这些路由信息保存在zookeeper中。
3：服务端分片
服务器端分片是Redis官方的集群分片技术。Redis-C1luster将所有 Key 映射到16384个slot中,集群中每个Redis实例负责一部部分,业务程序是通过集成的Redis-Cluster客户端进行操作。客户端可以向任一实例发出请求,如果所需数据不在该实例中,则该实例引导客户端自动去对应实例读写数据。Redis-Cluster成员之间的管理包括节点名称、IP、端口、状态、角色等,都通过节点与之间两两通讯,定期交换信息并更新。
四：负载均衡的实现
客户端路由:在RedisCluster中,客户端需要根据数据的的键名选择正确的节点进行读写操作。RedisCluster使用哈希槽(hash slot)来划分数据,并将每个哈希槽映射到相应的节点上。客户端可以根据键名的哈希值,将请求发送到到对应的节点上,实现负载均衡
自动迁移:RedisCluster具有自动迁移功能,当节点加入或离开集群时,系统会自动重新分配数据,保持各个节点上哈希槽的均衡。当节点加入集群时,系统会将一部分哈希槽从其他节点迁移到新节点上;当节点离开集群时,系统会将该节点上的哈希槽重新分配给其他节点。这种机制可以在节点数目变化时,自动调整数据的分布,实现负载均衡。
故障检测与恢复:RedisCluster具有故障检测和自动恢复的机制。集群中的节点会相互监控,检测节点的健康状态。当某个节点被检测到不可用时,系统会自动将该节点标记为下线,并将该节点上的哈希槽重新分配给其他节点。当节点恢复正常时,系统会将其重新加入集群,并进行数据迁移,保持数据的一致性。
Redis Cluster通过分片和副本机制实现了数据的高可用性利负载均衡。分片机制将数据均匀地分布在多个节点上,提高了系统的并发处理能力:副本机制则保证了数据的可靠性,即使发生节点故障,也能够继续提供服务。同时,RedisCliuster通过客户端路由、自动迁移和故障检测与恢复等机制,实现了负载均衡和故障自动转移。在实际应用中,合理设计和配置RedisCluster,可以提高系统的性能、可靠性和可扩展性
五：故障处理
1：故障转移
当从节点发现自己的主节点变为己下线(FAIL)状态时,便尝试进Failover,以期成为新的主。
以下是故障转移的执行步骤:
(1)从下线主节点的所有从节点中选中一个从节点
(2)被选中的从节点执行SLAVEOFNO NOE命令,成为新的主节点
(3)新的主节点会撤销所有对已下线主节点的槽指派,并将这些槽全部指派给自己
(4)新的主节点对集群进行广播PONG消息,告知其他节点已经成为新的主节点
(5)新的主节点开始接收和处理槽相关的请求
(6)集群slots是否必须完整才能对外提供服务
2：多slave选举
在多个slave情况下如果一个master宕机,需要基于Raft协议选举方式来实现的新主的选举。步骤如下:
（1）当从节点发现自己的主节点进行已下线状态时,从节点会广播一条CLUSTERMSGTYPE_FAILOVER_AUTH REQUEST消息,要求所有收到这条消息,并且具有投票权的主节点向这个从节点投票。
（2）如果一个主节点具有投票权,并且这个主节点尚未投票给其他从节点,那么主节点将向要求投票的从节点返回一条,CLUSTERMSG TYPE_FAILOVER_AUTH_ACK消息,表示这个主节点支持从节点成为新的主节点。
（3）每个参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVERAUTH_ACK消息,并根自己收到了多少条这种消息来统计自己获得了多少主节点的支持
（4）如果集群里有N个具有投票权的主节点,那么当一个从书节点收集到大于等于集群N/2+1张支持票时,这个从节点就成为新的主节点。
（5）如果在一个选举周期没有从能够收集到足够的支持票数,那么集群进入一个新的选举周期,并再次进行选主,直到选出新的主节点为止。
六：Redis群集部署
| 操作系统 | 主机名 | 配置 | IP | 应用 |
| openEuler24 | master1 | 2C4G | 192.168.10.101 | Redis |
| openEuler24 | master2 | 2C4G | 192.168.10.102 | Redis |
| openEuler24 | master3 | 2C4G | 192.168.10.103 | Redis |
| openEuler24 | slave1 | 2C4G | 192.168.10.104 | Redis |
| openEuler24 | slave2 | 2C4G | 192.168.10.105 | Redis |
| openEuler24 | slave3 | 2C4G | 192.168.10.106 | Redis |
1：安装redis（每个节点都要安装）
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# setenforce 0
[root@localhost ~]# dnf -y install gcc* zlib-devel tar
[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/locafl/redis install
[root@localhost ~]# ln -s /usr/local/redis/bin/* /usr/local/bin
[root@localhost redis-5.0.14]# cd /root/redis-5.0.144/utils
[root@localhost utils]# ./install_server.sh2：修改配置文件（每个节点都要配置，只有IP地址不同，其他都相同）
[root@localhost ^]# vim /etc/redis/6379.conf
bind 0.0.0.0 ##70行
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.10g
appendonly yes ##开启aof持久化,700行
cluster-enabled yes ##833行,去掉注释符,表示启用群集
cluster-config-file nodes-6379.conf ##841行,去掉注释
cluster-node-timeout 15000 ##847行,去掉注释
cluster-require-full-coverage no ##924行,去掉注释,将yes改为no
注释:
开启Cluster:cluster-enabledyes
集群配置文件:cluster-config-file nodes-7000.conf这个配置文件不是要我们去配的,
而是Redis运行时保存配置的文件,所以我们也不可以修改这个文件。
集群超时时间:cluster-node-timeout15000。结点超时多久则认为它宕机了。
槽是否全覆盖:cluster-require-full-coverageno。默认是yess,只要有结点右机导致16384
个槽没全被覆盖,整个集群就全部停止服务,所以一定要改为no
[root@localhost ~]# /etc/init.d/redis_6379 restart
[root@localhost ~]# netstat -anpt | grep 63793：创建redis群集
[root@localhost ~]# redis-cli --cluster create --cluster-replicas 1 192.168.10.
101:6379 192.168.10.102:6379 192.168.10.103:6379 1992.168.10.104:6379 192.168.10.
105:6379 192.168.106:6379
备注:
需要至少3个master节点,副本数至少为1,即每个mastter需要一个从节点4：测试群集
[root@localhost ~]# redis-cli -h 192.168.10.106 -p6379-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 -p6379 -c
192.168.10.105:6379 get centos
192.168.10.105:6379 quit5：集群信息查看
[root@localhost ~]# redis-cli
192.168.10.106:6379>cluster nodes
[root@localhost ~]# redis-cli --cluster check 192.168.10.101:63796：添加节点
例如存在节点192.168.10.107(并且已在配置文件中开启集群相关配置),把
192.168.10.107加入现有集群
[root@localhost ~]# redis-cli -c -p 6379 cluster meet192.168.10.1076379
OK
[root@localhost ~]# redis-cli
127.0.0.1:6379>cluster nodes
注意:
添加完后此新节点是master的角色7：添加节点的另一种方法
例如存在节点192.168.10.108(并且已在配置文件中开启集群相关配置), 192.168.10.108加入现有集群 [root@localhost~]# redis-cli --cluster add-node 192.168.10.108:63799 192.168.10 101:6379 注意: 10.108是要新添加的节点,10.101可以是当前集群中的任意一个节点
8：删除节点
（1）清除10.108的槽位信息
[root@localhost ~]# redis-cli -h 192.168.10. 108 -p 6379
192.168.10.109:6379>flushall
OK
192.168.10.109:6379>cluster reset
OK（2）删除10.108的节点
[root@localhost ~]# redis-cli --cluster del-node 192.168.10.108:6379 fe75330d96
c2c3af9c5a02b9819d66b2e8a48da2
注意:此ID为10.108的ID
注意：
如果删除的slave节点,直接删除即可,如果删除的是master*节点,需要先清除槽信息再
删除,并且建议清除redis实例中的集群配置文件并重启实例,例如/var/lib/redis/6379
/nodes-6379.conf9：修改新节点为其他节点的从节点
[root@localhost ^]# redis-cli -h 192.168.10.108 -p6379
192.168.10.108:6379>cluster replicate 5472bbc9226737ca2199e146080ddaa41686a694
让10.108成为10.107的从节点,此ID(5472bbc9226737ca2199e146080ddaa41686a694
是10.107的ID
注意:10.108需要先加入到集群,再设置为其他master的slave。10：重新分配槽位
重新分片基本上意味着将slot重新分配,就像集群创建一样,它是使用redis-cli实用程序完成的。
注意:平均分配所有的槽位,使用以下命令会自动将16384个个槽位自动分配给集群的每个master,不用手动指定槽为分配。
[root@localhost ~]# redis-cli --cluster rebalance --clusteer-threshold 1 --clust
er-use-empty-masters 192.168.10.101:6379
只需要指定一个老的节点(192.168.10.101:6379),redis会会自动查找其他节点
如果某个master节点没有槽位,可以使用以下命令分槽:
语法:redis-cli -h -p CLUSTER ADDSLOTS 1 2 3 4 ... 5460
[root@localhost ~]# redis-cli -h 127.0.0.1 -p 6379 CLUSTER ADDSLOTS{0..5460} 七：集群排错思路
（1）redismaster宕机,恢复后不会自动切为主
（2）扩容rediscluster如果我们大量使用rediscluster的话,有一个痛点就是扩容的机器加入集群的时候,分配主从。现在只能使用命令去操作,非常的凌乱。而且如果rediscluster是线上集群或者是有数据的话,极其容易造成丢数据。
（3）redis cluster从节点支持可读的前提下得在执行 readonly执行,程序读取从节点时也需要执行。一次连接需要执行一次,客户端关闭即失效。
（4）rediscluster启动必须以绝对路径的方式启动,如果不用绝对路径启动,会产生新的nodes.conf文件,集群的主从对应关系就会变乱,从而导致集群奔溃