Redis系列之Redis Cluster

概述

Redis 2.8版本发布稳定版Redis Sentinel，不过Sentinel集群版存在一些问题：

• 高可用性：Sentinel集群对Redis既有的主从集群提供有限的高可用保障；
• 在线扩容：节点下线，触发选举，选举涉及两个阶段；新增节点，数据迁移过程麻烦。

对比Redis Sentinel

Redis Sentinel，即Redis 哨兵集群，区别如下：

• 集群架构
  Redis Sentinel是一主多从， Redis Cluster是多主多从
• 数据一致性
  • Redis Sentinel：由于没有分片，Sentinel对数据一致性的保障会更好一些，结构相对简单，脑裂问题会相对少一些，主从之间的数据一致性问题相对简单。主从切换后，存在数据一致性的小概率问题（例如主节点故障前的未同步数据丢失），但整体上保持一致性较好；
  • Redis Cluster：由于数据分片，Redis Cluster在发生主从切换和网络分区时，可能存在数据不一致的风险。
• 扩展性
  • Redis Sentinel：扩展性差，受限于单机性能和存储能力。尽管可以通过添加从节点分担读请求，但所有写操作仍然只能在主节点进行；
  • Redis Cluster：扩展性好，可通过加节点来扩展存储容量和处理能力。每个节点只负责一部分数据，可实现负载均衡。
• 适用场景
  • Redis Sentinel：适用于中小型应用，数据量和请求量相对较小的场景，或者不需要水平扩展的情况；
  • Redis Cluster：适用于大规模应用，需要处理大数据量和高并发的场景，且需要水平扩展能力。
• 运维
  • Redis Sentinel：运维复杂度较低，适合中小规模的Redis部署。需要维护Sentinel实例，并且在节点增加或减少时，配置相对简单；
  • Redis Cluster：运维复杂度较高，适合大规模的Redis集群。节点的增删、分片的重新分配、集群状态的维护等都需要较高的运维能力。

简介

从Redis3.0开始，提供Redis Cluster集群支持，用于在多个Redis节点间共享数据，提高服务可用性。Redis Cluster采用去中心化结构，无需proxy代理，应用可以直接访问集群中的数据节点。

Redis Cluster要求至少需要3个Master才能组成一个集群，同时每个Master至少需要有一个Slave节点。各个节点之间保持TCP通信。当Master发生宕机，Redis Cluster自动会将对应的Slave节点提拔为Master，来重新对外提供服务。

Redis Cluster功能：负载均衡，故障切换，主从复制。

Redis Cluster集群，内置数据自动分片机制，集群内部将所有的key映射到16384个Slot中，集群中的每个Redis Instance负责其中的一部分的Slot的读写。集群客户端连接集群中任一Redis Instance即可发送命令，当Redis Instance收到自己不负责的Slot的请求时，会将负责请求Key所在Slot的Redis Instance地址返回给客户端，客户端收到后自动将原请求重新发往这个地址，对外部透明。一个Key到底属于哪个Slot由crc16(key) % 16384决定。

通信

集群机器等数据信息通常有两种方式：

• 集中式：把集群信息保存在配置中心。好处：元数据的更新和读取，时效性非常好，一旦元数据出现变更，立即就更新到集中式的存储中，其他节点读取时立即就可以感知到。缺点：所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力
• Gossip：好处：元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，降低压力。缺点，元数据更新有延时，可能导致部分操作有滞后。

通信的端口就是本身Redis监听端口+10000。假如监听端口6379，通信端口就是16379。

Gossip