10M Ops/sec @ 1msec 延迟，仅需 6 个 EC2 节点

我们新发布的 Redis Enterprise 5.0 引入了对开源 (OSS) 集群 API 的支持，该 API 允许 Redis Enterprise 集群通过仅添加分片和节点来实现无限、线性地扩展。OSS 集群 API 依靠客户端的智能来决定将请求发送到哪个分片/节点，这取决于键值项的键部分以及客户端和集群之间共享的哈希函数。本文解释了 Redis Enterprise 如何使用 OSS 集群 API，并验证了其无限的线性性能可扩展性。

对于不熟悉 Redis Enterprise 架构的用户，我们先简要介绍一下背景知识

Redis Enterprise 架构概述

在 Redis Enterprise 中，集群是一组云实例、虚拟机/容器节点或裸金属服务器，允许您在共享的内存池中创建任意数量的 Redis 数据库（在 Redis Enterprise 术语中，数据库是管理跨多个 Redis 分片/实例的整个数据集的实体。不要将其与每个 Redis 实例中可以使用 Redis SELECT 命令进行键空间分段的数据库混淆）。该集群采用对称的共享无状态架构，数据路径与控制 & 管理路径完全分离，主要包含以下组件：

• Redis 分片（数据路径）—— 担任主或从角色的 Redis 实例
• 零延迟代理（数据路径）—— 基于直通、多线程、无状态架构构建，负责隐藏集群复杂性、增强安全性（SSL、身份验证、DDoS 防护）和提升性能（无 TCP 开销、连接管理和流水线）
• 集群管理器（控制 & 管理路径）—— 由驻留在集群每个节点上的一组分布式进程构建。集群管理器负责集群配置活动、供应请求、资源管理和监控，同时充当资源看门狗，并完全卸载了由 Redis 分片管理集群中其他分片的健康状况或做出故障转移决策的任务

Redis Enterprise 集群中的数据库可以按以下任何一种配置创建：

凭借其强大的多租户技术，Redis Enterprise 集群可以在同一集群资源上以完全隔离的方式管理多种不同类型的数据库。

集成 OSS 集群 API 的 Redis Enterprise

要利用新的 OSS 集群 API，在使用 Redis Enterprise API 创建数据库时应使用以下属性：

• “shards_placement”: “sparse” – 将分片分布在 Redis Enterprise 集群节点上
• “proxy_policy”: “all-master-shards” – 为每个至少包含一个主分片的节点分配一个代理
• “oss_cluster”: “true” – 使数据库可通过 OSS 集群 API 访问

这将创建一个具有与下图所示相似属性的集群数据库

正如您所见

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

构建测试环境

考虑到这一点，我们决定在 AWS 上构建一个测试环境，以验证 Redis Enterprise 是否真的可以无限地、线性地扩展。由于我们计划进行一些严肃的负载测试，我们决定使用 EC2 m4.16xlarge 实例（64 核，256GB 内存）作为集群节点，并使用 c4.8xlarge 实例（36 核，60GB 内存）运行 memtier_benchmark，这是一个开源的多线程负载生成工具。

使用 memtier_benchmark 的多个实例是必需的，因为在许多情况下，单个 Redis Enterprise 节点可以处理的流量比单个 memtier_benchmark 实例能生成的流量大。这种方法还使我们能够避免单个 NIC 的网络带宽和每秒数据包限制，并且可以轻松地逐步（逐个实例地）增加流量负载。

这是我们最终设置的样子

• 6 个 m4.16xlarge 实例作为 Redis Enterprise 集群节点

• 8 个运行 memtier_benchmark 的 c4.8xlarge 实例

• 我们使用 Ubuntu Server 16.04 作为操作系统，并确保机器配置支持 增强型联网。所有实例都位于同一 VPC、可用区、网络子网和放置组中。

创建和调优集群数据库

我们使用 Redis Enterprise API 创建了一个包含 192 个分片的集群 Redis 数据库，使用以下参数：

{
"name": "api-benchmark",
"replication": false,
"port" : 12345,
"sharding": true,
"shards_count" : 192,
"version": "4.0",
"memory_size": 100000000000,
"type": "redis",
"oss_cluster":true,
"proxy_policy": "all-master-shards",>
"shards_placement": "sparse",
"shard_key_regex": [{"regex": ".*{(?.*)}.*"}, {"regex": "(?.*)"}]
}

> curl -k -X POST -u ":" -H "Content-Type: application/json" -d @create_db.json https://localhost:9443/v1/bdbs

我们通过将代理线程数设置为 24 来调优每个节点上的代理，以应对预期的负载

> rladmin tune proxy all max_threads 24
> rladmin tune proxy all threads 24

填充数据库并运行测试

我们使用了支持 OSS 集群 API 的新版本 memtier_benchmark，首先向数据库填充了大约 1000 万个项目，然后运行了测试。

以下是我们填充和基准测试阶段使用的 memtier_benchmark 参数：

• 键模式：我们对读写使用了统一的随机访问模式 (−−key-pattern=R:R)。
• 项目数：我们必须找到一种组合，以便尽可能均匀地填充和访问所有哈希槽。这是通过将请求数与每个槽的键范围相结合来实现的 (−−key-minimum=1 −−key-maximum=611 −−num_requests=40042496)。考虑到随机访问，在填充过程中可能会多次命中同一个键，这就是为什么我们执行的请求数超过了我们的目标 1000 万个项目。
• 数据大小：我们测试了 100B 和 500B 项目（值）大小。
• 写/读比例：我们测试了混合工作负载 (−−ratio=1:1)、只读工作负载 (−−ratio=0:1) 和只写工作负载 (−−ratio=1:0)。
• 流水线：我们在所有测试中使用了实际的流水线大小，即 −−pipeline=9。
• 客户端数和线程数：我们的 memtier_benchmark 实例创建的连接数等于线程数 (-t) 与每个线程的客户端数 (-c) 的乘积。在我们最终的设置中，8 台基准测试客户端机器中的每一台都运行 40 个客户端，分布在 12 到 15 个线程上，总共创建了超过 3000 个到集群的连接。

以下是一个 memtier_benchmark 命令行示例

> memtier_benchmark -s $DB_SERVER -p $DB_PORT
--pipeline=$PIPELINE_SIZE -c $NUM_CLIENTS -t $NUM_THREADS
-d $DATA_SIZE --key-minimum=$KEY_MIN
--key-maximum=$MAX_KEYS_PER_SLOT --key-pattern=R:R
--ratio=$WR_RATIO --run-count=1 --requests=$NUM_REQ
--out-file=$OUT_FILE --oss-cluster

测试结果

我们的最终设置在 Redis Enterprise 集群上运行了一个由 6 个节点组成的 192 分片数据库，并展示了出色的结果：以略高于 1 毫秒的延迟达到了每秒超过 1000 万次操作！以下是 Redis Enterprise UI 的截图

我们进行这项实验是为了验证 Redis Enterprise 的共享无状态架构能够凭借 Redis Enterprise 5.0 中引入的新 OSS 集群 API 实现线性扩展。我们的实验包括：

• 在单节点 Redis Enterprise 集群上对 32 分片数据库进行基准测试
• 在双节点 Redis Enterprise 集群上对 64 分片数据库进行基准测试
• 在 6 节点 Redis Enterprise 集群上对 192 分片数据库进行基准测试

我们发现在从 1 节点集群扩展到 6 节点集群时实现了线性性能可扩展性，如下图所示

对这些结果的深入分析表明，在从单节点集群扩展到双节点集群，然后扩展到 6 节点集群时，每个节点的吞吐量变化不超过 10%。我们认为，测试之间性能的这些变化可能与每次测试迭代中不同的资源条件（网络、虚拟机等）有关。

总结

随着 OSS 集群 API 的引入，Redis Enterprise 5.0 可以通过简单地向数据库添加分片和向集群添加节点来实现轻松的线性扩展，这一点已通过本次基准测试得到验证。我们计划继续打破数据库领域的性能记录，但我们希望在 re:invent 2017 上分享这一点，所以我们暂时止步于此。请持续关注！