Redis深度历险-集群

主从同步

• CAP
  • C：Consistent 一致性
  • A：Availability 可用性
  • P：Partition tolerance 分区容忍性
• 众所周知：CAP在网络分区发生时，一致性和可用性是两难全，具体可以查看此篇文章第六章：CAP理论
• Redis保证的是AP，加上最终一致性
  • 当发生网络分区时，主节点依旧对外提供服务，网络恢复后，从会追赶主，到达数据最终一致性
• Redis同步的是指令流，使用环状列表存储指令
• Redis使用的主从异步复制

Sentinel哨兵

• 自动版的反客为主
• 使用哨兵主动监测，发现主机掉线后，重新组织评选，选出一个新的主机。原本的主机重新上线后会作为从机和新主机建立复制关系
• Redis的主从异步复制，会造成消息丢失

Sentinel的基本用法

• 客户端使用Sentinel就是先通过Sentinel发现主从节点地址，从而建立连接来进行操作Redis的数据
• 并且客户端在连接时就会监测主节点地址是否变更，连接池建立连接时就会查询主节点地址，再和内存中的主节点地址进行比较，一旦发现变更，那么所有的连接都会关闭，因为这代表之前的连接的机器已经掉线了
  • 如果主机没有掉线，而只是被降级为了从节点，那么所有的修改指令会抛出ReadonlyError，并且处理命令会捕获这个异常，一旦出现这个命令那么就会将所有的连接都关闭，如果只是读，那么不会抛出这个异常。

Codis 与 Cluster集群

• Codis是Redis集群方案之一。
  • 使用Go语言开发，是一个转发代理中间件，同样使用Redis协议对外提供服务，当客户端向Codis发送指令时，Codis会负责将指令转发到Redis实例执行，将结果返回给客户端
    
• Codis集群代价
  • 不能使用事务
  • key的value不宜过大：迁移时是全部迁移，如果为hash，那么可能带来卡顿
  • 多了一个Codis中转，那么网络开销会更大
  • 多了zookeeper的运维代价：Codis集群的配置中心使用Zookeeper
• Cluster是Redis作者自己提供的Redis集群方案
  • Cluster是去中心化的

Cluster使用的技术有：

• 槽位
  • 将数据划分为16382个槽位，分别由三个节点组成一个集群，每个节点所管理的槽位多少可能不同
    • 不需要额外的分布式配置中心来管理槽位的信息
    • 客户端连接集群的时候，会得到一份集群的槽位配置信息
  • 当服务端发现客户端发送了错误的指令，因为这个key所在的槽并不归自己管理，会向客户端发送一个特殊的挑转指令
    ![[Pasted image 20231114194454.png]]
    3999代表key的槽，后面的ip和端口表示重新请求的地址
• 数据迁移
  • Redis提供了redis-trib供我们手动调整槽位分配情况
    • 流程：从源节点获取内容->存到目标节点->删除源节点的内容
    • 在执行这个流程时，源节点的主线程会处于阻塞状态，指定key删除
      • 如果出现网络故障，并且正在迁移，那么重启后会提示用户继续迁移
• 槽位移动感知
  • Cluster的两个特殊命令：MOVED，ASKING
  • MOVED：用来纠正槽位的，如果将指令发送到错误的服务器上，那么会由其发送MOVED来纠正槽位，正如上面的那张图
  • ASKING：用来临时纠正槽位，当发送一个数据正在迁移，那么指令会先发到旧节点，如果旧节点存在数据就返回，如果没有，旧通知客户端去新节点拿数据，这时就会使用ASKING
• 容错
  • Cluster集群方案可以为每个节点搭建主从，当主节点故障时，可以类似于哨兵将从节点转换为主节点提供服务，当没有从节点可用时，那么整个集群都会处于不可用状态
• 网络抖动
  • Cluster提供了cluster-node-timeout来表示一个节点最多可以失联多久，避免网络波动带来的频繁的主从切换
• 可能下线(PFail)与确定下线(Fail)
  • 一个节点任务某一节点失联不算失联，需要进行“协商”，协商完成后通过Gossip协议来广播自己的状态以及改变对集群的“认知”
• 集群变更感知
  • 当目标节点挂掉，客户端会抛出ConnectionError，并且随机挑一个节点重试，由这个节点返回MOVED重新跳转
  • 当运维手动更改集群信息，主节点切换，并且旧主节点删除后，如果发生请求，会收到ClusterDown错误，客户端需要关闭所有连接和槽点映射关系表，向上抛错