Java教程

选译:Reids 集群规格

本文主要是介绍选译:Reids 集群规格,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

Redis 集群目标

  • 高性能:可线性伸缩到1000个节点,无代理通信,使用异步复制,不对值执行merge操作。

  • 一致性:可接受程度内的写安全。对于连接到主节点中”大多数“的客户端,系统会最大程度保留他们的写入。

  • 可用性:当主节点中”大多数“可达,且每个不可达的主节点至少有一个可达的副本,集群能够在分区中存活。

    副本迁移:一个副本都没有的主节点,可以从其他拥有多个副本的主节点接收一个副本。

子集实现

Reids 单机版支持的单键命令,Reids 集群也支持。

对于复杂的多键命令,如果这些键都被哈希到相同的槽,Reids 集群也支持。

Reids 集群支持"hash tag"的概念,用来强制某些键存储到同一个哈希槽。

Reids 集群不支持多个数据库,只有0号数据库。

服务端和客户端在 Reids 集群中扮演的角色

  • 集群节点负责承载集群的数据和状态,包括把键映射到正确的节点。
  • 集群节点可以相互发现,探测不能工作的节点。当故障发生时,为了能够继续操作集群,集群节点可以把副本提升为主节点。
  • 集群节点使用 TCP 总线、二进制协议相互通信,也叫集群总线。
  • 为了发现新节点,集群节点之间使用 gossip 协议广播集群信息。使用 ping 包确认其他节点正常工作,使用集群消息通知特定的条件。
  • Pub/Sub 消息通过集群总线广播到整个集群。
  • 系统管理员执行手动故障转移也是通过集群总线编排实现。
  • 集群节点不代理请求,使用重定向错误-MOVE或-ASK可以把客户端重定向到其他节点。理论上,客户端可以向任意集群节点发送请求,但根据需要,客户端可能会被重定向。客户端不必须保存集群的状态,但客户端可以缓存键和节点之间的映射关系,合理地提升性能。

写安全

  • 集群节点之间使用异步复制,以最后被选中的主节点数据集为准,覆盖其他副本的数据(如果有差异)。发生分区的期间,会有一个时间窗口,期间的写入可能会丢失。

  • 被分区中的大多数所接受、确认的写入,在故障期间,写入丢失的例子:

    1. 写入已经被主节点接受,客户端收到回复(确认),但写入异步复制到副本失败。等待足够久的时间后,其中一个副本被提升为主节点。

    2. 主节点因为分区而不可达,被其中一个副本代替,一段时候后恢复可达,然后旧的主节点被转换为副本。客户端因为缓存了路由表(键-节点),在旧的主节点被转换为副本之前,向它写入了数据。

  • 当一个主节点不能被主节点中的大多数访问,持续时间达到 NODE_TIMEOUT,主节会被其副本替换。如果在 NODE_TIMEOUT 之前分区被解决,没有写入丢失,否则期间的写入会丢失。(因为分区)如果主节点中的少数在持续 NODE_TIMEOUT 时间之后,仍然无法连接上主节点中的大多数,主节点中的少数进入拒接写入的状态。

性能

  • redis 集群节点不会把命令转发到负责该命令键的节点,但是会重定向客户端到正确的节点。
  • 客户端最终可以得到键和节点之间的正确映射关系,直接向正确的节点发送命令。
  • 因为使用了异步复制,客户端不会等待其他节点的写入确认,除非使用WAIT命令。
  • 集群性能根据主节点的数量线性伸缩。通常客户端和节点保持持久链接,延迟也不会增加。
  • 高性能,高伸缩性,弱数据安全,弱可用性,是 redis 集群的主要目标。

键分布式模型

键空间被划分为16384个槽,集群中的每个主节点负责16384个槽中的一个子集。

HASH_SLOT = CRC16(key) mod 16384

键 hash tag

hash tag 保证多个键被哈希到同一个槽。

def HASH_SLOT(key)
    s = key.index "{"
    if s
        e = key.index "}",s+1
        if e && e != s+1
            key = key[s+1..e-1]
        end
    end
    crc16(key) % 16384
end

重定向和重分片

MOVED 重定向

  • redis 客户端可以向任意节点发送请求,包括副本节点。如果请求是可接受的(单键请求,或者是多键请求但键都在同一个槽),节点会去查找负责(键所属)哈希槽的节点。如果哈希槽正好由当前节点负责,直接处理请求,否则查找内部映射表(槽->节点),回复 MOVED 错误:

    GET x
    -MOVED 3999 127.0.0.1:6381
    

    3999为键所属槽,127.0.0.1:6381为能处理此请求的实例IP和端口。

  • 客户端需要重新发送请求到对应的实例。

  • 客户单应该记住3999号槽由127.0.0.1:6381实例负责。下次要发送请求时,计算键所在哈希槽,有更大几率直接选中正确的节点。

  • 另一个方案是,当收到MOVED重定向时,使用 CLUSTER NODES 或者 CLUSTER SLOTS 命令查询集群内所有槽->节点的映射关系。

ASK 重定向

  • 案例:8号槽由节点A负责,现在要把所有属于8号槽的键(可能有很多),由节点A迁移到节点B,键迁移过程中,8号槽仍然由节点A负责,直至所有键迁移完成后,8号槽开始由节点B负责。
  • 键迁移过程中,可能一部分键还在旧节点A上,一部分键已经在新节点B上。
  • 客户端向节点A请求8号槽的foo键,此时迁移还在进行中,但foo键已经迁移到新节点B,A节点给客户端返回ASK重定向,重定向至节点B。
  • 客户单收到至节点B的ASK重定向后,先向节点B发送ASKING命令,随后重新向节点B发送foo键的请求。
  • 如果节点B收到8号槽foo键的请求,但是前面没有ASKING命令,节点B不作处理,给客户端返回MOVED重定向,重定向至节点A。因为迁移还未完成,8号槽仍然由节点A负责。
  • 客户端不应该更新本地槽->节点的映射,错误地认为8号槽已经由节点B负责。随后关于8号槽其他键的请求,客户端仍要先发送到节点A,收到明确的ASK重定向后才能重新发送(到节点B)。
  • 所有键迁移完成后,8号槽开始由节点B负责,客户端向节点A请求8号槽键,会被MOVED重定向到节点B。

客户端首次连接&重定向的处理

下列情况下,客户端通常需要完整地获取所有槽->节点的映射:

  • 启动初始化
  • 收到MOVED重定向

参考 CLUSTER SLOTS 命令。

多键操作

当某个槽正处于重新分片的过程中,属于此槽的键是不可用的。

用副本节点伸缩读操作

连接可以开启只读模式,暗示客户端可以接受“过时”的数据,对正在进行中的写入不感兴趣。

参考 READONLY 命令。

这篇关于选译:Reids 集群规格的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!