Redis集群搭建

前言

哨兵模式虽然让读写分离更加高可用,但单台服务器由于本身的内存和 CPU 瓶颈,对于高并发和大数据业务的应用场景还是远远不能满足;对于这种情况,有点经验的小伙伴会毫不犹豫的想到集群,搞他好几个节点,负载均衡再加上故障转移,岂不美哉。是的,就是这个理,接下来玩玩。

正文

集群,相信这个词小伙伴应该听的耳朵起茧子了吧;多搞几台服务器,让请求/命令平均分发到各个服务器,避免单台服务器承载过大压力;对于Redis 集群来说,为了实现自动故障转移,还需要在每个主节点上增加一个或多个从节点,当主节点发生故障时,从节点自动补上,实现高可用。

总的来说,Redis 集群有以下作用:

  • 多主节点的实现可以应对高并发场景,并发量增大,节点可以随时扩展满足需求;
  • 多主节点的实现可以存储更多的数据,因为数据均匀分布到各个节点;
  • 多主节点搭配多从节点的实现让高可用更加稳定,即当有主节点发生故障时,对应下面的从节点会升级为主节点,正常提供功能;

老规矩不变,一边实操一边总结,接下来搭建一个 3 主 3 从的集群,这是最简单的。 Redis 集群中最少需要 3 个主节点,再加上为了实现高可用,每个主节点至少得跟一个从节点,不然一个主节点挂了,找不到完整的数据,整个集群就不能用了;至于为什么会找不到完整的数据,下面会聊到。

接下来要搭建的集群环境如下:

Redis 集群搭建

简要说明:

  • 6370 为主节点,6381 为 6370 的从节点;
  • 6380 为主节点,6391 为 6380 的从节点;
  • 6390 为主节点,6371 为 6390 的从节点;
  • 在集群环境中主节点之间是相互通讯的(这里没有哨兵),每一个节点都是数据节点;

这里集群方案使用 redis-cli 自动指定主从关系(小伙伴的主从关系可能会和我这不一样哦),也可以手动指定;反正思路都一样;

以下演示在同一台机器上,通过端口区分各个节点;在实际开发中,一般都是用不同的服务器。

案例演示

  1. 准备六个节点的配置文件,开启集群相关配置;拷贝最初默认的配置文件,然后进行更改,主要更改以下项:
    port 6370 # 指定 redis 节点端口
    pidfile /var/run/redis_6370.pid # 指定对应进程文件
    dbfilename dump6370.rdb # 每个节点的 rdb 持久化文件
    cluster-enabled yes # 开启集群,这个比较重要
    cluster-config-file nodes-6370.conf #指定每个节点的集群配置文件,这个比较重要
    

    以上配置文件内容在其他节点(6370,6371,6380,6381,6390,6391)都需要进行修改,只是将其中 6370 改为对应节点的端口即可,目的就是为了不同节点使用不同端口并区分用到的不同文件即可;比如需要修改 6371 节点的配置文件如下:

    port 6371 # 指定 redis 节点端口
    pidfile /var/run/redis_6371.pid # 指定对应进程文件
    dbfilename dump6371.rdb # 每个节点的 rdb 持久化文件
    cluster-enabled yes # 开启集群,这个比较重要
    cluster-config-file nodes-6371.conf #指定每个节点的集群配置文件,这个比较重要
    

    其中cluster-enabledcluster-config-file是集群配置的重点。

  2. 启动六个节点,刚开始各个节点是相互独立的;准备好配置文件之后,就可以使用 redis-server 指定配置文件启动节点啦,如果节点多,小伙伴可以编写脚本哦;
    ./redis-server ZoeCluster/redis6370.conf # 启动 6370 节点
    ./redis-server ZoeCluster/redis6371.conf # 启动 6371 节点
    ./redis-server ZoeCluster/redis6380.conf # 启动 6380 节点
    ./redis-server ZoeCluster/redis6381.conf # 启动 6381 节点
    ./redis-server ZoeCluster/redis6390.conf # 启动 6390 节点
    ./redis-server ZoeCluster/redis6391.conf # 启动 6391 节点
    

    启动效果如下:

    Redis 集群搭建

    这样只是将各个节点启动起来,集群关系还没创建呢,如果不信,可以使用 redis-cli 连接任意一个节点查看集群信息,如下:

    Redis 集群搭建

    如上图,cluster-size 为 0,集群的关键,槽也还没有分配;那接下来肯定是要将各节点的集群关系搞起来;

  3. 建立节点集群关系由于我使用的Redis版本是 5.0,直接可以使用redis-cli就可以进行集群搭建,在此版本之前都推荐使用 redis-trib.rb 进行相关操作,这个是一个 Ruby 脚本,需要安装相关环境,小伙伴可以下来尝试;使用命令如下:
    ./redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6370 127.0.0.1:6380 127.0.0.1:6390 127.0.0.1:6371 127.0.0.1:6381 127.0.0.1:6391
    

    参数简介:

    — cluster : 指定是用于创建集群环境;

    -a:密码,即如果有密码,可以通过-a 传参,这里没有设置密码;

    –cluster-replicas:这里设置为 1, 用于配置主节点上的从节点数,1 就代表一主一从,2 就代表一主二从,依次类推;

    后面的是节点 IP:节点端口,一般前面的是主节点,后面的是从节点;

    Redis 集群搭建

    如果同意集群方案,然后就开始进行相关操作,如下:

    Redis 集群搭建

    同样,可以连接到任意一个节点,查看集群情况,如下:

    Redis 集群搭建

    注:关于主从节点之间的主从复制过程就不在这说了,和之前说过的主从复制一样;

  4. 演示访问操作;使用 redis-cli 连接任意节点写入数据,如果不指定集群连接的话,会写入数据失败,如下:Redis 集群搭建由于集群环境下,数据的存储位置是根据 Key 来计算而来的(这里牵涉到一致性哈希算法),使得数据可以均匀分配到各节点上,所以在 redis-cli 连接的时候需要指定集群模式,如下:Redis 集群搭建如上图所示,指定集群模式之后就可以正常存取了;
  5. 故障演示既然集群环境,肯定少不了要好好测测;模拟从节点挂掉找个从节点停掉试试,这里停掉 6371 节点,根据创建集群信息知道,它的主节点是 6390;主节点显示从节点断开连接,看看它的主节点反应:Redis 集群搭建

    其他集群节点只是将从节点标记为 failing 状态,即下线状态,如下:

    Redis 集群搭建

    对于存取数据也不受影响,这里就不截图了,小伙伴自行尝试吧;

    当故障的从节点 6371 重新连上时,主节点恢复主从关系,并进行主从复制操作;其他集群节点会清除原来标记的下线状态,将其改为上线;

    模拟主节点挂掉

    这里就手动将 6390 这个节点停掉,会有怎样的反应呢?

    自身从节点会每隔一秒检测连接,如果超时(默认是 15 秒),会选举从节点做为集群的主节点来提供服务,如下图:

    Redis 集群搭建

    数据存取最终还是不受影响;

    对于其他集群节点,将故障节点标记为 failing,让新上任的主节点提供服务,如下图:

    Redis 集群搭建

    存取数据也是不受影响的;

    挂掉的主节点 6390 如果恢复,那它只能变为 6371 的从节点啦,并进行相关主从复制操作;而集群的其他节点只是将其原有的 Fail 状态清除,表示可以正常连接;

Redis 集群就是这样简单,只要思路对,就是手工活;小伙伴可以编写脚本自动执行哦;

接下来说说集群数据的存储;

数据存储简单分析

Redis 集群环境中,数据的存储位置是根据对 Key 的 Hash 计算进行指定的; Redis 集群为了在节点改变时保证数据分布均匀,引入了槽(slot)作为迁移的基本单位,槽解耦了数据和实际节点的关系,使得实际节点数的改变对系统影响较小;

在整个集群中,槽(slot)总共有 16384,会将其均匀分配到集群的主节点上,其中每一份槽对应一个存储空间(这里的存储空间可以理解为一个容器,是可以存很多数据的),以上集群环境的槽分配如下:

Redis 集群搭建

存储数据的过程,如下:

连接 6380 主节点,执行如下操作:

Redis 集群搭建

具体过程如下:

Redis 集群搭建

简要说明:

  1. 客户端发起命令;
  2. 服务器将 Key 进行 CRC16 计算,并与总槽位计算出 Key 需要存储的位置;
  3. 这里模拟的 Key 为 zoe,计算出的槽位为 14588,不在 6380 这个节点上,集群节点会将其重定向到对应槽位的节点上;
  4. 然后找到 6371 上的 14588 槽位进行数据存储;(注,这里的 6371 已经是主节点了,因为上面做过一次故障转移模拟);

那集群节点是如何知道其他节点的槽范围和其他信息呢?

那是因为各节点之间有通讯,通讯端口是对应的 redis 端口+10000,比如节点 6371 的集群通讯端口为 16371(如果多台机器,别忘了防火墙放开这个端口哦),可以通过cluster nodes看到,如下:

Redis 集群搭建

并且将各节点的信息保存在自己对应的集群配置文件中,这个集群文件名是通过配置项cluster-config-file指定的,在集群节点启动时会检查该文件是否存在,如果不存在,会自动创建,如果存在,就加载里面的相关配置信息;里面有哪些信息,随便找个节点的配置文件看一下:

Redis 集群搭建

如上图所示,各节点的配置文件中记录了其他节点的主从关系,分配的槽位,各节点的状态;这样的话,集群关系就算重新启动也还存在。

集群伸缩(节点增删)演示

在实际应用场景中,会根据业务需要,对集群进行伸缩,即节点的增删;业务并发大了加节点进行扩展, 节点需要调整时可能需要进节点删除;

加节点

这里进行节点扩展,加一个 6360 主节点,6361 作为 6360 的从节点;参照以上集群搭建时配置文件更改,然后将其都启动,如下:

6360 节点

port 6360 # 指定 redis 节点端口
pidfile /var/run/redis_6360.pid # 指定对应进程文件
dbfilename dump6360.rdb # 每个节点的 rdb 持久化文件
cluster-enabled yes # 开启集群,这个比较重要
cluster-config-file nodes-6360.conf #指定每个节点的集群配置文件,这个比较重要

6361 节点

port 6361 # 指定 redis 节点端口
pidfile /var/run/redis_6361.pid # 指定对应进程文件
dbfilename dump6361.rdb # 每个节点的 rdb 持久化文件
cluster-enabled yes # 开启集群,这个比较重要
cluster-config-file nodes-6361.conf #指定每个节点的集群配置文件,这个比较重要

两个节点都启动,然后将 6360 加入到集群主节点中,执行以下命令:

./redis-cli --cluster add-node 127.0.0.1:6360 127.0.0.1:6370

注:其中 127.0.0.1:6360 是需要加入的新增节点,127.0.0.1:6370 是现有集群中的任意一个节点;

可以通过以下命令检测集群状态,如下:

./redis-cli --cluster check 127.0.0.1:6370  # 后面的地址是任意的集群节点

可以看到 6360 已经加入到集群环境中,但现在还没有从节点和槽分配,所以接下来先将 6361 作为 6360 的从节点加入,如下:

./redis-cli --cluster add-node --cluster-slave --cluster-master-id eaa814dc56beb0d5edb6a4fbb14f1384e78d4764 127.0.0.1:6361 127.0.0.1:6370 

参数说明:

  • –cluster-slave : 意思就是加入的是从节点;
  • –cluster-master-id:后面紧跟主节点的 id,这里就是 6360 的节点 id;通过 cluster nodes 可以查看到节点 id;
  • 127.0.0.1:6361:需要加入的从节点;
  • 127.0.0.1:6370:现有集群的任意主节点;

现在还差槽分配了,如果需要直接将 16384 个槽平均分配到所有节点话,直接执行以下命令即可:

./redis-cli --cluster rebalance --cluster-threshold 1 --cluster-use-empty-masters 127.0.0.1:6370

使用命令./redis-cli –cluster check 127.0.0.1:6370 查看分配结果,如下图,只截了部分:

Redis 集群搭建

如果不想均匀分配,根据自定义需要进行配置,可以执行以下命令,会提示一步一步配置;

./redis-cli --cluster reshard 127.0.0.1:6360 #后面是新加入的主节点 
# 也可以执行以下指令直接配置想要的数据
./redis-cli --cluster reshard --cluster-from all --cluster-to 需要分配槽的节点 id --cluster-slots 1000 --cluster-yes 127.0.0.1:6370 # 1000 指分配的槽数

这里就不截图演示了,留给小伙伴自己动手操作吧;

删除节点

  1. 先对节点进行分片工作,防止数据丢失,即将指定节点上的槽分配到其他节点;
    ./redis-cli –cluster reshard 要删除节点 ip:port
  2. 移除节点,推荐先删除从节点,再删除主节点; ./redis-cli –cluster del-node 节点 ip:port 节点 id

集群配置项

  • cluster-enabled(是否开启集群模式):设置为 yes,将该节点开启为集群模式;
  • cluster-config-file(设置每个集群节点对应的配置文件名称):文件是自动生成的,不用手动创建;
  • cluster-node-timeout(设置超时时间,即集群节点不可用的最大时间,如果超过这个时间就认为该节点不可用):默认为 15000(以毫秒为单位);
  • cluster-migration-barrier(配置一个主机最少可用的从机的个数):默认是 1,表示一个主机的从机迁移之后,至少得有一个从机可用,否则不进行节点迁移;
  • cluster-require-full-coverage(配置集群服务的可用性):默认 yes 开启,即集群没完全覆盖所有 slot,集群就挂了;设置为 no,就算槽没有全分配,也能提供服务,需要自己保证槽分配;

总结

到这集群的搭建就完啦,本来想着写着很简单的,没想到又干了 4000 字;对于集群,使用有一些限制,比如 Keys 命令只能针对当前节点,需要针对多节点的情况进行处理;集群中各节点只支持 db0 数据库,其他数据库不支持等等;所以使用要注意哦,后续抽时间单独整理一篇注意事项吧,篇幅有点长,不继续聊啦; 下篇说说熟悉的缓存穿透、缓存击穿、缓存雪崩吧。

 

相关:

Redis 之加个哨兵让主从复制更加高可用

Redis 集群环境搭建实践


来源:https://www.cnblogs.com/zoe-zyq/p/14370730.html

© 版权声明

☆ END ☆
喜欢就点个赞吧
点赞0 分享
图片正在生成中,请稍后...