Redis多机常用架构-cluster

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