你在项目中使用的 Redis 客户端是什么？
- 标签：后端、Redis
🏛 业务架构师
我的标准选型是：Spring Boot 默认的 Lettuce + 需要分布式锁等高级能力时的 Redisson。
三类客户端的业务定位：
- Jedis：老牌、API 直观，但连接模型是阻塞式、每实例一个连接，多线程要靠连接池。功能全但连接管理粗放，如今多见于存量系统；
- Lettuce：基于 Netty 的异步驱动，连接可安全共享（线程安全，单连接也能支撑高并发，必要时再扩），支持异步/响应式（与 WebFlux 配合）。Spring Boot 2 起默认——默认即代表社区共识与长期维护红利；
- Redisson：定位不是"客户端"而是"分布式中间件库"——分布式锁（看门狗续期）、布隆过滤器、限流器、延迟队列、Map/List 的分布式实现。用它不是为了执行命令，是为了白拿一整套分布式原语。
我的组合策略：日常读写用 Lettuce（随 Boot 默认，零配置心智）；用到锁、布隆过滤器时引入 Redisson，两者可以共存（各自连接，注意连接资源预算）。
选型之外的经验之谈：
- 客户端版本要与 Redis Server 版本兼容（RESP2/RESP3、命令支持差异），升级 Redis 前先核对客户端矩阵——见过升级服务端后秒级命令报错的案例；
- 连接池参数是容量问题：max-active 要与业务并发对齐，超时时间要配（默认无限等待是事故源）；
- 监控接上：连接数、命令延迟、慢命令，客户端无监控等于裸奔。
一句话：默认驱动选社区默认（Lettuce），高级能力交给 Redisson，省下的精力做业务。
🏗 系统架构师
我生产用 Redisson，选型理由从架构角色讲：
- Lettuce（Spring Boot 2.x 起默认）：基于 Netty 的异步非阻塞连接，连接共享（单连接多线程复用），线程安全，支持响应式，资源占用小——纯缓存读写场景它是性能与资源效率最优解；
- Jedis：老牌同步客户端，简单直白，但连接不线程安全要靠连接池，命令阻塞模型在高并发下线程开销大，现在多见于老系统；
- Redisson：定位不是"客户端"而是分布式中间件——分布式锁（可重入、看门狗、公平锁、读写锁）、限流器（RRateLimiter）、布隆过滤器、延迟队列（RDelayedQueue）、分布式集合、Spring Cache 注解集成。底层基于 Netty 异步，也支持 Lettuce 式的响应调用。
我的组合用法：普通缓存走 Spring Data Redis（底层 Lettuce）+ 注解缓存抽象；分布式协调类需求（锁、限流、延迟任务）统一 Redisson——让团队不必自己拼装 Lua 脚本和重试逻辑，官方实现踩过的坑（误删、续期、可重入）比自研覆盖得全。也提醒团队：Redisson 的锁与限流是"尽力而为"语义，正确性兜底仍在 DB 约束与幂等设计。
💻 全栈开发专家
我的选型和理由：Lettuce（Spring Boot 2.x 起默认）+ 复杂场景上 Redisson。
三者对比：
- Jedis：老牌，简单直连模型，命令和方法一一对应；连接不是线程安全的，必须配连接池（JedisPool），多线程下借还开销大。现在主要出现在老项目。
- Lettuce：基于 Netty 的同步/异步/响应式客户端，连接线程安全（单连接多路复用，省连接数），支持 Cluster 拓扑自动刷新，Spring Boot 默认就是它。
- Redisson：定位不是"客户端"而是分布式数据结构：RLock、RBloomFilter、RMap、RQueue、RRateLimiter、延迟队列 RDelayedQueue，把 Redis 当分布式内存用。
我的常用配置（Lettuce + 池化）：
yaml
spring:
data:
redis:
lettuce:
pool:
max-active: 32
max-idle: 16
shutdown-timeout: 200ms
timeout: 2s # 命令超时，防止慢查询拖死调用方踩坑提醒：
- 生产必配
timeout和command timeout，默认无限等待会把 Tomcat 线程池全挂在 Redis 上； - Cluster 模式下 Lettuce 要开自适应拓扑刷新，否则主从切换后连旧节点报错；
- 我用 Redisson 的 RLock/RRateLimiter 时确认它是独立连接，和业务 Lettuce 池隔离，互不拖累。