为什么需要集群？
- 高并发：
- 大数据：
-
集群分区方式
数据分区顺序分区
-
哈希分区
-
节点取余分区
-
客户端分片：进行哈希+取余
节点取余 - 扩容：
存在问题：当需要扩充节点的时候，需要进行大量的数据迁移（解决方案：翻倍扩容，会降低数据的迁移量）
图片.png
-
-
一致性哈希分区
一致性哈希分区采用一致性哈希算法进行分区，由客户端计算并且提供一致性hash，基本步骤如下;- 客户端分片：进行哈希+（顺时针）优化取余
- 首先求出Redis服务器（节点）的哈希值，并将其配置到0～2的32次方的圆（continuum）上。
- 然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。
-
然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过2的32次方仍然找不到服务器，就会保存到第一台Redis服务器上。
一致性哈希算法 - 扩容
只影响邻近节点，但是还是存在数据迁移，使用翻倍扩容保证最小迁移数据和负载均衡
图片.png
-
-
虚拟槽分区（Redis-Cluster采用）
槽（slot）：每个预设虚拟槽映射一个数据子集，一般比节点数大，Redis集群的整个数据库被分成16384（0~16383）个槽，数据库中的每个键都属于这些槽中的一个。
虚拟槽分区
数据分布对比
Redis 集群：是一个通过分片（sharding）在多个Redis间节点间共享数据的分布式数据库方案，提供复制和故障转移功能。
- 节点
是组成Redis集群的基本元素，一个Redis集群包含多个节点。所有的主节点都负责 16384 个哈希槽中的一部分。当集群处于稳定状态时，集群中没有在执行重配置（reconfiguration）操作，每个哈希槽都只由一个节点进行处理（不过主节点可以有一个或多个从节点，可以在网络断线或节点失效时替换掉主节点）。-
节点属性：
节点ID（唯一）是用于在整个集群中标识每个节点。一个给定的节点可以在不改变节点ID的情况下改变 IP 和地址。集群能检测到 IP 或端口的变化，然后使用在集群连接（cluster bus）上的 gossip 协议来发布广播消息，通知配置变更。
每个节点都有其他相关信息是所有节点都知道的：- 节点的 IP 地址和 TCP 端口号。
- 各种标识。
- 节点使用的哈希槽。
- 最近一次用集群连接发送 ping 包的时间。
- 最近一次在回复中收到一个 pong 包的时间。
- 最近一次标识节点失效的时间。
- 该节点的从节点个数。
- 如果该节点是从节点，会有主节点ID信息。
-
集群拓扑结构
集群拓扑结构
Redis 集群是一个网状结构，每个节点都通过 TCP 连接跟其他每个节点连接。在一个有 N 个节点的集群中，每个节点都有 N-1 个流出的 TCP 连接，和 N-1 个流入的连接。 这些 TCP 连接会永久保持，并不是按需创建的。 -
节点握手
只有在两种方式下，一个节点才会认为另一个节点是集群中的一部分：- 当一个节点node发送CLUSTER MEET IP PORT命令，可以让node节点与指定节点进行握手，握手成功时，node节点就会被指定节点添加到他当前所在的集群中。
- 一个已被信任的节点能通过传播gossip消息让另一个节点被注册为集群中的一部分。也就是说，如果 A 知道 B，B 知道 C，那么 B 会向 A 发送 C 的gossip消息。A 收到后就会把 C 当作是网络中的一部分，并且尝试连接 C。 这意味着，只要我们往任何连接图中加入节点，它们最终会自动形成一个完全连接图。从根本上来说，这表示集群能自动发现其他节点，但前提是有一个由系统管理员强制创建的信任关系（MEET）。 这个机制能防止不同的 Redis 集群因为 IP 地址变更或者其他网络事件而意外混合起来，从而使集群更具健壮性。 当节点的网络连接断掉时，它会积极尝试连接所有其他已知节点。
简单来说，
1.Redis Cluster中的节点A发送MEET消息通知另外一个节点B，让节点B把节点A当做Cluster中的一员。
2.如果节点A认识节点B，节点B认识节点C，那么节点B可以发送包含节点C信息的MEET消息给节点A，从而节点A也认识节点C了，即节点A将与节点C建立连接。
-
- 槽分配
关于槽，上面已经说过了，假设我们现在使用cluster meet 搭建了一个三个节点的集群，但是呢，现在这个集群是处于下线状态的，为什么呢？
当数据库中的16384个槽都有节点在处理时，集群是处于上线状态的，相反的，只要有一个槽没有得到处理，那么集群处于下线状态。因为我们集群中的三个节点都没有在处理任何槽，所以集群是下线状态的。
- 集群搭建（原生安装）
- 配置开启节点
- 节点握手
- 分配槽
- 分配主从关系
关于安装配置的方法大家自己查询即可，这里只是为了理解集群的架构，需要注意的是这种方法不太常用，还是推荐Redis官方的Ruby安装（需要注意服务器绑定的地址，127.0.0.0会存在回环问题，建议绑定外网地址）。
- 集群伸缩
集群伸缩实际上就是=槽和数据在节点之间的移动
伸缩原理- 集群扩展过程
- 准备新节点
- 加入集群
- 迁移槽和数据
- 集群收缩过程
- 下线迁移槽（假设持有槽）
- 通知其他节点忘记该节点
- 关闭节点
- 集群扩展过程
- 客户端路由
- moved重定向
一个 Redis 客户端可以自由地向集群中的任意节点（包括从节点）发送查询。接收的节点会分析查询，如果这个命令是集群可以执行的（就是查询中只涉及一个键），那么节点会找这个键所属的哈希槽对应的节点。
- moved重定向
如果刚好这个节点就是对应这个哈希槽，那么这个查询就直接被节点处理掉。否则这个节点会查看它内部的 哈希槽 -> 节点ID 映射，然后给客户端返回一个 MOVED 错误。
moved
- ask重定向
当我们使用 MOVED 的时候，意味着我们认为哈希槽永久地被另一个不同的节点处理，并且希望接下来的所有查询都尝试发到这个指定的节点上去。而 ASK 意味着我们只要下一个查询发送到指定节点上去。
图片.png
两者都是客户端重定向；
moved：槽已经确定迁移，以后对该槽的请求都发送到目标节点；
ask：槽还在迁移当中，只有这一次对该槽的请求都发送到目标节点，以后还是请求源节点；
