Redis Enterprise 的线性扩展

Redis Enterprise 已经过 基准测试 ，展示了真正的线性扩展——从 6 个 AWS EC2 实例的 1000 万 ops/秒扩展到 18 个 AWS EC2 实例的 3000 万 ops/秒。如果 Redis 服务器达到其可承受的读/写次数上限，有多种方法可以扩展您的数据库

• 扩展分片和节点
• 扩展代理
• 使用开源集群 API 实现真正的线性可扩展性
• 使用 'replica-of' 功能通过读取副本扩展“读取”操作

扩展分片和节点

Redis Enterprise 的重新分片机制基于 Redis 复制。每当需要向外扩展分片时，Redis Enterprise 集群就会启动另一个 Redis 实例，并将原始分片的一半哈希槽复制到新实例。一旦新分片填充完毕，代理会将流量发送到这两个分片，这对应用程序来说是完全透明的。

扩展数据库分片有两种方式

1. 向上扩展，即在不向集群添加节点的情况下向数据库添加分片。当集群中存在足够的未利用容量时，此场景非常有用。

向上扩展

2. 向外扩展，即向 Redis Enterprise 集群添加一个或多个节点，进行重新平衡，然后重新分片数据库。如果您的集群需要更多物理资源来扩展数据库，此场景非常有用。

扩展代理

默认情况下，在 Redis Enterprise 集群上创建的每个数据库都使用一个冗余代理进行操作。尽管代理效率极高，并且在适度的云实例上运行时通常可以处理超过 100 万 ops/秒，但在某些情况下，需要扩展代理以应对网络带宽或每秒数据包限制。Redis Enterprise 允许您在不更改应用程序代码的情况下，跨集群的多个节点扩展代理。Redis 客户端可以使用 DNS 循环赛来选择每次创建新连接时要使用的代理。

此外，为了优化跨集群节点的网络流量，Redis Enterprise 根据代理配置选择分片放置策略。当使用单个代理配置时，Redis Enterprise 会尝试在每个节点上放置尽可能多的分片（这也被称为 密集 配置）。当使用多代理配置时，集群的分片放置策略将基于 稀疏 配置。

扩展代理

使用开源集群 API 实现真正的线性可扩展性

Redis Enterprise 支持开源 (OSS) 集群 API，以便无论集群规模如何，客户端与集群之间只需一次网络跳转。这样，您的客户端就可以使用 OSS 集群协议了解分片在集群节点上的实际位置，如下所述

使用 OSS 集群 API 进行扩展

• 从 Redis 客户端的角度来看，每个代理代表一个哈希槽 (HS) 范围，该范围等于代理所在节点上主分片服务的所有哈希槽的总和。换句话说，从客户端的角度来看，代理代表了一个扮演主角色的大型 Redis 实例。
• 与 OSS 集群一样，客户端（标准的 OSS 客户端）根据键值项的键和 Redis 集群哈希函数将请求发送到相关的代理。
• 请求到达代理后，通过应用相同的哈希函数将其转发到节点上的相关分片。
• 在集群拓扑发生变化（即分片迁移、主/从故障转移等）时，代理会更新其管理的哈希槽，并在必要时将客户端请求重定向到集群中的另一个节点（使用 MOVED 响应）。

使用 OSS 集群 API 时，Redis Enterprise 以真正的线性方式进行扩展。 下图总结了 一系列 基准测试的结果

使用 'replica-of' 功能通过读取副本扩展“读取”操作

Redis Enterprise 允许您通过创建另一个数据库（在同一集群上），并使用“replica-of”功能将其作为原始数据库的读取副本，来扩展您的读取操作。您的读取副本被视为一个完全不同的数据库，并且可以配置不同数量的分片以及不同的可用性或持久性特征。您可以创建多个读取副本，或者仅增加现有读取副本中的分片数量，以进一步扩展您的读取操作。

使用读取副本扩展“读取”操作

下一节  ►  高可用性 Redis