Redis集群在NoSQL中的应用与优化策略

目录

一、Redis集群方式

二、集群模式简介

三、数据分片方式

四、负载均衡的实现

五、故障的处理

六、Redis集群部署

1.资源清单

2.修改主机名

3.安装Redis（每个节点都要安装）

4.修改配置文件（每个节点都要配置）

5.创建redis群集（master1）

6.删除节点（master1）

7.清除从节点的数据（slave1、slave2、slave3）

8.添加节点

9.检查指定节点的集群状态（master1）

10.测试集群（master1）

---

一、Redis集群方式

1.主从模式

a.主从复制是高可用Redis的基础，哨兵和群集是在主从复制基础上实现高可用。

b.主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单故障恢复

c.缺陷：故障恢复无法自动化，写操作无法负载均衡，存储能力受到单机的限制

2.哨兵模式

a.在主从复制基础上，哨兵实现了自动化的故障恢复

b.缺陷：写操作无法负载均衡，存储能力受到单机的限制，哨兵无法对从节点进行自动故障转移；在读写分离场景下，从节点故障会导致读服务不可用，需要对从节点做到额外的监控、切换操作

3.集群模式

a.通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案、

b.Redis-Cluster，支持Redis分布式集群部署模式，采用无中心分布式架构。所Redis节点彼此互联，内部使用二进制协议优化传输速度和带宽。节点Fail是通过集群中超过半数的节点检测失败是才生效。

c.客户端与Redis节点直连，不需要中间代理层，提高了Redis集群性能

d.Redis Cluster通过创建多个副本来保证数据的可靠性

二、集群模式简介

a.集群，即Redis Cluster。集群由多个节点（Node）组成，Redis的数据分布在这些节点中

b.集群中的节点分为主节点和从节点

c.只有主节点负责读写请求和群集信息维护，从节点只进行主节点数据和状态信息的复制

d.Redis集群采用master-slave方式

e.Redis集群是一个由多个主从节点组成的分布式服务集群，它具有复制、高可用和分片特性

三、数据分片方式

1.客户端分片

a.将分片工作放在业务程序端。程序代码根据预先设置的路由规则，直接对多个Redis实例进行分布式访问

b.这种分片机制的性能比代理式更好

c.缺点是：升级麻烦，对研发人员的个人依赖项强，需要有较强的程序开发能力做后盾

2.代理分片

a.将分片的工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回个业务程序

b.Twemproxy代理分片机制

可接受多个程序的访问，按照路由规则，转发到后台的各个Redis服务器，再原路返回。

解决了单个Redis实例问题，应用范围广、稳定性高、最久经考验的分布式中间件

无法平滑的扩容/缩容，增加了运维难度

c.Codis代理分片机制

引用了Group的概念，每个Group包括一个Redis Master及至少1个RedisSlave

好处是如果当前Master有问题，则运维人员可通过Dashbiard”自助式“切换到Slave

支持数据热迁移

3.服务器分片

a.是Rredis官方的集群分片技术

b.Redis-Cluster将所有Key映射到16834个slot中，集群中每个Redis实例复制一部分，业务程序是通过集成的Redis—Cluster客户端进行操作

c.客户端可以向任意实例发出请求，如果所需数据不在该实例中，则该实例引导客户端自动对对应实例读写数据。

d.Redis-Cluster成员之间的管理包括节点名称、IP、端口、状态、角色等，都通过节点与之间两两通讯，定期交换信息并更新

四、负载均衡的实现

1.客户端路由

a.客户端需要根据数据的键名选择正确的节点进行读写操作、

b.Redis Cluster使用哈希槽来划分数据，并将每个哈希槽映射到相应的节点上

c.客户端可以根据键名的哈希值，将请求发送到对应的节点上，实现负载均衡

2.自动迁移

a.当节点加入或离开群集时，系统会自动重新分配数据，保持各个节点上哈希槽的均衡

b.这种机制可以在节点数目变化时，自动调整数据的分布，实现负载均衡

3.故障检测与恢复

a.集群中的节点会相互监控，检测节点的健康状态

b.当某个节点被检测到不可用时，系统会自动将该节点标记为下线，并将该节点上的哈希槽重新分配到其它节点。当节点恢复正常时，系统会自动将其重新加入集群，并进行数据迁移，保持数据的一致性

4.Redis Cluster通过分片和副本机制实现了数据的高可用性和负载均衡

五、故障的处理

1.故障转移

a.当从节点发现自己的主节点变为已下线（FALL）状态时，便尝试进Failover，以期望成为新的主

• 从下线主节点的所有从节点中选中一个从节点
• 被选中的从节点执行SLAVEOF NO NOE命令。成为新的主节点
• 新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己
• 新的主节点对集群进行广播PONG消息，告知其它节点已经成为新的主节点
• 新的主节点开始接收和处理槽相关的请求
• 集群slots是否必须完整才能对外提供服务

2.多slave选举

a.当从节点发现自己的主节点进行已下线状态时，从节点会广播一条CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST 消息，要求所有收到这条消息，并且具有投票权的主节点向这个从节点投票。

b.如果一个主节点具有投票权，并且这个主节点尚未投票给其他从节点，那么主节点将向要求投票的从节点返回条，CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK 消息，表示这个主节点支持从节点成为新的主节点。

c.每个参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK 消息，并根据自己收到了多少条这种消息来统计自己获得了多少主节点的支持。

d.如果集群里有N个具有投票权的主节点，那么当一个从节点收集到大于等于集群N/2+1张支持票时，这个从节点就成为新的主节点。

e.如果在一个选举周期没有从能够收集到足够的支持票数，那么集群进入一个新的选举周期，并再次进行选主，直到选出新的主节点为止。

六、Redis集群部署

1.资源清单

操作系统	主机名	IP	应用
OpenEuler 24.03	master1	192.168.16.142	Redis
OpenEuler 24.03	master2	192.168.16.143	Redis
OpenEuler 24.03	master3	192.168.16.144	Redis
OpenEuler 24.03	slave1	192.168.16.145	Redis
OpenEuler 24.03	slave2	192.168.16.146	Redis
OpenEuler 24.03	slave3	192.168.16.147	Redis

2.修改主机名

hostnamectl set-hostname master1
hostnamectl set-hostname master2
hostnamectl set-hostname master3
hostnamectl set-hostname slave1
hostnamectl set-hostname slave2
hostnamectl set-hostname slave3

3.安装Redis（每个节点都要安装）

dnf -y install gcc* make tar zlib-devel
tar zxf redis-5.0.14.tar.gz  
cd redis-5.0.14/ 
make && make PREFIX=/usr/local/redis install 
ln -s /usr/local/redis/bin/* /usr/local/bin
cd /root/redis-5.0.14/utils/
./install_server.sh 

4.修改配置文件（每个节点都要配置）

vi /etc/redis/6379.conf bind 0.0.0.0    #70行
appendonly yes    #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/etc/init.d/redis_6379  restartss -nlpt

5.创建redis群集（master1）

redis-cli --cluster create --cluster-replicas 1 192.168.16.142:6379 192.168.16.143:6379 192.168.16.144:6379 192.168.16.145:6379 192.168.16.146:6379 192.168.16.147:6379

6.删除节点（master1）

redis-cli --cluster del-node 192.168.16.145:6379  94e7cf366074901d913183b94dff2c89f091b8f3
redis-cli --cluster del-node 192.168.16.146:6379 f447dfd491a5f5357163659c1b62d253aa15a842
redis-cli --cluster del-node 192.168.16.147:6379 44c34877a34f2d8820d93ff255fb22d32a947405[root@master1 utils]# redis-cli 
127.0.0.1:6379> cluster nodes
ffa7fa66b621e295a8961f0975ae0f9a07251662 192.168.16.143:6379@16379 master - 0 1747108964941 2 connected 5461-10922
6068a1ecd4a3143f14a15efa2ce18d7d3a37b350 192.168.16.142:6379@16379 myself,master - 0 1747108962000 1 connected 0-5460
4b04b0ef593f34a72ece542edfeb55b8dd670843 192.168.16.144:6379@16379 master - 0 1747108963936 3 connected 10923-16383
127.0.0.1:6379> 

7.清除从节点的数据（slave1、slave2、slave3）

ls /var/lib/redis/6379/
rm -rf /var/lib/redis/6379/*
ls /var/lib/redis/6379/
/etc/init.d/redis_6379 restart
ss -nlpt

8.添加节点

#master1上
redis-cli --cluster add-node 192.168.16.145:6379 192.168.16.142:6379
redis-cli --cluster add-node 192.168.16.146:6379 192.168.16.143:6379
redis-cli --cluster add-node 192.168.16.147:6379 192.168.16.144:6379#slave1上
[root@slave1 utils]# redis-cli -h 192.168.16.145
192.168.16.145:6379> cluster replicate 6068a1ecd4a3143f14a15efa2ce18d7d3a37b350
OK#slave2上
[root@slave2 utils]# redis-cli -h 192.168.16.146
192.168.16.146:6379> cluster replicate ffa7fa66b621e295a8961f0975ae0f9a07251662
OK
192.168.16.146:6379> #slave3上
[root@slave3 utils]# redis-cli -h 192.168.16.147
192.168.16.147:6379> cluster replicate 4b04b0ef593f34a72ece542edfeb55b8dd670843
OK

9.检查指定节点的集群状态（master1）

redis-cli --cluster  check 192.168.16.142:6379

10.测试集群（master1）

[root@master1 utils]# redis-cli -c -h 192.168.16.142
192.168.16.142:6379> set kc01 11111
-> Redirected to slot [9745] located at 192.168.16.143:6379
OK
192.168.16.143:6379> exit
[root@master1 utils]# redis-cli -c -h 192.168.16.142
192.168.16.142:6379> keys *
(empty list or set)
192.168.16.142:6379> get kc01
-> Redirected to slot [9745] located at 192.168.16.143:6379
"11111"
192.168.16.143:6379>