dot Redis 8 来了——而且是开源的

了解更多

每秒 120 万次操作的 Redis 云集群单服务器非基准测试

前几天在了解世界动态时,我阅读了 Anshu 和 Rajkumar 在 High Scalability 上发表的客座文章(Aerospike 出品,很棒)。我非常喜欢整篇文章,并对他们在 EC2 实例上所做的繁重调整以达到 100 万次操作印象深刻,但我一直在想——Redis 会怎样?

我本可以做一个全面的基准测试。但是做一个全面的基准测试非常耗时且耗费资源。而且还不包括比较苹果、橙子和其他类型水果的最初困难。真正的基准测试是一个陷阱,因为它只不过是一项从一开始就被认为会被积压的工作。但我想要一个答案,而且我想要它快点,所以我愿意做出一些牺牲来得到它。这意味着做下一件最好的事情——一个非基准测试。

根据(我自己的)定义,非基准测试与基准测试截然不同(因此得名)。在其中,你抄近路,放松每一个假设,以获得一个快速而粗略的估计值。严重依赖我们实验室人员的专业知识,我们在没有任何进一步优化的情况下测量了我们的 Redis 云软件的性能。我们使用以下设置运行了我们的非基准测试

  • 一个分片的1 Redis 云内存 NoSQL 数据库服务器,运行在单个 Amazon 实例上(请参阅下面关于分片和 Redis 云集群的说明)。
  • 3,000,000 个对象,每个对象大小为 100 字节。
  • 在非服务器实例上使用以下命令行参数运行 memtier_benchmark 工具客户端:`–ratio=1:1 -n 1000000 -d 100 -t 1 -c 50 –pipeline=75 –key-pattern=S:S`。
  • 一个以相等比例混合读取和写入的工作负载(我们对一种操作类型没有特别的偏好,并且认为这种混合更好地反映了现实生活)。
  • 一个按需 c3.8xlarge 实例。

我们没有时间设置 VPC 并调整放置组以获得最佳性能,因此我们在我们的标准服务环境中运行了整个过程——即在嘈杂、拥挤的 EC2 网络上。我们也没有针对此实验调整 CPU 行为或线程数或分片配置——我们让 Redis 云使用其默认设置。我们没有测试多个网络配置或添加额外的弹性网络接口 (ENI)。我们只是在 HVM 上获取了一个新配置的 Redis 云服务器,并对它进行了非基准测试……

你可以在 这个 gist 中找到我们运行的原始输出,但最重要的是,它获得了略高于 120 万 TPS(确切地说是 1228432)。当然,这个惊人的结果真的激发了我的胃口,我立即要求进行一个全面的、包含所有优化的、详尽的、包含水果和蔬菜的基准测试,以真正了解我们可以用 Redis 将限制推到什么程度!猜猜怎么着?它在待办事项列表中 🙂

1 关于分片和 Redis 云集群的一些说明(如承诺的那样)

按照设计,Redis 服务器(主要是)是一个单线程进程。在那种情况下,通常采用分片来将 Redis 数据库扩展到单个 CPU 核心或单个服务器的 RAM 容量之外。通常有三种公认的实现分片的方法:客户端、代理或集群。由于客户端和基于代理的 Redis 分片解决方案更容易独立于实际的底层数据库引擎实现,因此这些(例如,Redis-rbnutcracker)已经存在很长时间了。然而,今天只有少数 Redis 集群解决方案。

分片的 Redis 集群意味着一组 Redis 服务器(进程)部署在一个或多个计算节点上。该集群运行 Redis 数据库,每个数据库可能跨越多个节点和多个核心,超过聚合的 RAM 容量。生产级集群还应满足确保数据库可用性以及基础设施和数据库资源性能和管理的挑战。

Redis 集群最著名的实现当然是开源的。Redis 集群 (v3) 已经处于 beta 的高级阶段,预计将在几个月内投入生产。这个即将推出的版本将为我提到的许多挑战提供出色的答案。在其众多新功能中,新 OSS 版本还包括 创建 分片的 集群 的能力。谨代表整个 Redis 社区(如果我冒犯了任何人,我深表歉意),我们预计 Redis 版本 3 将在各个方面成为一个重要的新版本!

除了开源 v3 之外,还有其他一些 Redis 集群已经存在。有些人继续构建了自己的集群,每个人都有自己的理由。我不想点名任何人(比如 Twitter、 FlickrPinterest),但一家已经构建了集群的公司是 Redis。我们的 Redis 云服务由我们自己实现的 Redis 集群提供支持,并且在过去两年的大部分时间里一直在生产中使用。在那段时间里,我们一直在多个云和数据区域构建和运营我们的集群。作为一家初创公司,我们不得不构建我们的系统,以便良好且经济地扩展,以适应我们商业公共服务所取得的巨大成功。

Redis 是开源 Redis 项目的贡献者——我们的大部分员工都是出色的开发人员,他们热爱 Redis——但我们的用户需要开源范围内尚未准备好的解决方案。为了应对这些业务挑战,我们开发了允许我们动态扩展 Redis 数据库的解决方案,从兆字节到太字节。我们在四个不同的 IaaS 提供商和大约 20 个数据中心部署、扩展和管理集群。我们的用户创建了数万个数据库,并且对于每个数据库,我们不仅维护了可用性和性能,还处理了运营和管理任务(所有这些都通过一个 小型的 devops 团队 完成)。

要使用我们的 Redis 云集群,只需注册我们的服务并创建一个数据库。你可以在几秒钟内设置一个分片数据库(尽管分片不包含在我们的免费层中)。可以使用标准策略对 Redis 云实例进行分片,即根据 开源 Redis 集群规范,或者使用功能强大的自定义分片策略,该策略完全可以通过正则表达式规则列表进行配置(请参阅该功能的帮助页面 和未来的更新以获取更多信息)。

只要我还在这个话题上,这里有一个关于 Redis 集群的鲜为人知的事实:你无需更改应用程序中的任何内容即可开始使用它们。是的,你可以使用现有的代码和客户端库(无论是否知道集群和分片),你仍然可以获得集群提供的所有可扩展性、可用性和运营优势。我们的用户只需创建数据库并配置其选项(可用性、数据持久性、分片、安全等)和 bazinga!他们可以使用单个 Redis URL(主机名和端口),该 URL 是 Redis 集群中数据库的网关。当然,还有一些调整、最佳实践、优化、技巧、窍门和数百万个其他你可以在之上做的事情,但是(如非基准测试所示),即使没有它们,我们的集群也是一个非常出色的执行者。

我本打算使这些说明保持简短,但集群是我最喜欢且丰富的主题,我可以连续说几天(实际上我保证我会——更多相关的公告/技术/基准测试/规范/比较将随之而来)。为了保持这篇文章的篇幅适中,我想在这里结束,并邀请你关注 我们 并 对着  大喊——我非常可用 🙂

这篇文章最初发表在 2014 年 8 月 27 日的 HighScalability.com