作者广泛使用 Redis 处理各种后端任务，如缓存、会话和队列。最近，作者探索了 Dragonfly，这是一个兼容但架构不同的替代方案。Dragonfly 基于 Redis API，但采用多线程、无共享架构，以充分利用现代多核处理器。这与 Redis 主要采用单线程执行形成对比，后者是为在旧硬件上实现简单性和可预测性而设计的。Dragonfly 因其协议兼容性而易于集成。其潜在优势在工作负载变为 CPU 或内存瓶颈时显现，此时其架构可提供性能提升。然而，Dragonfly 是一个较新的项目，存在一些粗糙之处。其持久化仅支持快照，缺乏 Redis 的 AOF 选项以实现细粒度的持久性。Lua 脚本的行为可能有所不同，尤其是涉及动态生成的键时，且多键操作会产生协调开销。集群管理方式也不同，且与某些高级 Redis 模块的兼容性尚未得到保证。作者指出，Dragonfly 的缺陷列表虽然正在增长，但与 Redis 的成熟度相比仍处于早期阶段。Redis 在其长期稳定性、稳健的持久性选项、庞大的生态系统支持以及所有功能上的可预测行为方面仍具有优势。两者的选择取决于具体的工作负载特征和运营需求。如果 Redis 能够舒适地处理工作负载，或者成熟度和生态系统至关重要，则 Redis 仍然适用。Dragonfly 值得在以下情况下进行评估：在大型机器上执行 CPU 密集型任务、内存效率是关键、或希望简化集群管理时，前提是快照持久化可接受。最终，两者都有合理的架构决策，最佳选择取决于具体项目的要求。