Dragonfly：号称比 Redis 快 25 倍的内存数据库

Dragonfly 是什么？

Dragonfly 是一种内存数据库，与 Redis 和 Memcached API 均100% 兼容。

这表示它与你当前在 Redis 实例中使用的所有相同的 SDK 和工具是兼容的，不用修改代码。

2022年，一位前谷歌、前亚马逊的工程师推出了他创作的开源内存数据缓存系统 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 诞生了十多年，这时从头开始设计一个缓存系统，可以抛弃历史包袱，更好地利用资源。

官方称将吞吐量提高25倍以上

通过有效地使用多线程并利用最新的研究（比后来的研究更多），Dragonfly 开发人员能够将吞吐量提高25 倍，提高缓存命中率并减少尾部延迟。

为何可以这么快？

Dragonfly 于 2022 年开始作为设计内存数据存储的实验。该团队借鉴了内存存储用户和云工程师的经验，优先考虑了两个关键功能：所有操作的原子性保证以及低、亚毫秒级延迟以实现高吞吐量。

为了有效利用当前公有云服务器上的CPU、内存和I/O资源，采用了无共享架构
这种方法在线程之间划分内存存储的键空间，每个线程管理自己的“分片”。
用于线程和 I/O 管理的开源库为这种无共享架构提供了支持。
对于多键操作，原子性保证是通过利用最近的学术研究来实现的。

主内存数据库系统的锁管理器重新设计”指导了 Dragonfly 事务框架的开发。通过结合无共享架构和 VLL，可以在不需要互斥锁或自旋锁的情况下组合原子多键操作，这使 Dragonfly 与其他解决方案区分开来。

该团队的第二个挑战，涉及为新商店创建更高效的数据结构。

核心哈希表结构基于论文“ Dash：持久内存上的可扩展哈希”。

尽管最初关注的是持久内存，但其概念适用于当前的问题。其文档中建议的哈希表设计保留了两个重要的属性：数据存储增长期间的增量哈希以及使用无状态扫描操作在更改下遍历字典的能力。

此外，Dash 还提高了 CPU 和内存效率，下面对其进行了评测。代码如下：

func setdragoFly(b *testing.B) {
 client := redis.NewClient(&redis.Options{  Addr:     "127.0.0.1:6376",  Password: "",  DB:       0,  PoolSize: 10, }) err := client.Ping(context.Background()).Err() if err != nil {  log.Fatal(err) } b.N = 1e4 ctx := context.Background() for n := 0; n < b.N; n++ {  val := fmt.Sprintf("bench%d", n)  client.Set(ctx,   fmt.Sprintf("key%d", n),   val, time.Duration(time.Minute*1)) }}
func setRedis(b *testing.B) {
 client := redis.NewClient(&redis.Options{  Addr:     "127.0.0.1:6379",  Password: "",  DB:       0,  PoolSize: 10, }) err := client.Ping(context.Background()).Err() if err != nil {  log.Fatal(err) } b.N = 1e4 ctx := context.Background() for n := 0; n < b.N; n++ {  val := fmt.Sprintf("bench%d", n)  client.Set(ctx,   fmt.Sprintf("key%d", n),   val, time.Duration(time.Minute*1)) }}

首先，我们来比较一下上面提到的集合操作。


func  getdragoFly (b *testing.B) {
client := redis.NewClient(&redis.Options{  Addr:      "127.0.0.1:6376" ,  Password: "" ,  DB:        0 ,  PoolSize: 10 ,})err := client .Ping(context.Background()).Err()  if err != nil {  log.Fatal(err)}bN = 1e4 ctx := context.Background()  for n := 0 ; n < bN；n++ {  _, err := client.Get(ctx, fmt.Sprintf( "key%d" , n)).Result()   iferr == redis.Nil || err != nil {    log.Fatalf( "Dragonfly 数据丢失 %d - err: %v" , n, err)   } } } 
func  getRedis (b *testing.B) { 
client := redis.NewClient(&redis.Options{  Addr:      "127.0.0.1:6379" ,  Password: "" ,   DB:        0 ,   PoolSize: 10 , }) err := client.Ping(context.Background()).Err()  if err != nil {   log. Fatal(err) } bN = 1e4 ctx := context.Background()  forn：= 0；n < bN；n++ {   _, err := client.Get(ctx, fmt.Sprintf( "key%d" , n)).Result()   if err == redis.Nil || err != nil {    log. Fatalf( "redis 数据丢失 %d - err: %v" , n, err)   } } }

接下来我们再来对比一下get操作的性能。

func main() {
 fmt.Println("TEST BENCHMARK DragonFly VS Redis")
 fmt.Println("==================================")
 fmt.Println("========Compare Set=========")
 fmt.Println("DragonFly : ", testing.Benchmark(setdragoFly))
 fmt.Println("Redis : ", testing.Benchmark(setRedis))
 fmt.Println()
 fmt.Println("=======Compare Get=========")
 fmt.Println("DragonFly : ", testing.Benchmark(getdragoFly))
 fmt.Println("Redis : ", testing.Benchmark(getRedis))
}

好吧，让我们继续运行基准测试。

然而，与他们的说法相反，我们可以看到，根据结果，DragonFly 尽管稍微慢一点，实际上比 Redis 慢。

两个内存数据库的未来

据称 DragonFlyDB 除了速度之外还有很多优势。根据他们提供的基准，它在大容量服务中表现出了出色的性能。然而，我们必须认识到，在资源较低的环境中，效率可能不会压倒性地优于 Redis，具体取决于其服务架构。

Dragonfly 1.0 是一个重要的里程碑，是第一个生产就绪的更新，但只是一个开始。

该团队的目标是帮助开发人员和公司轻松创建快速、可扩展的应用程序。挑战依然存在，他们将利用最近筹集的 2100 万美元资金来发展 Dragonfly，扩展其用例并处理更大的工作负载。

下一阶段将采用SSD存储来扩展主内存，同时保持低延迟并降低成本。
此外，他们还将为那些喜欢托管基础设施的人推出云产品。注册候补名单以获取最新信息。

此外，他们声称已经实现了一种允许较低内存使用和垂直扩展的操作方法。这可以被认为是一个重要的优点，因为它可以更有效地利用资源。

然而，在考虑 DragonFly 时，重要的是不要仅仅依赖垂直缩放。集群本质上提供了服务零停机等好处。然而，当我们处于公司初期或引入新项目时，如果我们能够通过垂直扩展来暂时维持服务，以应对流量的快速增长，同时建立集群，而不用担心服务停机，DragonFly 就可以成为一个强大的工具。因此，在我看来，现阶段它可能不会完全取代Redis，但在未来，Redis和DragonFly很可能成为强有力的竞争对手。

结语

有人认为 Dragonfly 从长远来看将取代 Redis，并将彻底改变内存存储解决方案。

它在每个场景中都更好：消耗更少的内存，具有（高得多）更高的吞吐量，并且很快将与现有系统 100% 兼容！

有的开发者已经决定将它用于自己的项目，看来对其充满信息。

希望大家喜欢阅读这篇文章，欢迎多点赞转发，您会发现更多有趣的东西。

祝你有美好的一天！