Lettuce v5.1版本Redis请求未分发至所有从节点的问题排查与相关咨询
问题背景
我在Micronaut中使用Lettuce客户端连接Redis，当前客户端版本是5.1，依赖的lettuce-core库版本为6.1.6-RELEASE。我的应用是高TPS场景，最近发现Redis响应时间接近1秒，但连接超时设置的是180ms，所以排除了连接建立耗时的问题。
进一步排查后发现，通过Redis线程日志看到Lettuce会缓存主节点对应的从候选节点，导致所有读请求都集中打到同一个从节点上。我们的架构是5个主节点，每个主节点配2个从节点，共15个实例，我原本预期同一主节点的读请求会均匀分发到它的所有从节点。
Lettuce团队针对这个问题的修复是实现从节点候选的随机选择，该功能在Lettuce 5.2.0版本中正式发布。
我的假设验证请求
我自己分析：因为Lettuce采用响应式处理，应用线程不会阻塞等待获取Redis连接，所以连接超时不会触发；但每个从节点一次只能处理一个请求，后续请求都会排队等待资源，这就导致了监控里的响应时间居高不下。想请大家帮忙验证这个假设是否正确。
已做的排查尝试
- 研究了Lettuce团队实现从节点随机选择的代码变更，确认该修复逻辑是为了解决请求集中到单一从节点的问题
- 检查了Redis服务器的慢日志，确认所有查询的执行耗时都在正常范围内，排除了Redis端的性能问题
我的疑问
- 文档说明该修复在5.2版本中引入，但我在5.1版本的代码里也看到了相关逻辑，是不是因为我们依赖的
lettuce-core是最新版本，所以代码变更已经包含在核心库中？ - 我们的业务只需要从从节点读数据，打算设置
ReadFrom.Any_Replica，压测结果看起来正常，但因为相关文档和资源较少，想知道使用这个配置时有没有需要注意的问题？比如高TPS场景下，选择从节点的CPU开销会不会很高？
专家解答
关于响应时间高的假设验证
你的分析完全合理！在Lettuce 5.1版本的默认逻辑中，确实会固定选择同一个从节点作为主节点的读请求目标，在高TPS场景下，单个从节点很快会成为性能瓶颈。虽然响应式模型让应用线程不会阻塞在获取连接上，但从节点的处理能力是有限的，所有请求集中到一个节点会导致请求排队等待，最终直接体现在整体响应时间飙升，这和你观察到的现象完全匹配。
疑问解答
版本与代码逻辑的矛盾问题：Lettuce客户端版本（比如Micronaut集成的starter版本）和
lettuce-core核心库版本是对应但独立的体系。你当前用的是Micronaut封装的Lettuce 5.1客户端，但依赖的lettuce-core是6.1.6-RELEASE——这个核心库版本属于更高的分支，已经包含了从节点随机选择的修复逻辑，所以你会在代码里看到对应实现。不过要注意，Micronaut的starter封装可能会对配置生效有影响，建议你通过日志或监控确认客户端实际的ReadFrom配置是否真的触发了从节点的负载均衡。ReadFrom.Any_Replica的使用注意事项：- CPU开销问题：完全不用担心！Lettuce选择从节点的逻辑非常轻量级，只是在可用从节点列表中做简单的随机或轮询（具体取决于核心库版本），没有复杂的计算，在高TPS场景下的CPU开销可以忽略不计。
- 额外注意点：
- 确保Redis集群的从节点状态稳定可用，Lettuce会自动剔除不可用节点，但如果节点频繁上下线，会产生少量状态检查的额外开销
- 如果你需要更精细化的负载均衡策略（比如基于节点的CPU、内存负载），Lettuce支持自定义
NodeSelectionStrategy，但默认的随机/轮询策略已经能满足绝大多数高TPS场景的需求 - 配置完成后一定要监控从节点的负载情况，确认请求确实均匀分发到了所有从节点，避免因配置未生效再次出现单点瓶颈
备注：内容来源于stack exchange，提问作者Aditya k
