redis集群数据不自动均匀分布，关键在于crc16(key)%16384对前缀敏感，需避免固定前缀、冷热分离、大key拆分；客户端连接池配置不当易压垮服务；缓存穿透与击穿需结合场景选布隆过滤器或逻辑过期；读写分离须警惕主从延迟导致一致性问题。
缓存数据分片不等于简单哈希取模
Redis 单实例扛不住高并发或大数据量时，直接上 redis-cluster 是常见选择，但很多团队误以为只要用 CLUSTER 模式，数据就自动“均匀”了。实际不是——KEY 设计不合理，会导致大量热 KEY 落在同一个 Slot，进而压垮某个节点。
真正起作用的是 CRC16(key) % 16384 这个计算逻辑，而它对字符串前缀高度敏感。比如所有订单都用 "order:123"、"order:456" 这种格式，CRC16 结果容易扎堆。
- 避免固定前缀：把
"order:{uid}:{id}"改成"{uid}:order:{id}"，让哈希因子更分散 - 冷热分离：用户资料类缓存（读多写少）和会话类缓存（TTL 短、更新频繁）不要混在同一个集群，否则淘汰策略互相干扰
- 大 KEY 拆分：一个
"user:1001:profile"存几百 MB？不如拆成"user:1001:profile:basic"、"user:1001:profile:settings"等多个小 KEY
连接池配置不当会让客户端拖垮 Redis
Java 用 Lettuce、Python 用 redis-py 时，默认连接池参数往往照搬示例，结果在高 QPS 下出现大量 Connection reset by peer 或超时，其实问题不在 Redis，而在客户端没控住连接数和复用节奏。
Redis 是单线程处理命令的，但每个 TCP 连接都要占用服务端 fd 和内存。如果客户端每秒建 1000 个新连接又不复用，Redis 很快达到 maxclients 上限，开始拒绝新连接。
-
lettuce中maxConnections建议设为 16–64，别盲目调到 200+；同时打开poolRecycle避免长连接空闲老化 -
redis-py的ConnectionPool(max_connections=100)不等于安全——得配合socket_keepalive=True和合理的socket_connect_timeout - 微服务间共享一个 Redis 连接池？危险。不同业务的流量峰谷错位，A 服务突发打满连接池，B 服务直接卡死
缓存穿透和击穿不是加个布隆过滤器就能解决
缓存穿透（查不存在的 KEY）和击穿（热点 KEY 过期瞬间被并发请求打穿）常被归为“防御性问题”，但上线后仍频繁触发 MISS，说明方案没对齐真实流量特征。
布隆过滤器能挡掉大部分无效 KEY，但它有误判率，且无法动态更新；而缓存击穿靠互斥锁（如 SETNX）保护重建，若锁过期时间设短了，可能还没加载完就释放，导致多次重建。
- 布隆过滤器只适合 KEY 格式稳定、总量可预估的场景（如用户 ID），不适合含时间戳或随机字符串的 KEY（如
"token:abc123"） - 击穿防护中，
SET key value EX 300 NX的EX必须大于后端加载耗时 + 安全余量，否则锁失效比加载还快 - 更稳妥的做法是“逻辑过期”：value 里自带时间戳字段，过期不删 KEY，只在读取时判断是否需异步刷新，避免阻塞
从主从切换到读写分离要小心复制延迟
用 redis-py 或 Lettuce 配置读写分离时，很多人以为写主库、读从库就能提升吞吐，结果发现刚写入的数据立刻读不到——这不是 bug，是 Redis 主从复制的天然延迟，尤其在网络抖动或从库负载高时，延迟可达数百毫秒。
这种延迟在秒杀、库存扣减、用户状态变更等强一致性场景下不可接受，硬上读写分离反而引入数据不一致。
- 读写分离只适用于“写后不立即读”的场景，比如日志聚合、统计报表类查询
- 必须读最新数据时，强制走主库：Lettuce 用
ReadFrom.MASTER，redis-py用connection_pool.get_master_connection() - 别依赖
WAIT 1 1000命令来等同步——它只保证至少 1 个从库收到，不保证已执行，且会阻塞主库响应
缓存架构最难的不是选组件，而是把 KEY 生命周期、客户端行为、网络波动、Redis 内部机制这几层耦合关系理清楚。漏掉任意一层，资源集中就不是“会不会发生”，而是“什么时候爆发”。
