圆点 快速的未来即将来到你所在城市的活动中。

加入我们的 Redis Released

你的云做不到:0.5M ops + ACID@ <1ms 延迟!

对于熟悉 Redis 的人来说,创建一个保证类似 ACID(原子性、一致性、隔离性、耐久性)的配置操作相对简单:只需创建一个带有“主”角色的单个 Redis 实例,并将其配置为对持久化存储设备“appendfsync always”的所有写入操作进行 AOF。此配置通过以下方式提供 ACID 特性

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

话虽如此,大多数 Redis 用户更喜欢不使用此配置运行 Redis,因为它会显著影响性能。例如,如果持久化存储当前繁忙,Redis 将等待请求执行,直到存储再次变为可用。

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

  1. 使用 Redis Enterprise,可以轻松创建主集群,并在同一节点上运行所有分片。由于 Redis 是单线程的,因此在同一节点上运行多个分片将帮助我们提高吞吐量,因为节点上的所有内核都得到利用。此外,这也有助于我们确定可以从单个节点获得多少吞吐量,然后根据需要更多吞吐量相应地扩展集群。
  2. 由于 AOF 的大小在每次“写入”操作时都会增长,因此需要 AOF 重写操作来控制文件大小并减少从磁盘恢复所需的时间。默认情况下(也可以配置),当 AOF 的大小比之前的重写操作的大小大一倍时,OSS Redis 会触发重写操作。因此,在“写入”密集场景中,重写操作可能会阻止 Redis 主回路(以及同一节点上正在运行的其他 Redis 实例)执行正在进行的磁盘请求。Redis Enterprise 使用贪婪的 AOF 重写算法,该算法会尽可能尝试推迟 AOF 重写操作,而不会违反恢复时间 SLA(一个可配置参数),也不会达到磁盘空间限制。此方法的优点是即使在 ACID 配置中,由于优化了重写处理过程,Redis Enterprise 生得吞吐量更高。
  3. Redis Enterprise 存储层允许多个 Redis 实例以非阻塞的方式写入相同的持久存储,即一个持续向磁盘写入的繁忙的分片(例如当 AOF 重写正在执行时)不会阻止其他分片执行持久操作。

AWS 上的 ACID 基准测试

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

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

运行基准测试

尽管已经测试了多种类型的负载,包括不同的读/写比率;不同的对象大小(从 100B 到 6KB);连接数目较多;有无管道;但我们无法使持久“写入”操作的延迟低于一毫秒,其中延迟是从请求的第一个字节到达集群到第一个写入响应字节发回客户端的时间来测量的。最后,我们在单个连接上对单个请求进行了测试,但仍无法将延迟降低到 2-3 毫秒以下。我们做了更深入的分析,发现 AWS 云中的任何实例与 ACID 配置下的 EBS 存储之间的延迟不可能低于两毫秒。

由于我们大多数客户都想要 <1 毫秒的延迟,因此我们决定寻找其他方法。

戴尔 EMC VMAX 上的 ACID 基准测试

VMAX 背景

简单来说,VMAX 是建立在构建模块化、智能、简单存储的策略之上的存储阵列系列。它集成了连接并共享所有 VMAX 引擎中资源的动态虚拟矩阵界面,使存储阵列能够从入门级配置无缝增长为世界上最大的存储阵列。
性能方面,VMAX 可以从一个扩展至八个引擎(V-Brick)。每个引擎包括双控制器,每个控制器均配备 2 路插槽英特尔 CPU、前端和后端连接、硬件压缩模块、内部 InfiniBand 架构以及一个大型镜像持久缓存。所有写入操作会在在 VMAX 缓存中注册后立即确认对主机已完成操作,而只有在稍后(可能在多次更新后)才会写入到闪存中。读取操作也受益于 VMAX 大型缓存。当请求对未存储在缓存中的数据的读取时,FlashBoost 技术直接将 I/O 从后端(闪存)传递到前端(主机),随后会将其暂存到缓存中以备将来可能访问。

基准配置

我们设置了以下基准环境

以下是一些更多详细信息

基准参数

  • 项目大小 - 100B 和 6000B,涵盖大多数 Redis 使用案例
  • 我们测试了不同的读/写比率
    • 标准 - 1:1
    • “写”密集 - 1:9
    • “读”密集 - 9:1
  • 在每种配置中,我们都会测量在保持亚毫秒级服务器延迟的情况下可以完成多少 ACID 操作/秒。服务器延迟包括整个 Redis 过程和磁盘提交,但不包括客户端-服务器网络开销。
基准测试结果


正如预期的那样,“读”密集测试提供了最佳结果;也就是说,我们非常惊讶地发现,在标准的 1:1 读/写使用案例中,当 item_size 为 100B 时,操作/秒超过了 660K,并且在写密集场景中,操作/秒仅略低(即 640K)。我们也对 6000B 的结果印象深刻,即使是在写密集场景下,例如在单个集群节点上的操作/秒为 80K,延迟时间低于毫秒级。
我们惊讶(且高兴)地发现,借助戴尔-EMC VMAX 等高端持久性存储设备,单个 Redis集群节点可以在保持亚毫秒级数据库延迟的情况下支持超过 650K ACID 操作/秒。
另一方面,我们失望地看到,我们无法在最新的云存储基础设施(即 AWS io1 EBS)上以亚毫秒级延迟运行一项持久性操作。尽管有许多先进技术和公共云服务可用,但还有很长的路要走。

完整的 Redis 和戴尔-EMC VMAX 性能评估测试和最佳实践可以在我们的网站 此处 找到。

附录

memtier_benchmark 参数
每个测试都使用以下 memtier_benchmark 参数运行

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