dragonfly

其他语言：简体中文 日本語 한국어

网站 • 文档 • 快速开始 • 社区 Discord • Dragonfly 论坛 • 加入 Dragonfly 社区

GitHub 讨论 • GitHub 问题 • 贡献指南 • Dragonfly 云服务

世界上最高效的内存数据存储

Dragonfly 是为现代应用程序工作负载构建的内存数据存储。

完全兼容 Redis 和 Memcached API，无需修改代码即可采用 Dragonfly。与传统的内存数据存储相比，Dragonfly 提供了 25 倍的吞吐量，更高的缓存命中率和更低的尾部延迟，并且可以在相同规模的工作负载下使用少 80% 的资源运行。

目录

• 基准测试
• 快速开始
• 配置
• 路线图和状态
• 设计决策
• 背景
• 从源代码构建

基准测试

我们首先在 m5.large 实例上比较 Dragonfly 和 Redis，由于 Redis 的单线程架构，这种实例通常用于运行 Redis。基准测试程序从同一可用区的另一个负载测试实例（c5n）运行，使用 memtier_benchmark -c 20 --test-time 100 -t 4 -d 256 --distinct-client-seed

Dragonfly 显示了可比的性能：

1. SET 操作（--ratio 1:0）：

Redis	DF
QPS: 159K, P99.9: 1.16ms, P99: 0.82ms	QPS:173K, P99.9: 1.26ms, P99: 0.9ms

2. GET 操作（--ratio 0:1）：

Redis	DF
QPS: 194K, P99.9: 0.8ms, P99: 0.65ms	QPS: 191K, P99.9: 0.95ms, P99: 0.8ms

上面的基准测试表明，DF 内部允许其垂直扩展的算法层在单线程运行时并不会造成大的性能损失。

然而，如果我们使用稍微强一些的实例（m5.xlarge），DF 和 Redis 之间的差距开始扩大。 （memtier_benchmark -c 20 --test-time 100 -t 6 -d 256 --distinct-client-seed）：

1. SET 操作（--ratio 1:0）：

Redis	DF
QPS: 190K, P99.9: 2.45ms, P99: 0.97ms	QPS: 279K , P99.9: 1.95ms, P99: 1.48

2. GET 操作（--ratio 0:1）：

Redis	DF
QPS: 220K, P99.9: 0.98ms , P99: 0.8ms	QPS: 305K, P99.9: 1.03ms, P99: 0.87ms

Dragonfly 的吞吐量容量随着实例大小的增加而持续增长，而单线程 Redis 在 CPU 上受到瓶颈，在性能方面达到局部最大值。

如果我们在网络能力最强的实例 c6gn.16xlarge 上比较 Dragonfly 和 Redis，Dragonfly 显示出比 Redis 单进程高 25 倍的吞吐量增长，超过 380 万 QPS。

Dragonfly 在其峰值吞吐量下的第 99 百分位延迟指标：

操作	r6g	c6gn	c7g
set	0.8毫秒	1毫秒	1毫秒
get	0.9毫秒	0.9毫秒	0.8毫秒
setex	0.9毫秒	1.1毫秒	1.3毫秒

所有基准测试都是使用memtier_benchmark进行的（见下文），根据服务器和实例类型调整线程数。memtier在单独的c6gn.16xlarge机器上运行。我们将SETEX基准测试的过期时间设置为500，以确保它能在测试结束时存活。

  memtier_benchmark --ratio ... -t <threads> -c 30 -n 200000 --distinct-client-seed -d 256 \
     --expiry-range=...

在流水线模式下--pipeline=30，Dragonfly在SET操作中达到每秒1000万次查询，在GET操作中达到每秒1500万次查询。

Dragonfly vs. Memcached

我们在AWS的c6gn.16xlarge实例上比较了Dragonfly和Memcached。

在可比的延迟下，Dragonfly的吞吐量在写入和读取工作负载中都优于Memcached。由于Memcached写入路径上的竞争，Dragonfly在写入工作负载中表现出更好的延迟。

SET基准测试

服务器	QPS（千次每秒）	99%延迟	99.9%延迟
Dragonfly	🟩 3844	🟩 0.9毫秒	🟩 2.4毫秒
Memcached	806	1.6毫秒	3.2毫秒

GET基准测试

服务器	QPS（千次每秒）	99%延迟	99.9%延迟
Dragonfly	🟩 3717	1毫秒	2.4毫秒
Memcached	2100	🟩 0.34毫秒	🟩 0.6毫秒

Memcached在读取基准测试中表现出更低的延迟，但吞吐量也较低。

内存效率

为测试内存效率，我们使用debug populate 5000000 key 1024命令向Dragonfly和Redis填充了约5GB的数据，用memtier发送更新流量，并用bgsave命令启动快照。

这张图展示了每个服务器在内存效率方面的表现。

在空闲状态下，Dragonfly比Redis的内存效率高30%，在快照阶段没有显示任何明显的内存使用增加。在峰值时，Redis的内存使用量增加到Dragonfly的近3倍。

Dragonfly在几秒钟内就完成了快照。

关于Dragonfly的内存效率的更多信息，请参见我们的Dashtable文档。

配置

• memcached_port：启用Memcached兼容API的端口（默认：禁用）。

• keys_output_limit：keys命令返回的最大键数（默认：8192）。注意，keys是一个危险的命令。我们截断其结果以避免在获取过多键时内存使用量激增。

• dbnum：select支持的最大数据库数。

• cache_mode：参见下面的新型缓存设计部分。

• hz：键过期评估频率（默认：100）。较低的频率在空闲时使用更少的CPU，但代价是较慢的驱逐率。

• snapshot_cron：自动备份快照的cron调度表达式，使用标准cron语法，精确到分钟（默认：""）。 以下是一些cron调度表达式示例，你可以在我们的文档中阅读更多关于此参数的信息。 | Cron 调度表达式 | 描述 | |--------------------------|--------------------------------------------| | * * * * * | 每分钟 | | */5 * * * * | 每5分钟 | | 5 */2 * * * | 每2小时的第5分钟 | | 0 0 * * * | 每天00:00（午夜） | | 0 6 * * 1-5 | 周一至周五的06:00（黎明） |

• primary_port_http_enabled：如果为true，允许在主TCP端口上访问HTTP控制台（默认：true）。

• admin_port：在指定端口上启用管理员访问控制台（默认：禁用）。支持HTTP和RESP协议。

• admin_bind：将管理员控制台TCP连接绑定到指定地址（默认：任意）。支持HTTP和RESP协议。

• admin_nopass：在指定端口上启用开放的管理员访问控制台，无需认证令牌（默认：false）。支持HTTP和RESP协议。

• cluster_mode：支持的集群模式（默认：""）。目前仅支持emulated。

• announce_ip：集群命令向客户端和复制主节点宣告的IP。

• announce_port：集群命令向客户端和复制主节点宣告的端口。

常用选项的示例启动脚本：

./dragonfly-x86_64 --logtostderr --requirepass=youshallnotpass --cache_mode=true -dbnum 1 --bind localhost --port 6379 --maxmemory=12gb --keys_output_limit=12288 --dbfilename dump.rdb

参数也可以通过以下方式提供：

• --flagfile <文件名>：文件中每行列出一个标志，键值标志使用等号而不是空格。标志值不需要引号。
• 设置环境变量。设置DFLY_x，其中x是标志的确切名称，区分大小写。

有关日志管理或TLS支持等更多选项，请运行dragonfly --help。

路线图和状态

Dragonfly目前支持约185个Redis命令和除cas外的所有Memcached命令。几乎与Redis 5 API相当，Dragonfly的下一个里程碑将是稳定基本功能并实现复制API。如果您需要尚未实现的命令，请提出问题。

对于Dragonfly原生复制，我们正在设计一种分布式日志格式，将支持数量级更高的速度。

在复制功能之后，我们将继续添加Redis 3-6 API中缺失的命令。

请查看我们的命令参考了解Dragonfly当前支持的命令。

设计决策

新型缓存设计

Dragonfly有一个单一的、统一的、自适应的缓存算法，简单且内存高效。

您可以通过传递--cache_mode=true标志来启用缓存模式。一旦启用此模式，Dragonfly将在接近maxmemory限制时驱逐最不可能在未来被访问的项目。

相对精确的过期期限

过期范围限制在约8年内。

对于大于2^28毫秒的期限，毫秒精度的过期期限（PEXPIRE、PSETEX等）会四舍五入到最接近的秒，误差小于0.001%，对于大范围应该是可以接受的。如果这不适合您的用例，请联系我们或提出问题说明您的情况。

有关Dragonfly过期期限与Redis实现之间的更详细差异，请参见此处。

原生HTTP控制台和Prometheus兼容指标

默认情况下，Dragonfly允许通过其主TCP端口（6379）进行HTTP访问。没错，您可以通过Redis协议和HTTP协议连接到Dragonfly——服务器在连接初始化期间自动识别协议。请尝试使用浏览器访问。HTTP访问目前没有太多信息，但将来会包含有用的调试和管理信息。

访问:6379/metrics URL以查看Prometheus兼容指标。

导出的Prometheus指标与Grafana仪表板兼容，请参见此处。

重要！HTTP控制台旨在安全网络内访问。如果您对外暴露Dragonfly的TCP端口，我们建议您使用--http_admin_console=false或--nohttp_admin_console禁用控制台。

背景

Dragonfly始于一个实验，旨在探索如果在2022年设计内存数据存储会是什么样子。基于我们作为内存存储用户和为云公司工作的工程师的经验教训，我们知道需要为Dragonfly保留两个关键属性：所有操作的原子性保证以及在非常高的吞吐量下的低延迟（亚毫秒级）。

我们的第一个挑战是如何充分利用当今公共云中可用的服务器的CPU、内存和I/O资源。为解决这个问题，我们使用无共享架构，它允许我们在线程之间分区内存存储的键空间，使每个线程可以管理自己的字典数据切片。我们称这些切片为"分片"。为无共享架构提供线程和I/O管理的库在此处开源。

为了为多键操作提供原子性保证，我们使用了最新学术研究的进展。我们选择了论文"VLL: a lock manager redesign for main memory database systems"来开发Dragonfly的事务框架。无共享架构和VLL的选择使我们能够在不使用互斥锁或自旋锁的情况下组合原子多键操作。这是我们概念验证的一个重要里程碑，其性能在商业和开源解决方案中脱颖而出。 我们的第二个挑战是为新的存储系统设计更高效的数据结构。为了实现这个目标，我们基于论文《Dash：持久性内存上的可扩展哈希》设计了核心哈希表结构。该论文主要关注持久性内存领域，与主内存存储并不直接相关，但仍然最适用于我们的问题。论文中提出的哈希表设计让我们能够保持Redis字典中的两个特性：数据存储增长过程中的渐进式哈希能力，以及使用无状态扫描操作在变化中遍历字典的能力。除了这两个特性外，Dash在CPU和内存使用方面更加高效。借鉴Dash的设计，我们进一步创新了以下功能：

• 对TTL记录进行高效的过期处理。
• 一种新颖的缓存淘汰算法，比LRU和LFU等其他缓存策略能达到更高的命中率，且无内存开销。
• 一种新颖的无分叉快照算法。

在为Dragonfly构建好基础并对其性能感到满意后，我们着手实现Redis和Memcached的功能。到目前为止，我们已经实现了约185个Redis命令（大致相当于Redis 5.0 API）和13个Memcached命令。

最后，

我们的使命是为云工作负载构建一个设计良好、超高速、高成本效益的内存数据存储，充分利用最新的硬件进步。我们旨在解决当前解决方案的痛点，同时保留其产品API和价值主张。