Dragonfly 接入 Spring Boot：别把 Redis 兼容误读成无风险迁移

Dragonfly 适合被认真评估，但不适合被当作“Redis 免费性能外挂”直接替换。它的卖点很清楚：兼容 Redis/Memcached 协议、线程按核心扩展、单实例吞吐更高、内存效率更好。对 Spring Boot 项目来说，吸引力也很直接：Lettuce、Jedis、Spring Data Redis 这条链路大多可以继续用，迁移看起来像改连接地址。

真正要判断的不是“能不能连上”，而是你的系统是否依赖 Redis 的边缘命令、AOF 习惯、Cluster 语义、延迟分布和故障恢复流程。缓存可以大胆试，核心状态要谨慎迁。

先从缓存层试，不要从账本层试

Spring Boot 里最适合先试 Dragonfly 的场景，是可重建缓存、热点读取、会话外的临时状态、限流计数和排行榜这类可容错数据。它们能体现高吞吐和低延迟，也允许你用灰度方式回滚。

不建议第一步就迁移订单状态、支付幂等、强一致队列或不可丢业务事件。即使协议兼容，也不代表运维模型完全等价。

接入 Spring Boot 的最小路径

大多数 Java 应用不需要新客户端。先在测试环境启动 Dragonfly，保持 Redis 协议端口，然后让 Spring Data Redis 指向新的 host/port。业务代码不该感知底层是 Redis 还是 Dragonfly。

如果用了 Redisson、Lua 脚本、Pipeline、Pub/Sub、Streams、Bitmap 或冷门命令，要逐项跑兼容性测试。迁移前的命令画像比“官方兼容”四个字更重要。

压测要看尾延迟和恢复，不只看 QPS

官方和社区基准经常强调吞吐，但生产系统更怕尾延迟、快照时抖动、主从切换、连接池耗尽和内存临界点。评估 Dragonfly 时，至少要测三组：常态读写、高峰写入、快照/重启/复制期间的行为。