您的云做不到这一点：0.5M 操作数 + ACID @<1ms 延迟！

对于熟悉 Redis 的用户来说，创建保证 ACID 式（原子性、一致性、隔离性、持久性）操作的配置应该相对简单：只需创建一个具有“主”角色的单个 Redis 实例，并将其配置为每次写入都使用 AOF（“appendfsync always”）写入持久化存储设备。此配置通过以下方式提供 ACID 特性

原子性 – 使用 Redis 事务命令（即 WATCH/MULTI/EXEC）或 Lua 脚本实现不可分割和不可约减的特性。“全有或全无”属性几乎总是可以实现，除了像 OOM（内存不足）或有 bug 的 Lua 脚本等情况。
一致性 – Redis 验证任何“写入”操作都以允许的方式影响目标数据结构，并且任何编程错误都不会导致违反任何已定义的规则。
隔离性 – 在命令级别，由于 Redis 是单线程的，因此实现了隔离；对于多个操作，可以使用事务（即WATCH/MULTI/EXEC）或在 Lua 脚本中实现隔离。
持久性 – 对于每次写入都使用 AOF（附加日志文件），Redis 会在“写入”操作成功写入磁盘后向客户端回复，从而保证了持久性。此外，您应该将持久化存储连接到您的网络，以便通过将新节点连接到故障节点使用的同一持久化存储来轻松恢复数据。

话虽如此，大多数 Redis 用户更倾向于不在此配置下运行 Redis，因为它会极大地影响性能。例如，如果持久化存储当前繁忙，Redis 会暂停请求的执行，直到存储再次可用为止。

考虑到这一点，我们想确定 Redis Enterprise (Redis^e) 集群处理 ACID 事务的速度有多快。我们在 Redis^e 架构中进行了一些内置增强，可以在 ACID 配置下实现更好的性能，其中包括

使用 Redis Enterprise，很容易创建一个只有主分片的集群，并将所有分片运行在同一个节点上。由于 Redis 是单线程的，在同一个节点上运行多个分片有助于提高吞吐量，因为节点上的所有核心都被利用起来。此外，这也帮助我们确定单个节点可以获得多少吞吐量，然后如果需要更多吞吐量，可以相应地扩展集群。
由于每次“写入”操作都会使 AOF 文件大小增长，因此需要 AOF 重写过程来控制文件大小并缩短从磁盘恢复的时间。默认情况下（也可配置），开源 Redis 会在 AOF 大小达到上次重写操作的两倍时触发重写操作。因此，在“写入”密集型场景中，重写操作可能会阻止 Redis 的主循环（以及在同一节点上运行的其他 Redis 实例）执行进行中的磁盘请求。Redis Enterprise 使用贪婪的 AOF 重写算法，试图尽可能地推迟 AOF 重写操作，同时不违反恢复时间的 SLA（一个可配置参数）且不达到磁盘空间限制。这种方法的优势在于，尤其在 ACID 配置下，由于对重写过程的最佳利用，Redis Enterprise 的吞吐量更高。
Redis Enterprise 的存储层允许多个 Redis 实例以非阻塞方式写入同一持久化存储，即一个持续向磁盘写入（例如执行 AOF 重写时）的繁忙分片不会阻止其他分片执行持久化操作。

AWS 上的 ACID 基准测试

我们在 AWS VPC 内部署了以下基准测试配置

1x c4.8xlarge 实例，用于运行 memtier_benchmark 1.2.6 版本作为负载生成工具
1x x1.16xlarge 实例，用于运行仅含主分片的 Redis^ePack 集群 4.4.2-30 版本
4x io1 EBS 卷，总容量 5TB，性能 75K IOPS/秒

运行基准测试

尽管我们测试了多种类型的负载，包括不同的读/写比例；不同的对象大小（从 100B 到 6KB）；不同数量的连接；使用和不使用管线化；对于持久化“写入”操作，我们无法获得低于 1 毫秒的延迟，其中延迟是从请求的第一个字节到达集群的时间到“写入”响应的第一个字节发送回客户端的时间来衡量的。最后，我们测试了通过单个连接发送单个请求，但仍然无法获得低于 2-3 毫秒的延迟。我们进行了更深入的分析，发现在 ACID 配置下，AWS 云上的任何实例与 EBS 存储之间的延迟都无法低于两毫秒。

由于我们大多数客户希望延迟低于 1 毫秒，我们决定寻找替代方案。

Dell-EMC VMAX 上的 ACID 基准测试

VMAX 背景介绍

简而言之，VMAX 是基于简单、智能、模块化存储策略构建的存储阵列系列。它整合了一个动态虚拟矩阵接口，连接和共享所有 VMAX 引擎之间的资源，使存储阵列能够从入门级配置无缝扩展到全球最大的存储阵列。
在性能方面，VMAX 可以从一扩展到最多八个引擎（V-Bricks）。每个引擎包括双控制器，每个控制器配备双路 Intel CPU、前端和后端连接、硬件压缩模块、Infiniband 内部网络以及一个大型镜像和持久化缓存。所有写入操作一旦注册到 VMAX 缓存，就会立即向主机确认，稍后（可能在多次更新后）才会写入闪存。读取操作也受益于 VMAX 的大容量缓存。当请求读取不在缓存中的数据时，FlashBoost 技术将 I/O 直接从后端（闪存）传送到前端（主机），稍后会缓存在缓存中以便将来访问。

基准测试配置

我们设置了以下基准测试环境

以下是一些更多细节

基准测试参数

项大小 – 100B 和 6000B，涵盖大多数 Redis 使用场景
我们测试了不同的读/写比例
- 标准 – 1:1
- “写入”密集型 – 1:9
- “读取”密集型 – 9:1
在每种配置下，我们测量了在保持亚毫秒级服务器延迟的同时可以达到多少 ACID ops/秒。服务器延迟包括整个 Redis 进程和提交到磁盘的时间，但不包括客户端-服务器网络开销。

基准测试结果

正如预期，‘读取’密集型测试提供了最好的结果；话虽如此，我们非常惊讶地看到，在 100B 项大小的标准 1:1 读/写用例中，达到了超过 660K ops/秒的性能，而在写入密集型场景中，吞吐量仅略低（即 640K op/秒）。我们对 6000B 的结果也印象深刻，即使在写入密集型场景下，例如单个集群节点上的亚毫秒级延迟下达到了 80K ops/秒。
我们惊讶（并高兴）地发现，使用 Dell-EMC VMAX 等高端持久化存储设备，单个 Redis^e集群节点可以在保持亚毫秒级数据库延迟的同时，支持超过 650K ACID ops/秒。
另一方面，我们失望地看到，在最先进的云存储基础设施（即 AWS io1 EBS）上，我们无法在亚毫秒级延迟下运行单个持久化操作。尽管有众多先进技术和公共云服务可用，但仍有很长的路要走。

完整的《Redis 与 Dell-EMC VMAX 性能评估测试和最佳实践》可在我们的网站上找到此处。

附录

memtier_benchmark 参数
每次测试均使用以下 memtier_benchmark 参数运行

客户端数量 – 70
线程数量 – 1
管线化大小 – 20
测试运行时间 – 900 秒