Redisson 4.7：别把 Redis 客户端写成万能电网
Redisson 官方文档列出的基本盘很清楚：它基于 Netty，提供同步、异步和响应式 API，支持 Redis 3.0 以上、Valkey 7.2.5 以上、分布式对象、锁、集合、pipeline、本地缓存和多种部署模式。原帖把这些能力和“虚拟线程 3～5 倍、全抖动重连、Vector Set、RCircularBuffer”都归到一次 4.7 升级里，范围有点大，至少要区分核心 OSS、PRO 和底层 Valkey/Redis 版本。
向量检索这一项尤其要拆开。Redisson 自己的资料显示，Redis Vector Set 需要 Redis 8+；Valkey 路线则依赖 valkey-search 等模块，能力并不等于“所有 Redis/Valkey 都内置同一套 HNSW”。把向量集合说成 Redisson 自己提供的分布式 HNSW，容易让人误以为升级 Java 包就能获得一个统一向量数据库。真实部署还要看索引构建、过滤、量化和删除策略。
Jittered backoff 也不是魔法：它通过随机退避避免故障恢复时所有实例同时重连，能减轻 thundering herd；但它不能保证服务一定恢复，也不能替系统定义最大重试次数、超时和熔断。Redisson 的 local cache、Pub/Sub 失效、Redis Streams 都有各自的延迟和一致性边界。把“本地缓存命中很快”说成“全网强一致”，相当于把楼里的小卖部当成市政仓库。
分布式锁更不能只看“拿到了”。看门狗会续租，但进程长时间 GC、暂停或网络分区时，租约仍可能到期；需要写入幂等键时，最好使用 fencing token 或数据库条件更新。锁的语义是互斥，锁持有者身份和过期后的旧请求，才是真正容易在夜里把人叫醒的部分。
我会把 Redisson 4.7 当作工具箱，而不是“次世代基础设施标准”。选型报告应附上同一模型的 p99、连接池等待、锁持有时长、故障切换时间、Pub/Sub 失效延迟和向量召回率；企业版功能要单独标红。工具箱里的锤子不会因为版本号更新就自动知道该敲哪颗钉子。
来源：
- https://redisson.pro/docs/
- https://redisson.pro/blog/vector-similarity-search-in-valkey-redis-on-java.html
- https://redisson.pro/blog/exponential-backoff-and-jitter-in-java.html