Redis集群搭建很easy

坐下坐下,基本操作(ZooKeeper 操作篇)

前言

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

正文

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

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

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

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

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

简要说明:

  • 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-cli连接任意一个节点查看集群信息,如下:

    如上图,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:节点端口,一般前面的是主节点,后面的是从节点;

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

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

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

  4. 演示访问操作

    使用redis-cli连接任意节点写入数据,如果不指定集群连接的话,会写入数据失败,如下:

    由于集群环境下,数据的存储位置是根据Key来计算而来的(这里牵涉到一致性哈希算法),使得数据可以均匀分配到各节点上,所以在redis-cli连接的时候需要指定集群模式,如下:

    如上图所示,指定集群模式之后就可以正常存取了;

  5. 故障演示

    既然集群环境,肯定少不了要好好测测;

    模拟从节点挂掉

    找个从节点停掉试试,这里停掉6371节点,根据创建集群信息知道,它的主节点是6390;

    主节点显示从节点断开连接,看看它的主节点反应:

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

    解读乔新亮的《看透本质:研发出了生产事故,到底要不要罚钱?》

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

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

    模拟主节点挂掉

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

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

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

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

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

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

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

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

数据存储简单分析

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

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

存储数据的过程,如下:

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

具体过程如下:

简要说明:

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

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

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

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

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

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

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

加节点

这里进行节点扩展,加一个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-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数据库,其他数据库不支持等等;所以使用要注意哦,后续抽时间单独整理一篇注意事项吧,篇幅有点长,不继续聊啦; 下篇说说熟悉的缓存穿透、缓存击穿、缓存雪崩吧;

一个被程序搞丑的帅小伙,关注"Code综艺圈",跟我一起学~~~

手把手教你在容器服务 TKE 中使用动态准入控制器

相关推荐

发表评论

路人甲

网友评论(0)