使用仅 6 个 EC2 节点时的延迟为 1 毫秒，速率为 10M Ops/sec

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

对于那些不熟悉 Redis Enterprise 架构的人，让我们从一些简短的背景开始

简而言之，Redis Enterprise 架构

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

• Redis 分片（数据路径）——一个具有主角色或从属角色的 Redis 实例
• 零延迟代理（数据路径）——建立在端到端、多线程、无状态架构上，负责隐藏集群复杂性，增强安全性（SSL、验证、DDoS 保护），并提高性能（无 TCP、连接管理和流水线处理）
• 集群管理器（控制及管理路径）——由驻留在集群的每个节点上的一组分布式进程构建。群集管理器负责集群配置活动、供应请求、资源管理和监控，同时充当资源监视器，并将 Redis 分片在集群中管理其他分片或作出故障转移决策的任务完全转移出

Redis Enterprise 群集中的数据库可以在下面任何一个配置中创建

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

Redis Enterprise 与 OSS 群集 API

为了利用新的 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 RAM）用于集群节点，将 c4.8xlarge 实例（36 个内核、60GB RAM）用于运行 memtier_benchmark，一个开源多线程负载生成工具。

必须使用多个 memtier_benchmark 实例，因为在许多情况下一个 Redis Enterprise 节点可以处理比一个 memtier_benchmark 实例能产生的流量更多的流量。此方法还允许我们规避单个 NIC 的网络带宽和包每秒限制，并能轻松地按步骤（按实例）方式增加流量负载。

这是我们的最终设置

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

• 运行 memtier_benchmark 的 8 个 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://#:9443/v1/bdbs

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

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

填充数据库和运行测试

我们使用了支持 OSS 集群 API 的 memtier_benchmark，首先往数据库中填充大约 10 00万项，然后运行测试。

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

• 键模式: 我们对读和写使用了统一的随机访问模式（−−key-pattern=R:R）。
• 项数目: 我们必须找到一个方式，尽可能公平地填充和访问所有哈希槽。这是通过将请求数与每个槽的键范围相结合来实现的（−−key-minimum=1 −−key-maximum=611 −−num_requests=40042496）。由于是随机访问，因此在填充过程中可能会多次命中同一个键，这就是为什么我们需要执行多于的目标 10 00万项请求数。
• 数据大小: 我们测试了 100B 和 500B 的项（值）大小。
• 读写比例: 我们测试了一个混合负载（−−ratio=1:1），一个只读负载（−−ratio=0:1）和一个只写负载（−−ratio=1:0）。
• 流水线处理: 我们在所有测试中都使用了实际的流水线大小，即 −−pipeline=9。
• 客户机数目和线程数目: 我们 memtier_benchmark 实例创建的连接数等于线程数（-t）和每个线程的客户机数目（-c）的乘积。在我们的最终设置中，8 台基准测试客户机机器上的每一台都在 12 到 15 个线程上运行了 40 个客户机，总共创建了超过 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 个分片的数据库，并展示了出色的结果：超过 1000 万次操作/秒，且延迟略高于 1 毫秒！以下是从 Redis Enterprise UI 采取的屏幕截图

我们进行了这个实验，以便验证 Redis Enterprise 的无共享架构，可以借助 Redis Enterprise 5.0 中引入的新 OSS 集群 API 线性扩展。我们的实验包括

• 在单节点 Redis Enterprise 集群上对 32 个分片的数据库进行基准测试
• 在两节点 Redis Enterprise 集群上对 64 个分片的数据库进行基准测试
• 在 6 个节点的 Redis 企业版集群上进行 192 个分片数据库的基准测试

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

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

摘要

随着 OSS 集群 API 的推出，Redis Enterprise 5.0 只需向数据库添加分片，并向集群添加节点，便可轻松地进行线性扩展，如本次基准测试所证明的那样。我们计划继续打破数据库领域的性能记录，但我们希望在 2017 年 re:invent 大会上分享这一点，所以停留在了一半。请继续关注！