Redis集群Cluster

  Redis Cluster 是社区版推出的 Redis 分布式集群解决方案,主要解决 Redis 分布式方面的需求,比
如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster 能起到很好的负载均衡的目的。
Redis Cluster 集群节点最小配置 6 个节点以上(3 3 从),其中主节点提供读写操作,从节点作为
备用节点,不提供请求,只作为故障转移使用。


  Redis Cluster 采用虚拟槽分区所有的键根据哈希函数映射到 016383 个整数槽内,每个节点负责维
护一部分槽以及槽所映射的键值数据

原理

 redis-cluster设计 Redis-Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都
和其他所有节点连接。

  其结构特点:

  1、所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

  2、节点的fail是通过集群中超过半数的节点检测失效时才生效。

  3、客户端与redis节点直连,不需要中间proxy.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

  4redis-cluster把所有的物理节点映射到[0-16383]slot上(不一定是平均分配),cluster 负责维护node<->slot<->value

  5Redis集群预分好16384个桶,当需要在 Redis 集群中放置一个 key-value 时,根据CRC16(key) mod 16384的值,决定将一个key放到哪个桶中。

     
a.redis cluster节点分配 现在我们是三个主节点分别是:A, B, C 三个节点,它们可以是一台机器上的
  三个端口,也可以是三台不同的服务器。那么,采用哈希槽 (hash slot)的方式来分配16384slot
  话,它们三个节点分别承担的slot 区间是:
    节点A覆盖05460;
    节点B覆盖546110922;
    节点C覆盖1092316383.
    获取数据: 如果存入一个值,按照redis cluster哈希槽的算法CRC16('key')384 = 6782。 那么就
  会把这个key 的存储分配到 B 上了。同样,当我连接(A,B,C)任何一个节点想获取'key'这个key时,
  也会这样的算法,然后内部跳转到B节点上获取数据
  新增一个主节点: 新增一个节点Dredis cluster的这种做法是从各个节点的前面各拿取一部分slot
  到D上,我会在接下来的实践中实验。大致就会变成这样:
    节点A覆盖1365-5460
    节点B覆盖6827-10922
    节点C覆盖12288-16383
    节点D覆盖0-1364,5461-6826,10923-12287
  同样删除一个节点也是类似,2移动完成后就可以删除这个节点了。
b.Redis Cluster主从模式 redis cluster 为了保证数据的高可用性,加入了主从模式,一个主节点对应
  一个或多个从节点,主节点提供数据存取,从节点则是从主节点拉取数据备份,当这个主节点挂掉后,
  就会有这个从节点选取一个来充当主节点,从而保证集群不会挂掉
  上面那个例子里, 集群有ABC三个主节点, 如果这3个节点都没有加入从节点,如果B挂掉了,我们就无法
  访问整个集群了。ACslot也无法访问。
  所以我们在集群建立的时候,一定要为每个主节点都添加了从节点, 比如像这样, 集群包含主节点AB
  C, 以及从节点A1B1C1, 那么即使B挂掉系统也可以继续正确工作。
  B1节点替代了B节点,所以Redis集群将会选择B1节点作为新的主节点,集群将会继续正确地提供服
  务。 当B重新开启后,它就会变成B1的从节点。
  不过需要注意,如果节点BB1同时挂了,Redis集群就无法继续正确地提供服务了。

 

优点:
无中心架构;
数据按照 slot 存储分布在多个节点,节点间数据共享,可动态调整数据分布;
可扩展性:可线性扩展到 1000 多个节点,节点可动态添加或删除;
高可用性:部分节点不可用时,集群仍可用。通过增加 Slave standby 数据副本,能够实现故
障自动 failover,节点之间通过 gossip 协议交换状态信息,用投票机制完成 Slave Master 的角
色提升;
降低运维成本,提高系统的扩展性和可用性。


缺点:
Client 实现复杂,驱动要求实现 Smart Client,缓存 slots mapping 信息并及时更新,提高了开发
难度,客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 相对成熟,异常处理部分还不完
善,比如常见的“max redirect exception”
节点会因为某些原因发生阻塞(阻塞时间大于 clutser-node-timeout),被判断下线,这种
failover 是没有必要的。
数据通过异步复制,不保证数据的强一致性。
多个业务使用同一套集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的
情况。
Slave 在集群中充当冷备,不能缓解读压力,当然可以通过 SDK 的合理设计来提高 Slave 资源的
利用率。

原文地址:https://www.cnblogs.com/lemon-flm/p/15205097.html