中间件 | Redis - [集群]

§1 集群解决的痛点

  • 容量不够
  • 并发写操作的分流
  • 节点宕机重启切换主节点导致的 ip 地址变化

§2 集群方案

代理主机
类似 nginx,选用一台主机作为代理主机
代理主机对每组 redis 主从复制进行反向代理
为了健壮,代理主机也需要是集群的
在这里插入图片描述

无中心化集群
redis 3.0 后出现,目前通用集群方案,如下图

  • 主节点之间没有从属关系
  • 每个主节点都可以作为集群入口
  • 每个主节点存储一部分数据
  • 部分主节点挂掉不影响主节点功能

在这里插入图片描述

§3 无中心化集群搭建

最佳实践

  • 主节点分别使用不同的主机
  • 同组主从节点分别使用不同的主机

节点配置文件
注意打开 bind 配置

# inclue 引入原始配置文件
# 相当于用原始配置文件作为模板,然后进行增量配置
include /etc/redis/redis.conf

prot 6379
pidfile /var/run/redis_6379.pid
dbfilename dump6379.rdb

dir "/redis/cluster01"
logfile "/redis/cluster01/reis_err_6379.log"

# 集群配置
cluster-enabled yes
cluster-config-file nodes-6379.conf
# 节点失联时间
cluster-node-timeout 15000

启动节点
redis-server redis3679.conf

组建集群
cd /opt/redis-6.0.8/src
redis-cli --cluster create --cluster-replicas 1 192.1658.3.11:6379 192.168.3.11:6380 [...所有主机列表]

docker 版集群
参考 云原生 | Docker - [Redis 集群搭建]

§4 可视化工具

Redis Assistant (看上去很不错,但收费)
Another Redis Desktop Manager

无法连接时,查看防火墙相关配置,参考 firewall-cmd 指令
在这里插入图片描述

§5 集群指令

§5.1 cluster info [查看集群状态]

在这里插入图片描述

§5.2 cluster nodes [查看集群节点状态]

在这里插入图片描述

§5.3 redis-cli --cluster create[组建集群]

`redis-cli --cluster create --cluster-replicas 1 […所有主机 ip:端口 列表]``

  • –cluster-replicas 用于设置每个主节点备份的个数
§5.4 redis-cli --cluster ckeck[查看集群状态]

在这里插入图片描述

§5.5 redis-cli --cluster add-node[增加集群节点]

添加主节点

redis-cli --cluster add-node 新主节点Ip端口 集群中节点Ip端口

添加从节点

redis-cli --cluster add-node 新从节点Ip端口 集群中节点Ip端口 --cluster-slave  --cluster-master-id 主节点node-id
§5.6 redis-cli --cluster reshard[重新分配 hash 槽(手动)]
redis-cli --cluster reshard 集群中节点Ip端口
§5.7 redis-cli --cluster rebalance [重新分配 hash 槽(自动)]
redis-cli --cluster rebalance  集群中节点Ip端口

当每个节点的 key 都很少时,使用此命令无效,并提示

*** No rebalancing needed! All nodes are within the 2.00% threshold.
§5.8 redis-cli --cluster del-node [移除集群节点]
redis-cli --cluster del-node 集群中节点Ip端口
§5.9 cluster keyslot [计算 key 的插槽值]
cluster keyslot key_name
§5.10 cluster countkeysinslot[查看指定插槽中 key 的个数]
cluster countkeysinslot slot_no

只能查看当前节点的插槽

§5.11 cluster getkeysinslot[查看指定插槽中 key 的个数]
cluster getkeysinslot slot_no n

从 slot_no 号 hash 槽上获取前 n 个 key

§6 集群带来的问题

每个主节点并不包含所有数据
集群中的主节点分别负责一部分数据(key)的存储
具体一个 key 存放在哪个节点是由 hash 槽 算法决定
hash 槽相关说明参考 微服务架构 | 分布式存储 -算法

多 key 操作指令会受到影响
集群模式下,一口气操作多个 key 的指令会受到影响,比如 mset
因为涉及到的多个 key 可能经过计算 hash 槽后,分属于不同的主节点
可以通过对 keys 设置组来解决,如 mset k1(kk) v1 k2(kk) v2 k3(kk) v3

lua 脚本执行受到影响
lua 脚本在执行过程中很有可能遇到跨节点的操作
即,所有可能重定向节点 redirected 的操作都会受到影响

不同节点配置差异产生的问题
主要集中在两方面

  • 通用配置不一致
    比如节点配置了不同的 maxmemory
    某个从节点正常,但另一从节点因为此配置过小导致淘汰了大批 key
  • 数据结构优化不一致
    hash-max-ziplist-entries,配置了 hash 的压缩表大小

主从复制带来的问题

  • 挂载节点时全量复制
    比如加入节点时不可避免的全量复制,
    • 使用小节点,比如 2G
    • 访问低谷进行扩容,比如凌晨
  • 指令缓冲区不够导致时全量复制
    持久化过程中会用到指令缓冲区,用来缓冲从开始持久化到结束用户线程提交的新指令
    持久化结束后,会比较当前指令 offset,若在缓冲区队列中,则进行增量同步,否则全量复制
    • 缓冲区大小由 rel_backlog_size 指定,默认 1M,可以加大此配置
  • 全量复制风暴
    通常由主节点重启,众多从节点同时做全量更新导致
    可以通过修改拓扑优化,主从节点间增设从节点,即主节点只同步一个从节点,其余的同步由此节点复制
    但,比较新的集群中不会遇到此问题,因主节点挂掉后会由其原本的从节点补位

新老环境的迁移问题
如果有陈年老系统,可能最早不是使用的 redis 集群
而迁移需要保证数据的完整性,只能局限于整体迁移时,难度较大

§7 故障恢复

主节点宕机

  • 此主节点的从节点自动升为主节点
  • 原主节点恢复后自动成为新主节点的从节点

一段 hash 槽节点全部宕机

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值