Redis——Cluster

为什么需要集群？

• 高并发：
• 大数据：

• 集群分区方式

  
  数据分区

  • 顺序分区

  • 哈希分区

    • 节点取余分区

      • 客户端分片：进行哈希+取余

        
        节点取余
      • 扩容：
        存在问题：当需要扩充节点的时候，需要进行大量的数据迁移（解决方案：翻倍扩容，会降低数据的迁移量）
        图片.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个槽都有节点在处理时，集群是处于上线状态的，相反的，只要有一个槽没有得到处理，那么集群处于下线状态。因为我们集群中的三个节点都没有在处理任何槽，所以集群是下线状态的。

• 集群搭建（原生安装）
  1. 配置开启节点
  2. 节点握手
  3. 分配槽
  4. 分配主从关系
     关于安装配置的方法大家自己查询即可，这里只是为了理解集群的架构，需要注意的是这种方法不太常用，还是推荐Redis官方的Ruby安装（需要注意服务器绑定的地址，127.0.0.0会存在回环问题，建议绑定外网地址）。
• 集群伸缩
  集群伸缩实际上就是=槽和数据在节点之间的移动
  伸缩原理
  • 集群扩展过程
    • 准备新节点
    • 加入集群
    • 迁移槽和数据
  • 集群收缩过程
    • 下线迁移槽（假设持有槽）
    • 通知其他节点忘记该节点
    • 关闭节点
• 客户端路由
  • moved重定向
    一个 Redis 客户端可以自由地向集群中的任意节点（包括从节点）发送查询。接收的节点会分析查询，如果这个命令是集群可以执行的（就是查询中只涉及一个键），那么节点会找这个键所属的哈希槽对应的节点。

如果刚好这个节点就是对应这个哈希槽，那么这个查询就直接被节点处理掉。否则这个节点会查看它内部的 哈希槽 -> 节点ID 映射，然后给客户端返回一个 MOVED 错误。

moved

• ask重定向
  当我们使用 MOVED 的时候，意味着我们认为哈希槽永久地被另一个不同的节点处理，并且希望接下来的所有查询都尝试发到这个指定的节点上去。而 ASK 意味着我们只要下一个查询发送到指定节点上去。
  图片.png
  两者都是客户端重定向；
  moved：槽已经确定迁移，以后对该槽的请求都发送到目标节点；
  ask：槽还在迁移当中，只有这一次对该槽的请求都发送到目标节点，以后还是请求源节点；