缓存中间件选型别只看功能清单缓存产品的命令清单只能说明它宣称支持什么不能说明在项目自己的 Key 分布、批量大小和故障条件下会怎样工作。Redis Cluster 直连和 Proxy 都可能合适差别在于路由职责放在哪里以及团队能否观察、扩容和恢复新增的那一层。先拿到真实访问形状选型前从调用端统计命令、请求与 Value 大小、连接数和 Key 的访问分布。平均 QPS 会掩盖热点整体还有余量某个 Slot 所在节点已先饱和。增加节点也不会自动分散一个 Hot Key因为同一 Key 仍落在同一个 Slot。MGET、Pipeline 和 Lua 应单独验证。多 Key 操作常有同 Slot 约束客户端或 Proxy 是否拆分、并发还是串行、部分失败怎样返回都取决于实现与版本。Hash Tag 能让相关 Key 落到同一 Slot却也可能制造新的热点不能只为绕开约束而使用。压测至少覆盖常见批量、热点比例、大 Value、连接重建与节点迁移并同时看后端节点、客户端重定向、Proxy 队列和错误类别。直连和代理是不同责任划分直连时每种语言客户端要负责 Slot 路由、拓扑刷新、TLS、认证和重试优点是路径短缺点是多语言能力需要逐一核对。Proxy 能集中这些逻辑使客户端简单但它自身也成为需要扩容、监控和故障旁路的服务。不要默认 Proxy 一定有 Hot Key 本地缓存即便有也必须确认一致性、失效、容量与故障切换语义。写命令在响应丢失时可能已经成功自动重试必须受幂等语义约束。数据库中间件也是同样道理能解析 SQL 不代表路由符合分片规则。用真实 SQL 模板验证路由、绑定参数、排序分页、事务读写、会话状态和不支持语句的行为比对比功能表更可信。public String get(String key) { if (!localCacheAllowed.test(key)) return redis.opsForValue().get(key); String cached localCache.getIfPresent(key); if (cached ! null) return cached; String value redis.opsForValue().get(key); if (value ! null) localCache.put(key, value); return value; }本地缓存只适合允许短暂旧值、失效机制明确且容量可控的数据。库存、余额等强一致读取不能随意复制到每个应用实例。实际实现还需要请求合并防止集体回源写入和删除后的主动失效以及对空值、实例数放大和缓存穿透的处理。迁移时不要只切换一半流量就停止观察。应确认客户端拓扑刷新、TLS 与认证、连接超时、故障转移和监控标签在新旧路径中都一致出现异常时能否按 Key、Slot、节点和调用方快速定位。缓存层的问题通常不是单个命令报错而是边界条件下的延迟累积。选型结论应能被复查支持哪些命令跨 Slot 怎么处理热点怎样发现节点和 Proxy 故障时谁负责重试、如何旁路升级怎样回滚。把项目自己的请求和失败场景跑一遍才知道“支持”二字是否真的适用于这里。