重装上阵——Graviton2 提升 ElastiCache for Redis 的性价比！

1. 前言

从 2020 年 10 月开始，基于亚马孙云科技 Graviton2 的缓存实例逐步推出，客户可以在使用 Amazon ElastiCache for Redis 上使用这些实例。

Graviton2 处理器由 Amazon Web Services 使用 64 位 ARM Neoverse 内核定制，对第一代亚马逊云科技 Graviton 处理器进行了多种性能优化。这包括 7 倍的性能、4 倍的计算核心数量、每个内核 2 倍的私有内存、5 倍的内存速度和每个核心 2 倍的浮点性能。此外，Graviton2 处理器还具有全天候运行的全加密 DDR4 内存功能，且每核加密性能提高 50%。这些性能提升使得装备了 Graviton2 的实例成为缓存工作负载的上佳之选。

本文将向您展示 Graviton2 R6g 缓存实例（测试实例类型 cache.r6g，后续简称 r6g 或 R6g）对 R5 缓存实例（cache.r5，后续简称 r5 或 R5）的性能增强以及迁移到 Graviton2 R6g 缓存实例的方法流程。

通过测试我们可以清楚地看到，无论是何种工作负载和并发条件，R6g 实例比之同等资源配置的 R5 实例性能均有显著的提升，而且每小时单价却有下降，在这双重因素的叠加之下，选择新一代的 r6g 实例，具有更好的性能和性价比。

2. 环境准备

2.1 环境信息 

测试客户端（新加坡区域，AZ3）

表格：测试客户端配置

测试服务端（新加坡区域，主用在 AZ3）

表格：测试服务端配置

ElastiCache for Redis 选择默认参数，开启了集群模式（Cluster），数据用 3 个分片（每个分片 1 主 2 从，合计 9 个节点，为了系统的高可用和管理需要，默认参数会设置 25%的内存作为预留内存，所以读者在自己做性能测试时要留意别把内存耗光导致结果失真，这也是我们没有选择最低配置的实例做测试的原因之一）。

部署完毕后的集群地址：

表格：测试的集群终端节点

我们把测试客户端和集群的主节点人工强行放到了同一个 AZ 以获取更直接的对比效果，同时选用的 ElastiCache for Redis 集群实例（3*3 的 2xlarge 构建的集群）和测试客户端（8xlarge 的 EC2）均支持 10G 的带宽模式，读者在自己做测试时也要避免因网络带宽不足导致的测试结果失真。

可能很多读者会问，为什么测试的时候只选择这一个机型？细心的读者可能会发现，亚马逊云的机型是有一定规律的，例如 4xlarge 的配置刚好是 2xlarge 的两倍，而 8xlarge 的又刚好是 4xlarge 的两倍（以此类推，具体机型定义请参看网页链接：

https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/instance-types.html）

所以此处我们用 r5.2xlarge 和 r6g.2xlarge 做个具有代表性的对比测试，就不用其他机型一一对比了。

2.2 压测工具

此处我们使用两个不同的压测工具做针对性测试，一个是 Redis 自带的简单易用的 redis-benchmark，一个是 Redis Labs 开源提供的在更高并发的场景使用的 memtier_benchmark。

2.2.1 redis-benchmark

redis-benchmark 默认含在 redis 的分发里面，直接安装 redis 即可获得，在 Amazon Linux 2 操作系统上使用如下命令即可（这个安装在客户端上，后续迁移的时候也会用到这个客户端源）。

amazon-linux-extras install redis4.0 -y

其命令的常用参数选项如下：

表格：redis-benchmark 的常用参数

2.2.2 memtier_benchmark

memtier_benchmark 需要使用 github 上的源码进行编译才能使用，在 Amazon Linux 2 操作系统上可以使用如下方式：

yum install gcc git autoconf automake gcc-c++openssl-devel libevent-devel -y


mkdir /opt/memtier_benchmark
cd /opt/memtier_benchmark


git clone https://github.com/RedisLabs/memtier_benchmark.git


cd memtier_benchmark
autoreconf -ivf


./configure
make && make install

其命令的常用参数选项如下：

表格：memtier_benchmark 的常用参数

3. 测试过程

3.1 只读测试

注意：只读测试，我们只演示测试 redis-benchmark 工具。

测试 R5.2xlarge 机型的只读测试命令如下（压测 200 万次，并发 1000，随机 key 和 value，大小 1k，不使用管道）

1redis-benchmark -n 2000000 -c 1000 -t get -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试 R6g.2xlarge 机型的只读测试命令如下（压测 200 万次，并发 1000，随机 key 和 value，大小 1k，不使用管道）

1redis-benchmark -n 2000000 -c 1000 -t get -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

结果如下（此处截图仅供参考，不参与后面的性能统计）:

图例：对实例进行只读测试

3.2 只写测试

注意：只写测试，我们只演示测试 redis-benchmark 工具。

测试 R5.2xlarge 机型的只写测试命令如下（压测 200 万次，并发 1000，随机 key 和 value，大小 1k，不使用管道）

1redis-benchmark -n 2000000 -c 1000 -t set,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试 R6g.2xlarge 机型的只写测试命令如下（压测 200 万次，并发 1000，随机 key 和 value，大小 1k，不使用管道）

1redis-benchmark -n 2000000 -c 1000 -t set,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

结果如下（此处截图仅供参考，不参与后面的性能统计）：

图例：对实例进行只写测试

3.3 混合测试

3.3.1 通过 redis-benchmark 测试

此处我们设定四个场景，分别是如下两种并发和键值（key/value）大小的组合：

500 并发，1k 大小和 4k 大小；

1000 并发，1k 大小和 4k 大小；

如下为对应的测试命令（包括常用的命令 SET 和 GET，以及在实际业务中比较常用的 HSET）。

测试场景 1-1：500 并发，1k 大小，200 万次请求

1redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

1redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景 1-2：500 并发，4k 大小，200 万次请求

1redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 4096 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

1redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 4096 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景 1-3：1000 并发，1k 大小，200 万次请求

1redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

1redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景 1-4：1000 并发，4k 大小，200 万次请求

1redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 4096 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

1redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 4096 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

每种场景测试 5 次以上，然后取如下图所示的 SET、GET 和 HSET 的值并计算均值作为结果（因为 redis-benchmark 的单进程特性，在并发和模拟实际客户端场景层面难以完全覆盖，我们测试发现请求数在约 10 万/秒左右即达到上限，即使修改并发和数据大小也无法突破，所以这部分留给读者自己去做操作和测试验证，本文测试数据收集不考虑此工具，防止数据出现偏差）。

图例：对实例进行混合测试（SET/GET/HSET）

3.3.2 通过 memtier_benchmark 测试

此处我们同样设定四个场景，为如下条件的组合：

• 随机测试：分别测试 500 和 1000 并发，键值 1k 到 4k 大小随机，测试时间 180 秒，SET 和 GET 的比例为 1：4；

• 正态分布（高斯分布）测试：分别测试 500 和 1000 并发，键值 1k 到 4k 大小随机，测试时间 180 秒，SET 和 GET 的比例为 1：4；

我们没有设置更高的并发或更大的键值测试，因为在测试的过程中，我们发现系统运行比较稳定，调高并发或键值会导致本文的测试客户端 m5.8xlarge 的带宽使用率直接打满 10G（如果要测试集群的极限，建议采用多客户端的分布式测试方式，本文暂不涉及），我们的测试命令只包括 SET 和 GET，且为了更好的模拟实际生产环境中的读写比例，所以此处读写比例设置为 1：4（模拟 20%写）。

测试场景 2-1：随机测试，500 并发，键值 1k-4k 随机大小，测试时间 180 秒，SET 和 GET 比例为 1：4

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景 2-2：随机测试，1000 并发，键值 1k-4k 随机大小，测试时间 180 秒，SET 和 GET 比例为 1：4

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景 2-3：正态分布（高斯分布）测试，500 并发，键值 1k-4k 随机大小，测试时间 180 秒，SET 和 GET 比例为 1：4 

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景 2-4：正态分布（高斯分布）测试，1000 并发，键值 1k-4k 随机大小，测试时间 180 秒，SET 和 GET 比例为 1：4

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

在测试过程中，我们发现系统运行非常稳定，所以每种场景测试了 6 次，然后取如下图所示的 Sets、Gets 和 Waits 的 p99 均值（其中 1000 并发我们没有取 p99 的均值，而是取了总体的均值，因为我们发现在 R5 机型的集群中，1000 并发的情况下，p99 均值的波动和方差太大，而 R6g 的机型没有这个问题，为了方便对比，就没有取并发 1000 的延时 p99 均值）。

图例：对实例进行混合测试（本文测试数据集来自此测试模式）

3.4 监控

在测试的过程中，我们可以在 CloudWatch 控制台查看 ElastiCache 的 Cluster 端的对应数据，类似如下（主要防止因为资源耗尽的原因导致结果异常，如 CPU，带宽等）：

图例：CloudWatch 的监控数据

在测试客户端，每一次使用 memtier_benchmark 测试都会输出对应的网络流量，记得别超过实例的最高值即可，否则请使用多个实例的分布式并发测试（例如想压测出 ElastiCache for Redis 的集群的性能极限）或者使用更高规格的实例（对应网络带宽会更大）。

4. 对比分析

针对之前的混合读写测试场景，我们针对 memtier_benchmark 工具的 4 个不同场景各做了 6 轮测试（每次重新开始测试前使用“flushdb/flushall”清理集群中的 3 个主分片，我们发现测试的结果非常的接近，表示服务器端运行稳定），获取到的原始数据如下：

表格：测试获取到的原始数据

4.1 性能对比

注意：在计算比例时，以结果优的为基数（分母）。

4.1.1 写入性能对比

在场景 2-1 中，r6g 对比 r5，其 SET 的每秒请求数提升了 40%；

在场景 2-2 中，r6g 对比 r5，其 SET 的每秒请求数提升了 37%；

在场景 2-3 中，r6g 对比 r5，其 SET 的每秒请求数提升了 37%；

在场景 2-4 中，r6g 对比 r5，其 SET 的每秒请求数提升了 34%。

对比结果如下图所示（数值越大越好）：

图例：SET 写入场景性能对比 0

4.1.2 读取性能对比

在场景 2-1 中，r6g 对比 r5，其 GET 的每秒请求数提升了 40%；

在场景 2-2 中，r6g 对比 r5，其 GET 的每秒请求数提升了 37%；

在场景 2-3 中，r6g 对比 r5，其 GET 的每秒请求数提升了 37%；

在场景 2-4 中，r6g 对比 r5，其 GET 的每秒请求数提升了 34%。

对比结果如下图所示（数值越大越好）：

图例：GET 读取场景性能对比

4.1.3 响应延时对比

在场景 2-1 中，r6g 对比 r5，其 p99（99%）的响应延时降低了 36%；

在场景 2-2 中，r6g 对比 r5，其平均响应延时降低了 37%；

在场景 2-3 中，r6g 对比 r5，其 p99（99%）的响应延时降低了 50%；

在场景 2-4 中，r6g 对比 r5，其平均响应延时降低了 36%；

对比结果如下图所示（数值越小越好）：

图例：请求延时对比

4.2 性价比对比

我们从 Amazon Web Services 的官网列表价 查询到如下的 ElastiCache for Redis 实例每小时的价格（价格根据不同区域，不同时间会有差异，此处以 2021-04-29 的新加坡区域为例，最新和最终价格以官网页面为准）：

Amazon Web Services 也提供一个云上的成本计算器，针对上述两种机型，我给大家做了一个成本计算的例子供大家分享。

4.3 结论

同样条件下的性能测试和延时，R6g 机型（基于 Graviton 第 2 代的 ARM 架构）均大幅领先原有基于通用 CPU 的 R5 机型。通过测试我们可以清楚地看到，无论是何种工作负载和并发条件，R6g 实例比之同等资源配置的 R5 实例性能均有显著的提升，而每小时单价却有下降，因而 R6g 实例对客户来说，有更好的性价比。

综上所述，结合性能优势和价格优势，新发布的 R6g 机型将是客户在使用 ElastiCache for Redis 服务时的更优选择。

注意：当您按本文步骤进行测试的时候，随着环境，测试步骤的不同，可能需要对命令参数进行微调，测试结果也会有相应变化，但测试的思路以及测试结果变化的客观规律却是共通的。

5.实例的迁移

相对于 ElastiCache for Redis 管理服务，部分客户也喜欢自建 Redis 平台，但是相对平台服务而言，有如下比较明显的缺点和难题需要解决：

• 难以管理：管理服务器配置、软件补丁、安装、配置与备份

• 难以实现高可用：需要快速执行错误检测与修复

• 难以扩展：在线扩展可能引发错误，且需要监控副本性能

• 成本高昂：人员、流程、硬件与软件需要占用大量资金

除了前面章节对比测试的性能和延时，以及成本优势外，使用 ElastiCache for Redis 的管理服务还有如下优势可以让客户直接开箱即用:

• 极致性能：提供小于 1ms 的响应时间；当前最大支持 500 个节点，340TB 存储的最大 Redis 集群；最大支持 3250 万连接数，满足极致场景的巅峰性能；

• 全托管：Amazon Web Services 管理所有的硬件以及软件的配置和监控；

• 易伸缩：通过副本提供读操作的弹性伸缩，通过分片提供写操作非中断的弹性伸缩；支持横向和纵向的弹性伸缩；

• 可靠性保障：多可用区（免跨 AZ 流量费）支持，深度和详细的监控和告警，自动故障转移（10-20s 内实现 Fail Over）；

• 安全和合规：通过 Amazon VPC 实现网络隔离和管理，符合 HIPAA，PCI 和 FedRAMP 等安全和合规要求，存储和传输中支持进行加密和身份认证；

• 兼容性：兼容多个 Redis 版本和客户端，支持导入导出，支持快照和恢复等；

5.1 纯手工迁移

比较传统的方式是把运行在 EC2（或者容器）里面的 Redis 数据做个备份导出（通过在 reids-cli 中使用阻塞式的 save 命令或者后台方式的 bgsave 命令），然后把导出文件存到 S3（当前只支持从 S3 导入），然后在 ElastiCache 控制台创建集群时选择导入位于 S3 的备份文件，在这种操作方式下，如果源还在继续使用可能会导致两边的数据不完全同步，如果源不操作等新集群可用户再切换的话，则会有一定的服务中断时间。

具体操作见从备份还原的指引文档 ，本文不做额外的演示和说明。

5.2 使用 redis-migration-tool 进行迁移

Redis-migration-tool 是 github 上开源的一个 Redis 迁移工具，使用它可以在不同的 Redis 环境（如单机，集群等）实现同步和复制。

在 Amazon Linux 2 操作系统上可以使用如下方式使用 redis-migration-tool：

1mkdir /opt/redis-migration-tool && cd /opt/redis-migration-tool23git clone https://github.com/vipshop/redis-migrate-tool.git

因为这个工具有段时间没更新了，我们使用的是比较新的 Redis 6.0.5 版本，所以需要修改一下源码中关于 RDB 文件版本的定义。

修改“/opt/redis-migration-tool/redis-migrate-tool/src/rmt_redis.c”，把原来的“#define REDIS_RDB_VERSION 7”修改成“#define REDIS_RDB_VERSION 10”，然后再编译：

 1cd /opt/redis-migration-tool/redis-migrate-tool 2 3autoreconf -fvi 4 5./configure 6 7make 8 91011#编译好的文件位于src/redis-migrate-tool

接着编辑对应的配置文件“/opt/redis-migration-tool/redis-migrate-tool/rmt.conf”，内容如下（记得修改对应的集群 endpoint）：

 1[source] 2 3type: single 4 5servers : 6 7- 127.0.0.1:6379 8 91011[target]1213type: redis cluster1415servers:1617- r6g-2xlarge-elasticache-for-redis-cluster-endpoint:637918192021[common]2223listen: 0.0.0.0:8888

同时，我们此处使用之前的测试机（那个 m5.8xlarge 的 EC2）的机器当做源，然后通过脚本往里面压数据，命令如下（模拟一个并发，一个客户端，持续 180 秒的写入随机数据）：

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 1 -c 1 -p 6379 -s 127.0.0.1

5.2.1 准备

原来在准备 redis-benchmark 工具的时候已经安装了 redis 服务，此处我们把服务启动，并确认数据内容，同时手工写入一个 key 做测试，如下：

 1systemctl enable redis 2 3systemctl start redis 4 5 6 7redis-cli 8 9# keys *10# set owner "WeiqiongChen"

源如下所示（没有其他数据，只有我们手工写入的 key）：

图例：准备位于 EC2 的源 Redis（单机版）

目标如下所示（没有其他数据，也没有我们手工写入的 key，因为还没开始同步）：

图例：清理目标 ElastiCache for Redis 集群环境

5.2.1 迁移和同步

在源通过如下命令开始生成数据

1memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 1 -c 1 -p 6379 -s 127.0.0.1

如下：

图例：启动源

然后再启动同步（特意晚启动同步模拟客户真实的迁移场景）

1cd /opt/redis-migration-tool/redis-migrate-tool23./src/redis-migrate-tool -c ./rmt.conf -o log &

如下所示：

图例：启动源到目的的同步

5.2.1 验证

我们统计源注入的数据量，如下（此处为 473563 个 key）：

图例：查看源的数据量

对比查看目标库同步的数据量（因为目标卡集群分成三个片了，所以要统计三个分片的总数），如下（此处合并总数依然是 473563 个 key）：

图例：查看目标的数据量

注意：读者们可以在源多做几轮测试，验证同步结果是否符合预期（如果没有数据同步或者有异常，可以查看 redis-migration-tool 目录的 log 文件查看异常信息）。

扩展阅读

《Amazon ElastiCache 用户指南》：

https://docs.aws.amazon.com/zh_cn/AmazonElastiCache/latest/red-ug/GettingStarted.html

《Amazon ElastiCache 最佳实践》：

https://docs.aws.amazon.com/zh_cn/AmazonElastiCache/latest/red-ug/BestPractices.html

《使用 CloudWatch 监控 Amazon ElastiCache 的最佳实践》：

https://aws.amazon.com/cn/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/

《五个用来评估 Amazon ElastiCache 容量的工作负载指标》：

https://aws.amazon.com/cn/blogs/database/five-workload-characteristics-to-consider-when-right-sizing-amazon-elasticache-redis-clusters/

memtier_benchmark：

https://github.com/RedisLabs/memtier_benchmark.git

官网列表价：

https://aws.amazon.com/cn/elasticache/pricing/

成本计算例子：

https://calculator.aws/#/estimateid=783752bdbc0abfaa79c6f50146ae1071e03b07b4

本篇作者

陈卫琼

亚马逊云科技资深解决方案架构师

负责协助客户业务系统上云的解决方案架构设计和咨询，现致力于大数据和 IoT 相关领域的研究。