乐趣区

关于java:世界上最快的内存数据库横空出世比-Redis-快-25-倍Star-数飙升杀疯了

jiezi

起源 | Info，整顿 | 钰莹、Tina

还击就代表输了？！

往年年中，一位前谷歌、前亚马逊的工程师推出了他创作的开源 内存数据缓存零碎 Dragonfly，用 C/C++ 编写，基于 BSL 许可（Business Source License）散发。

依据过往的基准测试后果来看，Dragonfly 可能是世界上最快的内存存储系统，它提供了对 Memcached 和 Redis 协定的反对，但可能以更高的性能进行查问，运行时内存耗费也更少。

与 Redis 相比，Dragonfly 在典型工作负载下实现了 25 倍的性能晋升；单个 Dragonfly 服务器每秒能够解决数百万个申请；在 5GB 存储测试中，Dragonfly 所需的内存比 Redis 少 30%。

作为一个开源软件，Dragonfly 在短短两个月取得了 9.2K GitHub 星，177 个 fork 分支。

尽管这些年，涌现了不少相似的 Redis 兼容型内存数据存储系统，例如 KeyDB、Skytable，然而都没能像这次这么“轰动”。毕竟 Redis 诞生了十多年，这时从头开始设计一个缓存零碎，能够摈弃历史包袱，更好地利用资源。

Redis 还击

为还击新冒头的 Dragonfly，Redis 的联结创始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架构师 Yossi Gottlieb、Redis Labs 的性能工程师 Filipe Oliveira 联结公布了一篇名为《13 年后，Redis 是否须要新的架构》的文章。

在文章中，他们顺便给出了自认更加偏心的 Redis 7.0 vs Dragonfly 基准测试后果：Redis 的吞吐量比 Dragonfly 高 18% – 40%，以及一些无关 Redis 架构的观点和思考，以 证实“为什么 Redis 的架构依然是内存实时数据存储（缓存、数据库，以及介于两者之间的所有内容）的最佳架构”。

尽管他们强调 Redis 架构依然是同类最佳，但也没法漠视 Dragonfly 这些新软件提供的一些陈腐、乏味的想法和技术，Redis 示意其中的一些甚至有可能在将来进入 Redis（比方曾经开始钻研的 io_uring、更古代的 dictionaries、更有策略地应用线程等）。

另外，Redis 指出 Dragonfly 基准测试的比拟办法“不能代表 Redis 在事实世界中的运行形式”。对此，Reddit 上有网友反驳称：

它相对代表了事实世界中普通用户运行 Redis 的形式。“在单台机器上运行集群，只是为了可能应用超过 1 个 core” 是额定的复杂性，人们只有在别无选择的状况下才会这样做，如果竞争者无论有多少个 core 都能“just works”，那么最好能有更容易的设置。

另外，最近面试整顿了 Java 最新、最全的面试题：

https://www.javastack.cn/mst/

还有人示意，这篇文章是 Redis 团队在有礼貌地否定“Dragonfly 是最快的缓存零碎”，但更多网友示意，Redis 发文章进行“还击”，就曾经代表他们的营销部门输了：

“Redis 投入如此多的工程精力来写这么一篇文章，还对 Reids/Dragonfly 进行了基准测试，这是对 Dragonfly 的极大赞美。”

“我很快乐 Redis 发了这篇文章，因而我必须要去理解一下 Dragonfly，它看起来很棒。”

Redis 博客文章翻译：

作为一项基础性技术，每隔段时间总有人跳进去，想要替 Redis 换套新架构。

几年之前，KeyDB 就提出了这类计划，而最近亮相的 Dragonfly 则宣称是速度最快的 Redis 兼容型内存数据存储系统。没错，这类计划的涌现当然带来了不少值得关注和探讨的乏味技术 / 思路。在 Redis，咱们也喜爱迎接挑战，从新扫视 Redis 最后的架构设计准则。

咱们当然始终在寻求为 Redis 晋升性能、裁减性能的翻新方向，但这里咱们想聊聊本人的观点和思考，阐释 Redis 时至今日为何仍是最出色的实时内存数据存储（包含缓存、数据库以及介于二者之间的所有）计划之一。

接下来，咱们将 重点介绍 Redis 对于速度和架构差别的观点，再以此为根底做出比拟。在文章的最初，咱们还会提供基准测试后果、与 Dragonfly 我的项目的详尽性能比拟信息，欢送大家自行比照参考。

速度问题

Dragonfly 基准测试其实是将独立单过程 Redis 实例（只能应用繁多外围）与多线程 Dragonfly 实例（能够应用虚拟机 / 服务器上的全副可用外围）进行比拟。

很显著，这样的粗犷比拟并不能代表 Redis 在事实场景下的运行状态。作为技术构建者，咱们心愿更确切地把握自有技术同其余计划间的差别，所以这里咱们做了一点公平性调整：将具备 40 个分片的 Redis 7.0 集群（可应用其中的大部分实例外围）与 Dragonfly 团队在基准测试中应用的最大实例类型（AWS c4gn.16xlarge）进行性能比拟。

在这轮测试中，咱们看到 Redis 的吞吐量比 Dragonfly 要高出 18% 至 40%，而这还仅仅只用到全副 64 个 vCore 中的 40 个。

架构差别

背景信息

在咱们看来，每一位多线程我的项目的开发者在立项之前，都会依据以往工作中经验过的痛点来领导架构决策。

咱们也抵赖，在多核设施上运行繁多 Redis 过程（这类设施往往提供几十个外围和数百 GB 内存）的确存在资源无奈充分利用的问题。但 Redis 在设计之初也的确没有思考到这一点，而且泛滥 Redis 服务商曾经拿出了相应的解决方案，借此在市场上占得一席之地。

Redis 通过运行多个过程（应用 Redis 集群）实现横向扩大，包含在繁多云实例背景下也是如此。

在 Redis 公司，咱们进一步拓展这个概念并建设起 Redis Enterprise。Redis Enterprise 提供管理层，容许用户大规模运行 Redis，并默认启用高可用性、即时故障转移、数据长久与备份等性能。

上面，咱们打算分享幕后应用的一些准则，向大家介绍咱们如何为 Redis 的生产利用设计良好的工程实际。

架构设计准则

在每个虚拟机上运行多个 Redis 实例

通过在每个虚拟机上运行多个 Redis 实例，咱们能够：

  1. 应用一套齐全无共享的架构实现纵向与横向线性扩大。与纯纵向扩大的多线程架构相比，这套计划能始终提供更好的架构灵活性。
  2. 进步复制速度，因为复制操作是跨多个过程并发实现的。
  3. 从虚拟机故障中疾速复原。因为新虚拟机的 Redis 实例将同时填充来自多个内部 Redis 实例的数据。

将每个 Redis 过程限度为正当的大小

咱们不容许繁多 Redis 过程的大小超过 25 GB（运行 Redis on Flash 时下限为 50 GB）。如此一来，咱们就能：

  • 在出于复制、快照保留、Append Only File（AOF）重写等目标进行 Redis 分叉时，既享受边写边复制的益处，又无需承当沉重的内存开销。若非如此，咱们（或客户）将须要领取低廉的资源老本。
  • 为了轻松治理整个集群，咱们心愿每个 Redis 实例都放弃在较小体量，借此放慢迁徙分片、从新分片、扩大和从新平衡等的执行速度。

横向扩大才是最重要的

以横向扩大的形式灵便运行内存数据存储，是 Redis 获得成功的要害。

上面来看具体起因：

  • 更佳弹性——咱们在集群中应用的节点越多，整个集群的健壮性就越强。例如，如果您在三节点集群上运行数据集，且其中一个节点产生降级，则代表有三分之一的集群无奈运行；但如果是在九节点集群上运行数据集，同样是其中一个节点产生降级，则只有九分之一的集群无奈运行。
  • 易于扩大——在横向扩大零碎当中，向集群增加一个额定节点、并将数据集的一部分迁徙到其中要容易得多。与之对应，在纵向扩大零碎中，咱们只能间接引入一个更大的节点并复制整个数据集……这是个漫长的过程，而且期间随时有可能闹出麻烦。
  • 逐渐扩大更具老本效益——纵向扩大，尤其是云环境下的纵向扩大，往往对应昂扬的老本。在少数状况下，即便只须要向数据集内增加几 GB 内容，也须要将实例大小翻倍。
  • 高吞吐——在 Redis，咱们看到很多客户会在小型数据集上运行高吞吐量工作负载，即具备极高的网络带宽及 / 或每秒数据包（PPS）需要。咱们以每秒操作数 100 万 + 的 1 GB 大小数据集为例，相较于应用单节点 c6gn.16xlarge 集群（128 GB 内存、64 个 CPU 加 100 Gbps 传输带宽，每小时应用老本 2.7684 美元），三个 c6gb.xlarge 节点（8 GB 内存、4 个 CPU 外加最高 25 Gbps 传输带宽，每小时 0.1786 美元）形成的集群可能将运行老本拉低 20%，而且健壮性反而更高。既然老本效益杰出、弹性更强且吞吐量反超，那横向扩大无疑就是比纵向扩大更好的抉择。
  • 贴近 NUMA 架构——纵向扩大还要求应用能包容更多外围和大容量 DRAM 的双插槽服务器；相比之下，Redis 这样的多解决架构其实更适应 NUMA 架构，因为其行为特色就靠近一种由多个较小节点组成的网络。但必须抵赖，NUMA 跟多线程架构之间也有人造抵触。依据咱们在其余多线程我的项目中的教训，NUMA 可能令内存数据存储的性能升高达 80%。
  • 存储吞吐量限度——AWS EBS 等内部磁盘的扩大速度，显然不迭内存和 CPU。事实上，云服务商会依据所应用设施的类型增加存储吞吐量限度。因而，防止吞吐量限度、满足数据高持久性要求的惟一方法，就是应用横向扩大——即增加更多节点和更多的配套网络附加磁盘。
  • 长期磁盘——长期磁盘是一种将 Redis 运行在 SSD 上的绝佳形式（其中 SSD 用于代替 DRAM，而非充当长久存储介质），可能在放弃 Redis 极高速度的同时将数据库老本放弃在磁盘级程度。但长期磁盘也有其下限，一旦迫近这一下限，咱们还须要进一步扩大容量——这时候，更好的方法依然是增加更多节点、引入更多长期磁盘。所以，横向扩大持续胜出。
  • 商品硬件——最初，咱们的很多客户会在本地数据中心、公有云甚至是小型边缘数据中心内运行 Redis。在这类环境中，绝大多数设施内存不超过 64 GB、CPU 不超过 8 个，所以惟一可行的扩大形式就只有横向扩大。

总 结

咱们依然观赏由社区提出的种种乏味思路和技术计划。

其中一部分无望在将来进入 Redis（咱们曾经开始钻研 io_uring、更古代的字典、更丰盛的线程应用策略等）。

但在可预感的将来，咱们不会放弃 Redis 所坚守的无共享、多过程等根本架构准则。这种设计不仅具备最佳性能、可扩展性和弹性，同时也可能反对内存内实时数据平台所须要的各类部署架构。

附录：Redis 7.0 对 Draonfly 基准测试细节

Redis 教程举荐看这里：https://www.javastack.cn/database/redis/

后果概述

版本：

  • 咱们应用 Redis 7.0.0，间接通过源码构建
  • Dragonfly 应用的则是构建自 https://github.com/Dragonfly/… 的 6 月 3 日版源码（hash=e806e6ccd8c79e002f721a1a5ecb847bd7a06489）

指标：

  • 验证 Dragonfly 颁布的后果是否可重现，并确定检索后果的残缺条件（鉴于 memtier_benchmark、操作系统版本等信息有所缺失）
  • 确定 AWS c6gn.16xlarge 实例上可实现的最佳 OSS Redis 7.0.0 集群性能，并与 Dragonfly 的基准测试后果相比拟

客户端配置：

  • OSS Redis 7.0 解决方案须要大量接入 Redis 集群的凋谢连贯，因为每个 memtier_benchmark 线程都须要连贯到所有分片
  • OSS Redis 7.0 解决方案在应用两个 memtier_benchmark 过程时问题最好，而且为了与 Dragonfly 基准相适应，这两个过程运行在同样的客户端虚拟机上

资源利用与配置优化：

  • OSS Redis 集群在 40 个主分片的配置下性能体现最佳，对应的就是虚拟机上有 24 个备用 vCPU。尽管设施资源仍未失去全副利用，但咱们发现持续减少分片数量曾经没有意义，反而会拉低整体性能。咱们仍在考察具体起因。
  • 另一方面，Dragonfly 解决方案彻底耗尽了虚拟机性能，所有 64 上 vCPU 均达到了 100% 利用率。
  • 在两种解决方案中，咱们调整了客户端配置以实现最佳后果。如下所示，咱们胜利重现了大部分 Dragonfly 基准数据，甚至在 30 通道条件下得出了比我的项目方更高的测试问题。
  • 本次测试强调与 Dragonfly 测试环境保持一致，如果调整测试环境，Redis 的问题还有望进一步晋升。

最初，咱们还发现 Redis 和 Dragonfly 都不受网络每秒数据包或传输带宽的限度。

咱们曾经确认在 2 个虚拟机间（别离作为客户端和服务器，且均应用 c6gn.16xlarge 实例）应用 TCP 传递约 300 B 大小的数据包负载时，能够让每秒数据包传输量达到 1000 万以上、传输带宽超过 30 Gbps。

剖析后果

单 GET 通道提早低于 1 毫秒：

  • OSS Redis：每秒 443 万次操作，其中提早平均值与第 50 百分位值均达到亚毫秒级别。均匀客户端提早为 0.383 毫秒。
  • Dragonfly 宣称每秒 400 万次操作：

–

    • 咱们胜利重现至每秒 380 万次操作，均匀客户端提早为 0.390 毫秒
      –
  • Redis 对 Dragonfly——Redis 吞吐量比 Dragonfly 宣称的后果高出 10%，比咱们胜利重现的 Dragonfly 后果高 18%。

30 条 GET 通道：

  • OSS Redis：每秒 2290 万次操作，客户端均匀提早为 2.239 毫秒
  • Dragonfly 宣称每秒可达 1500 万次操作：

–

    • 咱们胜利重现了每秒 1590 万次操作，客户端均匀提早为 3.99 毫秒
      –
  • Redis 对 Dragonfly——与 Dragonfly 的重现后果和宣称后果相比，Redis 别离胜出 43% 和 52%

单 SET 通道提早低于 1 毫秒：

  • OSS Redis：每秒 474 万次操作，提早平均值与第 50 百分位值均达到亚毫秒级。客户端均匀提早为 0.391 毫秒
  • Dragonfly 宣称每秒 400 万次操作：

–

    • 咱们胜利重现了每秒 400 万次操作，客户端均匀提早为 0.500 毫秒
      –
  • Redis 对 Dragonfly——与 Dragonfly 的重现后果和宣称后果相比，Redis 均胜出 19%

30 条 SET 通道:

  • OSS Redis：每秒 1985 万次操作，客户端均匀提早为 2.879 毫秒
  • Dragonfly 宣称每秒 1000 万次操作：

–

    • 咱们胜利重现了每秒 1400 万次操作，客户端均匀提早为 4.203 毫秒
      –
  • Redis 对 Dragonfly——与 Dragonfly 的重现后果和宣称后果相比，Redis 别离胜出 42% 和 99%

用于各变体的 memtier_benchmark 命令：

单 GET 通道提早低于 1 毫秒

  • Redis:2X: memtier_benchmark –ratio 0:1 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram
  • Dragonfly:memtier_benchmark –ratio 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram

30 条 GET 通道

  • Redis:2X: memtier_benchmark –ratio 0:1 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram –pipeline 30
  • Dragonfly:memtier_benchmark –ratio 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram –pipeline 30

单 SET 通道提早低于 1 毫秒

  • Redis:2X: memtier_benchmark –ratio 1:0 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram
  • Dragonfly:memtier_benchmark –ratio 1:0 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram

30 条 SET 通道

  • Redis:2X: memtier_benchmark –ratio 1:0 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram –pipeline 30
  • Dragonfly:memtier_benchmark –ratio 1:0 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram –pipeline 30

测试设施细节

在本次比拟测试中，咱们在客户端（用于运行 memtier_benchmark）和服务器（用于运行 Redis 和 Dragonfly）应用了雷同的虚拟机类型，具体规格为：

  • 虚拟机：AWS c6gn.16xlarge
  • aarch64
  • ARM Neoverse-N1
  • 每插槽外围数: 64
  • 每外围线程数: 1
  • NUMA 节点数: 1
  • 外围版本: Arm64 Kernel 5.10
  • 装置内存: 126 GB

参考链接：

https://redis.com/blog/redis-…

https://www.reddit.com/r/prog…

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)

2. 劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！

退出移动版