Redis-cluster:去中心化,中间件,集群中任意节点平等,任一节点可获得全局的数据
Redis-cluster 拓扑图:
架构演变及 cap 理论:
单机 Redis 属于 cp 模型。
Redis-cluster 属于 ap 模型
Redis-cluster 核心参数:
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 50000(毫秒)
cluster-migration-barrier 1
cluster-require-full-coverage no
cluster-slave-validity-factor
(node-timeout * slave-validity-factor) + repl-ping-slave-period
Redis-cluster 数据分布:预分槽(slot)
预分配 16384(slot), 根据 crc16(key) mod 16384的值,决定key 存放在哪个 slot里。
预分槽的方案介于“硬Hash”和“一致性Hash”之间,牺牲了一定的灵活性,但相比“一致性Hash“,数据的管理成本大大降低
Redis-cluster M-S
Redis-cluster 采用 一主多从
集群完整写的步骤:
1. client 写数据到 master
2. master 告知 client “ok”
3. master 同步数据到 slave
存在风险:
第二步骤成功后, mater crash,照常主从数据不一致
Redis-cluster 解决了 我们什么问题?
以前:
1. redis cpu 使用率>80%, 拆分redis实例,修改代码,指向新的redis实例。
2 redis 内存使用超过标准,继续拆分实例!
3 redis 流量增长,拆!
4. 单实例的高可用问题。
现在:
只需要 分配一组新的redis实例 加入 cluster, 迁移 slot 即可解决 资源 使用率问题。
Redis-cluster缺点:
1. 无法查看 几号 slot 里 存有什么类型的keys,只能查看实例里存有多少slot 号。
2. 当 redis-cluster 中 一组节点全部挂掉, 将 丢失 指向 已经挂掉节点的 keys。 (根据 crc16算法)
Redis-cluster 无法处理的问题:
A. 在遇到 被爬虫,强刷部分模块, 容易出现 redis 线程上涨,堵塞 响应请求, 其根因是 存储的redis key不合 理.
B. 部分hash key 存的过大,单个key里 存储数据 超过1W。降低 redis 响应时间。
C. 程序逻辑问题, 导致 redis 实列 频繁刷新 部分业务key.
D. 程序设计漏洞。
cluster经典架构
节点:
节点(Node)
一个集群由一个或多个节点组成,其中主节点(master)负责储存键值对数据,而从节点(slave)则负责复制主节点。
注意:从节点不提供任何读写操作
分片:
分片(Sharding)
集群将整个数据库分为16384(2 的 14 次方)个槽(slot)
每个主节点可以负责处理0 个至 16384 个槽
注意:集群只有在所有槽位均有主节点处理时,才能进入上线状态并处理数据命令
槽位计算方式
命令执行:
槽位正确与槽位不正确
槽位正确:命令处理的键所在的槽,正好由接收命令的节点负责
槽位不正确:接收命令的节点并不包含键所在的槽位
槽位正确:
槽位不正确:
键 date 所在的槽 2022 并非由节点 7001 负责,7001向客户端返回Redirection。
客户端根据Redirection的指引,转向至节点 7000,并重新发送命令。
Redirection的实现
Gossip协议内部通信
Redirection的实现之槽表(Slot table)
节点在接收到命令请求时,会通过槽表检查键所在的槽是否由本节点处理:
如果是的话,那么节点直接执行命令;
如果不是的话,那么节点就从槽表里面提取出正确节点的地址信息,然后返回客户端转向错误。
Failover
集群中三个负责处理命令的主节点标记7000出现SDOWN