深入DragonflyDB核心技术：从DashTable到Fiber调度

颜妙瑶Titus

497人浏览 · 2025-06-01 09:03:31

颜妙瑶Titus · 2025-06-01 09:03:31 发布

深入DragonflyDB核心技术：从DashTable到Fiber调度

【免费下载链接】dragonfly dragonflydb/dragonfly: DragonflyDB 是一个高性能分布式KV存储系统，旨在提供低延迟、高吞吐量的数据访问能力，适用于大规模数据存储和检索场景。项目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly

DragonflyDB作为高性能内存数据库，其核心技术包括创新的DashTable哈希表实现和基于Fiber的协程调度机制。DashTable采用分段式架构和现代硬件优化设计，提供卓越的内存效率和并发性能。Fiber调度系统通过用户态协程实现高效的异步处理，避免了传统线程上下文切换的开销。本文深入探讨这些核心技术的设计原理、实现细节和性能优势。

DashTable哈希表的创新设计与实现原理

DragonflyDB的核心存储引擎采用了名为DashTable的创新哈希表实现，这是一种基于现代硬件特性优化的高性能数据结构。DashTable的设计灵感来源于1979年的可扩展哈希（Extendible Hashing）算法，但在内存效率、并发性能和扩展性方面进行了根本性的改进。

架构设计理念

DashTable采用分段式哈希表架构，将整个哈希表划分为多个独立的段（Segment），每个段包含固定数量的桶（Bucket）。这种设计实现了真正的共享无架构（Shared-Nothing Architecture），允许不同段在不同的CPU核心上并行处理，充分利用现代多核处理器的计算能力。

mermaid

核心数据结构组成

段（Segment）结构

每个DashTable段是一个自包含的哈希表单元，包含56个常规桶和4个备用桶（Stash Buckets）。每个桶包含14个槽位，总容量为840个键值对。这种设计在内存局部性和冲突处理之间取得了最佳平衡。

struct DefaultSegmentPolicy {
  static constexpr unsigned kSlotNum = 12;      // 每个桶的槽位数
  static constexpr unsigned kBucketNum = 64;    // 常规桶数量
  static constexpr unsigned kStashBucketNum = 4; // 备用桶数量
  static constexpr bool kUseVersion = true;     // 版本控制支持
};

桶（Bucket）实现

每个桶使用高效的位图管理来跟踪槽位的使用状态，大幅减少了元数据开销：

template <unsigned NUM_SLOTS> class SlotBitmap {
  // 使用紧凑的位表示法管理槽位状态
  uint32_t GetBusy() const;    // 获取占用槽位掩码
  uint32_t GetProbe(bool probe) const; // 获取探测状态掩码
  int FindEmptySlot() const;   // 查找空槽位
  void ClearSlots(uint32_t mask); // 清理指定槽位
};

创新性内存管理

指纹哈希技术

DashTable采用8位指纹哈希（Fingerprint Hash）来快速过滤不匹配的键，减少完整键比较的开销：

uint32_t CompareFP(uint8_t fp) const {
  // 使用SIMD指令快速比较指纹
  return _mm_movemask_epi8(_mm_cmpeq_epi8(
      _mm_set1_epi8(fp), _mm_loadu_si128((__m128i*)finger_arr_)));
}

版本化存储

DashTable实现了高效的版本控制系统，每个桶共享高6位版本号，各槽位存储低2位版本号，大幅减少了版本存储开销：

template <unsigned NUM_SLOTS> class VersionedBB : public BucketBase<NUM_SLOTS> {
  uint8_t version_[8] = {0}; // 共享的高位版本号
  // 各槽位存储低位版本号，减少内存占用
};

高效的插入算法

DashTable的插入过程采用多级探测策略，确保高性能的同时维持低延迟：

主桶探测：首先在哈希确定的主桶中寻找空槽位
邻接桶探测：主桶满时检查右侧邻接桶
备用桶回退：前两者都满时使用备用桶
段分裂机制：当所有桶都满时触发段分裂

std::pair<iterator, bool> InsertInternal(U&& key, V&& value, 
                                       EvictionPolicy& ev, InsertMode mode) {
  uint64_t hash = DoHash(key);
  unsigned seg_id = GetSegmentId(hash);
  SegmentType* segment = segment_[seg_id];
  
  // 多级插入尝试
  auto result = segment->Insert(key, value, hash, policy_);
  if (result.second) {
    size_++;
    return {CreateIterator(seg_id, result.first), true};
  }
  
  // 触发段分裂和重新插入
  if (NeedSplit(segment)) {
    SplitSegment(seg_id);
    return InsertInternal(std::forward<U>(key), std::forward<V>(value), ev, mode);
  }
  
  return {end(), false};
}

性能优化特性

缓存友好设计

DashTable的段目录大小经过精心设计，通常可以完全放入CPU的L1缓存中。每个段的大小为固定值，确保内存访问模式的可预测性。

增量扩展机制

与传统哈希表需要分配整个新桶数组不同，DashTable的扩展是增量式的，每次只添加一个新段，避免了大规模内存分配造成的延迟峰值。

零拷贝迭代

DashTable提供了稳定的遍历接口，即使在表扩展期间也能保证遍历的正确性：

template <typename Cb> 
Cursor Traverse(Cursor curs, Cb&& cb) {
  // 保证在表突变期间的遍历稳定性
  while (curs.value() != 0) {
    auto it = CursorToBucketIt(curs);
    if (it.Valid()) {
      cb(it);
    }
    curs = AdvanceCursor(curs);
  }
  return curs;
}

内存效率对比

与传统Redis字典相比，DashTable在内存使用方面具有显著优势：

指标	Redis字典	DashTable	改进幅度
元数据开销	16-32字节/项	6-16字节/项	50-75%
扩展峰值内存	48N字节	O(1)常量	显著降低
缓存命中率	较低	高	提升明显

实际应用效果

在标准测试中，DashTable展示了卓越的性能表现：

单线程填充：相比Redis 6，速度快48%，内存使用减少42%
多线程填充：8核环境下速度提升近8倍，内存效率保持优异
快照期间：内存使用峰值降低67%，快照完成时间大幅缩短

DashTable的创新设计不仅提供了更高的性能和更低的内存开销，还为DragonflyDB的其他高级特性（如无fork快照、智能过期策略等）奠定了坚实的基础。其分段式架构和精细的内存管理机制使其成为现代内存数据库的理想存储引擎。

Fiber协程调度机制与异步处理模型

DragonflyDB采用基于Fiber（协程）的高性能异步处理模型，这是其实现高吞吐量和低延迟的关键技术之一。该模型充分利用现代多核CPU架构，通过用户态协程调度避免了传统线程上下文切换的开销。

Fiber协程架构设计

DragonflyDB使用Helio库提供的Fiber实现，构建了一个高效的用户态协程调度系统。每个Proactor线程管理多个Fiber，通过协作式调度实现高效的并发处理。

mermaid

核心调度机制

1. Fiber创建与启动

DragonflyDB通过LaunchFiber方法创建和启动新的协程：

// 示例：创建快照调度Fiber
watchdog_fiber_ = pp_->GetNextProactor()->LaunchFiber([this] {
    ThisFiber::SetName("Watchdog");
    // 监控逻辑...
});

// 示例：并行处理多个任务
auto fb0 = pp_->at(0)->LaunchFiber(Launch::dispatch, [&] {
    // 任务1逻辑
});
auto fb1 = pp_->at(1)->LaunchFiber(Launch::dispatch, [&] {
    // 任务2逻辑
});

2. 协作式调度与Yield机制

Fiber之间通过协作式调度实现CPU时间分配，关键操作包括：

// 主动让出CPU
util::ThisFiber::Yield();

// 带超时的等待
ThisFiber::SleepFor(50us);

// 设置Fiber名称用于调试
ThisFiber::SetName("SnapshotScheduling");

3. 跨Fiber同步与通信

DragonflyDB使用多种同步原语确保线程安全：

同步机制	使用场景	示例代码
Mutex	保护共享资源	`fb2::Mutex m; std::unique_lock lk(m);`
ConditionVariable	线程间通知	`schedule_done_.WaitFor(100ms)`
Channel	生产者-消费者	`util::fb2::SimpleChannel`

异步I/O处理模型

1. 文件I/O异步化

DragonflyDB将耗时的文件操作封装为异步任务：

// 异步文件读取示例
auto fb = proactor->LaunchFiber([&] {
    io::ReadonlyFileOrError res = snapshot_storage_->OpenReadFile(rdb_file);
    if (!res) {
        result = res.error();
        return;
    }
    // 异步处理文件内容
    io::FileSource fs(*res);
    // ... 文件处理逻辑
});

2. 网络I/O异步处理

网络请求也采用异步模式，避免阻塞主线程：

// 异步DNS解析
#include "util/fibers/dns_resolve.h"

// 异步协议处理
error_code ProtocolClient::Recv(FiberSocketBase* input, base::IoBuf* dest) {
    // 异步接收数据
}

3. 批量并行处理

通过AwaitFiberOnAll实现跨所有线程的并行处理：

// 在所有Shard上并行执行任务
shard_set->pool()->AwaitFiberOnAll([&](unsigned index, ProactorBase* base) {
    ThisFiber::SetName("Watchdog");
    // 在每个Shard上执行监控逻辑
});

// 数据加载时的并行处理
pool.AwaitFiberOnAll([val](auto index, auto* context) {
    // 并行加载数据到各个Shard
});

内存管理与栈分配

DragonflyDB对Fiber栈内存进行精细控制：

// 不同构建模式的栈大小配置
#ifdef NDEBUG
constexpr size_t kFiberDefaultStackSize = 32_KB - 16;
#elif defined SANITIZERS
constexpr size_t kFiberDefaultStackSize = 64_KB - 16;
#else
constexpr size_t kFiberDefaultStackSize = 50_KB - 16;
#endif

// 栈资源初始化
fb2::SetDefaultStackResource(&fb2::std_malloc_resource, kFiberDefaultStackSize);

任务队列与负载均衡

DragonflyDB实现了一个高效的MPSC（多生产者单消费者）任务队列：

class TaskQueue {
public:
    TaskQueue(unsigned queue_size, unsigned pool_start_size, unsigned pool_max_size);
    
    template <typename F> bool TryAdd(F&& f);
    template <typename F> bool Add(F&& f);
    template <typename F> auto Await(F&& f) -> decltype(f());
    
    void Start(std::string_view base_name);
    void Shutdown();
};

错误处理与监控

1. Fiber级错误处理

每个Fiber都有独立的错误处理机制：

ExecutionState::~ExecutionState() {
    DCHECK(!err_handler_fb_.IsJoinable());
    err_handler_fb_.JoinIfNeeded();
}

GenericError ExecutionState::GetError() const {
    std::lock_guard lk(err_mu_);
    return err_;
}

2. 死锁检测与调试

内置Watchdog Fiber用于检测死锁和调试：

watchdog_fiber_ = pp_->GetNextProactor()->LaunchFiber([this] {
    ThisFiber::SetName("Watchdog");
    if (!watchdog_done_.WaitFor(20s)) {
        LOG(ERROR) << "Deadlock detected!!!!";
        // 打印所有Fiber的堆栈跟踪
        fb2::detail::FiberInterface::PrintAllFiberStackTraces();
    }
});

性能优化策略

1. 栈内存复用

通过自定义内存分配器减少栈内存分配开销：

// 使用mi_malloc进行栈内存分配
init_zmalloc_threadlocal(mi_heap_get_backing());

2. 批量操作优化

利用Fiber的轻量级特性实现批量操作：

// 批量键操作
shard_set->pool()->AwaitFiberOnAll(add_keys);

// 并行快照处理
std::vector<fb2::Fiber> load_fibers;
for (auto& file : files) {
    load_fibers.push_back(proactor->LaunchFiber(std::move(load_func)));
}

3. I/O多路复用集成

与io_uring/epoll集成实现真正的异步I/O：

#ifdef __linux__
if (absl::GetFlag(FLAGS_force_epoll)) {
    pp_.reset(fb2::Pool::Epoll(num_threads_));
} else {
    pp_.reset(fb2::Pool::IOUring(16, num_threads_));
}
#else
pp_.reset(fb2::Pool::Epoll(num_threads_));
#endif

实际应用场景

1. 快照调度

void ServerFamily::SnapshotScheduling() {
    // 在独立Fiber中运行快照调度
    service_.proactor_pool().GetNextProactor()->LaunchFiber([this] { 
        SnapshotScheduling(); 
    });
    
    // 定时任务处理
    while (true) {
        const std::chrono::time_point now = std::chrono::system_clock::now();
        const std::chrono::time_point next = cron::cron_next(cron_expr.value(), now);
        
        if (schedule_done_.WaitFor(next - now)) {
            break;
        };
        
        GenericError ec = DoSave(); // 异步执行快照
    }
}

2. 数据加载

// 多文件并行加载
std::vector<fb2::Fiber> load_fibers;
for (auto& load_spec : load_specs) {
    auto load_func = [&, load_spec] {
        // 单个文件的加载逻辑
    };
    load_fibers.push_back(proactor->LaunchFiber(std::move(load_func)));
}

3. 事务处理

mermaid

DragonflyDB的Fiber协程调度机制通过精细的资源管理和高效的异步处理模型，实现了卓越的性能表现。其设计充分考虑了现代多核处理器的特性，通过用户态协程避免了内核态线程切换的开销，同时保持了编程模型的简洁性。这种架构使得DragonflyDB能够在高并发场景下保持稳定的低延迟和高吞吐量，为内存数据库的性能设定了新的标准。

内存管理优化与零开销缓存算法

DragonflyDB在内存管理方面采用了多项创新技术，实现了业界领先的内存效率和零开销缓存算法。这些优化使得DragonflyDB在相同硬件条件下能够存储更多数据，同时保持极低的延迟和高吞吐量。

内存分配器优化

DragonflyDB采用了mimalloc作为其内存分配器，这是一个由Microsoft开发的高性能内存分配器。mimalloc相比传统的malloc实现具有以下优势：

更小的内存碎片：通过使用大小分类的堆和延迟释放机制
更好的缓存局部性：分配器针对现代CPU缓存层次结构进行了优化
更低的开销：每个分配的开销仅为4字节，远低于传统分配器

class MiMemoryResource : public PMR_NS::memory_resource {
public:
    explicit MiMemoryResource(mi_heap_t* heap) : heap_(heap) {}
    
    size_t used() const {
        return used_;
    }
    
private:
    void* do_allocate(std::size_t size, std::size_t align) final {
        void* res = mi_heap_malloc_aligned(heap_, size, align);
        size_t delta = mi_usable_size(res);
        used_ += delta;
        return res;
    }
    
    mi_heap_t* heap_;
    size_t used_ = 0;
};

分段分配器设计

DragonflyDB实现了高效的分段分配器（SegmentAllocator），它通过紧凑的指针表示（4字节指针）在64位地址空间上提供32GB的分配能力，并可扩展到32*256GB。

mermaid

分段分配器的核心优势：

特性	传统分配器	DragonflyDB分段分配器
指针大小	8字节	4字节
地址空间	完整64位	32GB基础，可扩展
内存开销	高	极低
缓存友好性	一般	优秀

DashTable内存优化

DragonflyDB的核心数据结构DashTable在内存使用方面相比Redis字典有显著优势：

mermaid

内存使用对比分析：

场景	Redis字典	DragonflyDB DashTable
100%负载因子	32N字节	19N字节
75%负载因子	34N字节	22N字节
50%负载因子	40N字节	32N字节
增量调整峰值	48N字节	19N + 段大小

零开销缓存算法

DragonflyDB的缓存算法实现了真正的零内存开销，通过智能的逐出策略和内存预算管理：

class PrimeEvictionPolicy {
public:
    static constexpr bool can_evict = true;
    static constexpr bool can_gc = true;
    
    PrimeEvictionPolicy(const DbContext& cntx, bool can_evict, 
                       ssize_t mem_offset, ssize_t soft_limit,
                       DbSlice* db_slice, bool apply_memory_limit);
    
    bool CanGrow(const PrimeTable& tbl) const;
    unsigned GarbageCollect(const PrimeTable::HotBuckets& eb, PrimeTable* me);
    unsigned Evict(const PrimeTable::HotBuckets& eb, PrimeTable* me);
};

缓存算法的核心机制：

内存预算管理：每个分片维护独立的内存预算，动态调整
智能逐出策略：基于访问模式和内存压力自动选择逐出目标
垃圾回收：在段分裂时进行高效的过期项清理
渐进式扫描：避免一次性大规模扫描对性能的影响

内存回收与压缩

DragonflyDB实现了高效的内存回收机制：

unsigned PrimeEvictionPolicy::GarbageCollect(const PrimeTable::HotBuckets& eb, PrimeTable* me) {
    unsigned res = 0;
    string scratch;
    
    // 基于测试，常规桶的垃圾回收效率更高
    unsigned num_buckets = std::min<unsigned>(PrimeTable::HotBuckets::kRegularBuckets, eb.num_buckets);
    for (unsigned i = 0; i < num_buckets; ++i) {
        auto bucket_it = eb.at(i);
        for (; !bucket_it.is_done(); ++bucket_it) {
            if (bucket_it->second.HasExpire()) {
                string_view key = bucket_it->first.GetSlice(&scratch);
                ++checked_;
                auto [prime_it, exp_it] = db_slice_->ExpireIfNeeded(
                    cntx_, DbSlice::Iterator(bucket_it, StringOrView::FromView(key)));
                if (prime_it.is_done())
                    ++res;
            }
        }
    }
    return res;
}

性能优化策略

DragonflyDB采用了多种性能优化策略：

缓存行对齐：确保数据结构对齐到缓存行边界
预取优化：在访问前预取相关内存区域
写时复制：减少不必要的内存拷贝
内存池化：重用已分配的内存块

实际效果验证

通过基准测试验证，DragonflyDB在内存效率方面表现出色：

内存使用减少30%：相比Redis，在相同数据集下内存使用减少30%
零开销缓存：缓存模式下的内存开销几乎为零
平滑内存增长：避免内存使用的剧烈波动
高效垃圾回收：GC操作对性能影响极小

这些优化使得DragonflyDB成为内存敏感应用的理想选择，特别是在云环境和容器化部署中，内存效率直接关系到运营成本和性能表现。

事务处理与原子性保证机制

DragonflyDB作为高性能内存数据库，在事务处理方面采用了创新的架构设计，既保持了Redis兼容性，又通过先进的锁管理和调度机制实现了卓越的性能表现。其事务系统基于VLL（Very Lightweight Locking）锁管理器设计理念，为多键操作提供强原子性保证。

事务架构核心设计

DragonflyDB的事务系统采用分层架构，通过Transaction类作为核心构建块，支持多种事务模式：

mermaid

多模式事务执行

DragonflyDB支持三种主要的事务执行模式，每种模式针对不同的使用场景进行优化：

1. 全局事务模式 (GLOBAL)

全局事务在所有分片上执行，适用于需要跨多个分片进行原子性操作的场景。这种模式下，事务会锁定所有涉及的分片，确保操作的全局一致性。

// 全局事务初始化示例
void Transaction::StartMultiGlobal(Namespace* ns, DbIndex dbid) {
    multi_->mode = GLOBAL;
    InitBase(ns, dbid, {});
    InitGlobal();
}

2. 预锁定模式 (LOCK_AHEAD)

在预锁定模式下，事务在执行前会预先获取所有相关键的锁。这种模式适用于已知所有操作键的事务，能够减少锁竞争和提高并行度。

// 预锁定事务初始化
void Transaction::StartMultiLockedAhead(Namespace* ns, DbIndex dbid, 
                                       CmdArgList keys, bool skip_scheduling) {
    multi_->mode = LOCK_AHEAD;
    InitBase(ns, dbid, {});
    PrepareMultiFps(keys);
    if (!skip_scheduling) {
        Schedule();  // 预调度获取锁
    }
}

3. 非原子模式 (NON_ATOMIC)

非原子模式将事务作为流水线执行，每个命令独立执行，不保证原子性但提供更高的吞吐量，适用于不需要严格原子性保证的场景。

意图锁机制

DragonflyDB采用创新的意图锁（IntentLock）机制来管理并发访问，支持共享(SHARED)和独占(EXCLUSIVE)两种模式：

class IntentLock {
public:
    enum Mode { SHARED = 0, EXCLUSIVE = 1 };
    
    bool Acquire(Mode m) {
        ++cnt_[m];
        if (cnt_[1 ^ int(m)]) return false;
        return m == SHARED || cnt_[EXCLUSIVE] == 1;
    }
    
    bool Check(Mode m) const {
        unsigned s = cnt_[EXCLUSIVE];
        if (s) return false;
        return (m == SHARED) ? true : cnt_[SHARED] == 0;
    }
};

锁管理采用轻量级设计，通过指纹（Fingerprint）机制快速定位锁对象，避免字符串比较开销：

锁类型	适用场景	并发特性	性能影响
共享锁	读操作	允许多个读并发	低开销
独占锁	写操作	排他性访问	中等开销

多命令压缩执行

DragonflyDB引入了多命令压缩（Multi-Command Squashing）技术，将多个单分片命令批量执行，显著减少调度开销：

mermaid

压缩执行的核心优势：

并行化执行：单分片命令在多个分片上并行执行
减少调度开销：批量处理减少事务调度次数
保持原子性：在原子事务模式下仍保证操作原子性

WATCH机制实现

DragonflyDB的WATCH机制通过阻塞控制器（BlockingController）实现键监听功能：

class BlockingController {
public:
    void AddWatched(Keys watch_keys, KeyReadyChecker krc, Transaction* trans) {
        auto [dbit, added] = watched_dbs_.emplace(trans->GetDbIndex(), nullptr);
        for (auto key : watch_keys) {
            // 注册监听键和事务
            it->second.watched_keys[key].emplace(trans, krc);
        }
    }
    
    bool NotifyWatched(DbIndex db_indx, string_view key) {
        auto it = watched_dbs_.find(db_indx);
        if (it != watched_dbs_.end()) {
            // 通知监听该键的所有事务
            return it->second.NotifyKey(key);
        }
        return false;
    }
};

WATCH机制工作流程：

客户端通过WATCH key命令注册监听
系统记录键与事务的映射关系
当监听的键被修改时，通知相关事务
事务执行时检查监听状态，如果键被修改则中止执行

事务调度与Fiber集成

DragonflyDB的事务调度与Fiber系统紧密集成，实现高效的协程调度：

调度阶段	执行内容	Fiber使用	性能优化
事务初始化	解析命令和键	主Fiber	快速路径解析
锁获取	意图锁申请	工作Fiber	并行锁获取
命令执行	分片回调执行	分片Fiber	本地化执行
结果收集	响应组装	IO Fiber	零拷贝传输

事务执行采用Hop（跳转）模型，每个Hop代表在特定分片上的一次回调执行：

OpStatus Transaction::ScheduleSingleHop(RunnableType cb) {
    // 调度单次Hop执行
    Execute(cb, true);
    return local_result_;
}

原子性保证策略

DragonflyDB通过多层次的原子性保证策略确保数据一致性：

键级别原子性：通过意图锁保证单个键操作的原子性
分片级别原子性：每个分片内的操作保证原子性
全局原子性：通过事务协调器保证跨分片操作的原子性
持久化原子性：快照机制保证持久化操作的原子性

性能优化技术

事务系统采用多种性能优化技术：

锁优化策略：

细粒度锁：键级别锁减少锁竞争
乐观执行：在可能的情况下避免悲观锁
锁压缩：合并相邻的锁操作

调度优化：

批处理调度：合并多个操作减少调度开销
本地化执行：尽可能在数据所在分片执行
异步通知：非阻塞的事件通知机制

内存管理：

对象池：重用事务对象减少内存分配
紧凑布局：优化内存访问模式
预分配：预先分配所需资源

错误处理与恢复

事务系统具备完善的错误处理机制：

enum OpStatus {
    OK = 0,
    KEY_NOTFOUND,
    WRONG_TYPE,
    OUT_OF_MEMORY,
    INVALID_INTEGER,
    OUT_OF_RANGE,
    SYNTAX_ERR,
    EXEC_ABORT  // 事务执行中止
};

错误处理流程：

命令验证阶段检测语法和参数错误
执行阶段检测运行时错误（类型不匹配、内存不足等）
事务中止时自动回滚所有已执行操作
系统状态保持一致性，不会出现部分更新

DragonflyDB的事务系统通过创新的架构设计和精细的性能优化，在保持Redis兼容性的同时，实现了显著更高的吞吐量和更低的延迟，为现代应用提供了可靠的高性能事务处理能力。

总结

DragonflyDB通过DashTable哈希表、Fiber协程调度、内存管理优化和事务处理机制等核心技术，实现了卓越的性能表现。DashTable提供了高效的内存使用和并发处理能力，Fiber调度实现了低延迟和高吞吐量，内存管理优化显著减少了内存开销，事务系统保证了数据的一致性和原子性。这些创新设计使DragonflyDB成为现代内存数据库的理想选择，为高性能应用提供了可靠的基础设施支持。