凌晨两点被电话叫起来原因是一条 Redis 慢查询告警某条 HGETALL 命令耗时 800ms把接口 P99 从 120ms 顶到了 900ms。登上机器一看那个 Hash 里塞了 260 万个 field整个 value 接近 300MB。这类事故在有一定体量的业务里几乎避不开所以我常拿“Redis 大key的判定标准与多key拆分方案”这个话题去面候选人——不是考背诵而是看这个人有没有真的在生产上救过火。这篇文章就把我在实际项目里踩过的、验证过的、以及面试时听到的好答案烂答案一次性摊开讲清楚。大key这件事说穿了不复杂单个 key 承载的数据量或访问量超出了 Redis 单线程模型能从容处理的范围。但它牵扯出的东西很多——内存分布、网络带宽、持久化、主从复制、集群槽位倾斜每一个都能独立把服务打挂。多key拆分是治理手段里最主流的一种但它不是万能药拆错了反而把简单问题搞复杂。下面这些内容适合三类人写业务代码时习惯hset一把梭的初中级开发、正在准备面试想搞明白原理的求职者以及线上已经出现慢查询需要紧急止血的运维同学。我会从判定标准讲到拆分设计再落到四类数据结构的可直接抄的代码最后把迁移和踩坑都过一遍。1. 大key的判定标准与被放大的三重危害1.1 多大算大三条不同口径的判定线很多人面试时被问“多大算大key”条件反射答“超过 10KB”。这个答案太单薄因为 String 和 Hash 的“大”根本不是一回事。我一般按三个口径分口径类型经验阈值典型触发的问题字节体积Stringvalue 10KB高频访问场景收紧到 1KB网络往返耗时、带宽占用元素数量Hash / List / Set / ZSet元素数 5000或总体积 1MBHGETALL、SMEMBERS、LRANGE 全量读阻塞访问热度任意类型单 key QPS 5000单节点集群槽位热点、单核 CPU 打满这三条线要分开看。一条 100KB 的 String 如果每秒读十万次它比一个 5MB 但一天只读一次的 Hash 危险得多反过来一个 200 万元素的 Set 哪怕 QPS 只有 10一次SMEMBERS也能让整个实例卡住半秒以上因为那 200 万个元素的序列化和网络发送全在 Redis 的单线程里做。字节线也不是拍脑袋定的。Redis 处理命令时value 需要走“读取-序列化-写入 socket 缓冲区”这条链10KB 大概对应一次 0.1ms 量级的处理而 1MB 就是 10ms 量级。业务侧通常要求 Redis 单次操作控制在 1ms 以内所以 10KB 是个比较务实的界。元素数量线的 5000 也是类似逻辑——5000 个短 field 拼起来差不多 100KB 到 300KB再大就该警惕。需要强调一点判定阈值必须跟业务场景绑定不能跨团队照抄。缓存型业务比如商品详情容忍度可以高一些因为读放大有 CDN 和本地缓存顶着而计数型、会话型的场景1KB 都算大。我在某个内容平台项目里定的规则就是“String 8KB 或集合类 2000 元素一律进周巡检名单”跑了一年多误报率很低。1.2 危害拆解一次大key阻塞的完整链路光说“会阻塞”太笼统我把它拆成五条链路每一条都能对上真实现象。第一条是命令执行阻塞。Redis 6.0 之后虽然引入了 IO 多线程处理网络读写但命令执行始终是单线程的。一个HGETALL返回 2MB 数据这 2MB 的遍历、内存拷贝、resp 协议编码全在那一个线程里完成期间所有其他客户端的命令都在排队。2MB 大概 10~20ms如果这个 key 被高频调用就变成持续性的排队雪崩。第二条是网络带宽挤占。假设一个 200 万元素的 Hash 被HGETALL每秒调用 50 次那就是 300MB × 50 15GB/s 的出流量。这个数字已经超出绝大多数实例的网卡上限结果是所有正常的请求都跟着超时。带宽打满的表面现象往往是“偶发超时”“连接池被打穿”跟大key好像没关系排查时特别容易走偏。第三条是删除阻塞这条最容易被忽略。你用DEL删一个 200 万元素的 HashRedis 需要先释放这 200 万个对象的引用、回收内存整个过程同步执行实测能卡住两三秒。正确做法是UNLINK它把内存回收丢到后台线程异步做主线程只做一次 key 摘除。Redis 4.0 才有 UNLINK老版本只能用SCAN 分批HDEL慢慢删。第四条是持久化放大。RDB 落盘时大key会导致fork之后的写时复制COW内存膨胀因为父进程在 fork 期间只要有写入被改动的内存页就要复制一份。一个 300MB 的 Hash 如果整体被改写可能直接多出几百 MB 的额外内存极端情况下触发 OOM。AOF 也是同理大key的一次写入会产生一条巨大的 AOF 记录重写和回放都会被拖慢。第五条是集群槽位倾斜。在集群模式下一个大key整体落在某一个槽上而槽又落到某一个节点上。结果是那个节点的内存和 CPU 使用率远高于其他节点扩容也没用——因为热点还是那一个槽。这种现象在监控图上非常典型所有节点的内存都在 40%就一个节点 85%。1.3 面试时真正被考察的思维链我面人的时候问“你怎么处理大key”最想听到的是一条完整的链怎么发现、怎么判定、怎么止血、怎么根治、怎么做长期防护。只答“拆成多个小key”的候选人我会追问“拆多少片、怎么算的、拆完原子性怎么办”多半就答不上来了。比较理想的回答层次是这样的先说发现手段--bigkeys扫描、MEMORY USAGE、慢日志、RDB 离线分析再说危害阻塞、带宽、持久化、倾斜然后给治理方案拆分、压缩、换存储最后补一句预防写入拦截、阈值告警、编码规范。这条链能完整走下来的人基本上手上是真管过 Redis 的。2. 拆分方案的整体设计先定维度再定粒度2.1 三条拆分主线及其适用边界拆分不是只有“按哈希取模”一条路。我把它归成三条主线选哪条取决于数据结构和读写模式。第一条是业务维度拆分。这是最自然的方式比如按用户 ID 拆、按租户拆、按业务线拆。典型例子是用户会话session:{uid}本身就是按用户分开的天然不构成大key。真正需要业务拆分的场景是“一个大对象里塞了多个业务域的数据”比如商品详情里既有基础属性又有营销信息又有库存快照正确做法是把它们拆成独立 key各自设不同的过期时间。第二条是哈希分桶拆分。适合单个业务对象的内部结构无法再细分的情况比如一个用户的画像标签有 5000 个字段。做法是对 field 名或元素本身做哈希取模落到 N 个桶里每个桶是一个独立的 key。这种方式拆分均匀度高代价是失去整体的原子性和一次性读取能力。第三条是 value 内部切片。主要针对超大 String比如一个 8MB 的 JSON 文档或一张 Base64 编码的图片。做法是按固定字节数切成若干片每片一个 key读取时重新拼装。还有一条补充思路值得单独提冷热分离。一个 5000 字段的对象实际高频访问的可能只有 20 个字段剩下的都是长尾。那就把热字段拎出来单独存一个小 Hash冷字段留在原地或者挪到冷存储。这个方案对读性能提升最明显改造量也最小但前提是你得先摸清楚访问分布——MONITOR采样或者客户端埋点都能拿到。2.2 桶数量的计算两个约束取最大值“拆几个桶”是最容易被敷衍过去的环节。我见过有人随手拆 10 个结果单桶还是 20 万 field等于没拆。正确的算法是同时满足两个约束约束一单桶元素数 ≤ 上限比如 1000约束二单桶字节数 ≤ 上限比如 1MB桶数 N max(ceil(总元素数 / 元素上限), ceil(总体积 / 字节上限))然后向上取到 2 的幂举个具体例子。某项目有个用户标签 Hash200 万个 field平均每个 field 加 value 约 100 字节总体积约 200MB。代入公式按元素数2,000,000 / 1000 2000 个桶按字节数200MB / 1MB 200 个桶取最大值 2000向上取 2 的幂得到 2048拆完平均每桶约 977 个 field、97KB 左右完全在安全范围内。选 2 的幂是为了把取模换成位与运算hash 2047比hash % 2048快一截虽然 Redis 侧其实不差这点但客户端侧调用量大的时候还是有点意义。注意桶数量一旦上线就尽量别再改。因为桶号是靠取模算出来的桶数从 2048 改成 1024所有历史数据的桶号全变等于要做一次全量迁移。所以初期宁可多拆一点留出增长空间。2.3 拆分前必须先回答的四个问题我每次做拆分方案评审都会强制要求把这四个问题写进文档里答不上来就不许动手。问题一读模式是单字段读还是整体读如果业务 90% 是整体读比如渲染整个详情页那拆成多个 key 之后需要 N 次往返或者一次 pipeline端到端延迟不一定下降这时候冷热分离比硬拆更合适。如果主要是单字段读拆分收益极大因为读一个字段只需要访问一个桶。问题二需不需要跨桶原子性如果需要就必须在 key 里加 hash tag比如profile:{12345}:0保证同一个对象的多个桶落在同一个槽上这样才能用 Lua 或者 MULTI 包起来。但加了 hash tag 就意味着所有桶压在同一个节点上失去了分散压力的意义。这是个明确的权衡点必须显式决策。问题三有没有顺序性要求List 拆片时尤其要注意。如果按时间窗口切片feed:{uid}:202506这种LPUSH的顺序天然保持新数据进新片没问题。但如果按成员哈希切片LRANGE出来的顺序就完全乱了。所以 List 一般不按哈希拆只按时间或按序号区间拆。问题四有没有全量遍历需求如果业务存在“遍历所有元素”的操作比如统计、导出、对账拆分之后就要遍历 N 个桶SCAN的复杂度上升。这时候要么维护一个索引 key 记录所有桶号要么接受遍历成本上升。3. 四类数据结构的可直接落地的拆分实践3.1 String 超大 value切片存储与拼装读取某项目的商品详情缓存是一个 8MB 的 JSON。直接GET的耗时接近 100ms而且每次大促前预热时会持续压满带宽。改造方案是按 64KB 切片。切片大小的选择有讲究。太小会导致 key 数量爆炸、pipeline 命令数过多太大则单片仍然偏重。64KB 到 256KB 是比较舒服的区间8MB 切成 64KB 是 128 片。public class ChunkedStringStore { private static final int CHUNK_SIZE 64 * 1024; private static final String PREFIX prod:detail:; private final StringRedisTemplate redis; public ChunkedStringStore(StringRedisTemplate redis) { this.redis redis; } public void put(String id, byte[] payload, Duration ttl) { int total (payload.length CHUNK_SIZE - 1) / CHUNK_SIZE; MapString, String batch new HashMap(total 1); for (int i 0; i total; i) { int from i * CHUNK_SIZE; int to Math.min(from CHUNK_SIZE, payload.length); byte[] slice Arrays.copyOfRange(payload, from, to); batch.put(chunkKey(id, i), Base64.getEncoder().encodeToString(slice)); } batch.put(metaKey(id), String.valueOf(total)); redis.executePipelined((RedisCallbackObject) conn - { batch.forEach((k, v) - { byte[] kb k.getBytes(StandardCharsets.UTF_8); byte[] vb v.getBytes(StandardCharsets.UTF_8); conn.stringCommands().setEx(kb, ttl.getSeconds(), vb); }); return null; }); } public byte[] get(String id) { String totalStr redis.opsForValue().get(metaKey(id)); if (totalStr null) { return null; } int total Integer.parseInt(totalStr); ListString keys new ArrayList(total); for (int i 0; i total; i) { keys.add(chunkKey(id, i)); } ListString slices redis.opsForValue().multiGet(keys); ByteArrayOutputStream out new ByteArrayOutputStream(total * CHUNK_SIZE); for (String s : slices) { if (s null) { return null; } out.writeBytes(Base64.getDecoder().decode(s)); } return out.toByteArray(); } private String chunkKey(String id, int idx) { return PREFIX id :seg: idx; } private String metaKey(String id) { return PREFIX id :meta; } }几个实操细节必须说明。第一切片是按字节切的绝对不能在中途把每一片单独按 UTF-8 解码——一个中文字符占 3 个字节很可能被切成两半解码就出乱码。正确的做法是全程保持byte[]全部拼完再统一 decode。上面这段代码用 Base64 编码后存 String是为了兼容StringRedisTemplate如果直接用RedisTemplateString, byte[]可以省掉编解码开销。第二片数要单独存一个 meta key否则读的时候根本不知道有多少片。meta key 的 TTL 要跟数据片一致但不能反过来——如果 meta 先过期了残留的数据片就变成孤儿 key只能靠定期扫描清理。第三读的时候用multiGet一次发出所有片请求StringRedisTemplate底层会走 pipeline128 次往返压缩成 1 次。如果不走集群模式这是最省事的方案。3.2 Hash 巨型对象二次哈希分桶用户画像、购物车、配置表这类数据基本都用 Hash 存。当 field 数量涨到几十万HGETALL就成了定时炸弹。分桶方案如下public class ShardedHash { private static final int BUCKETS 2048; private static final int MASK BUCKETS - 1; private static final String PREFIX profile:; private final StringRedisTemplate redis; public ShardedHash(StringRedisTemplate redis) { this.redis redis; } private int bucketOf(String field) { int h field.hashCode(); h ^ (h 16); return h MASK; } private String bucketKey(String uid, int bucket) { return PREFIX uid : bucket; } public void put(String uid, String field, String value) { redis.opsForHash().put(bucketKey(uid, bucketOf(field)), field, value); } public String get(String uid, String field) { Object v redis.opsForHash().get(bucketKey(uid, bucketOf(field)), field); return v null ? null : v.toString(); } public MapString, String getAll(String uid) { ListString keys new ArrayList(BUCKETS); for (int i 0; i BUCKETS; i) { keys.add(bucketKey(uid, i)); } ListObject results redis.executePipelined((RedisCallbackObject) conn - { for (String k : keys) { conn.hashCommands().hGetAll(k.getBytes(StandardCharsets.UTF_8)); } return null; }); MapString, String merged new HashMap(); for (Object r : results) { if (r instanceof Map) { ((Map?, ?) r).forEach((k, v) - merged.put(String.valueOf(k), String.valueOf(v))); } } return merged; } }这里最关键的实现点是哈希函数的选择。String.hashCode()对短字符串分布还行但对形如tag_0001、tag_0002这种有规律的 field 名低位容易聚集。所以我在上面做了h ^ (h 16)的高低位混淆跟 HashMap 里那套扰动函数是一个思路。如果 field 名规律性特别强建议直接上 CRC32 或者 MurmurHash分布更均匀。第二个点是空桶的处理。2048 个桶里如果这个用户只有 30 个字段那 2018 个桶都是不存在的空 key。HGETALL一个不存在的 key 返回空 Map代价很小但 2048 次 pipeline 调用仍然是实打实的开销。所以实际项目里我一般会做一个自适应桶数不是固定的 2048而是根据对象的实际字段数量动态算。字段少于 1000 的直接单 key 存超过才分桶桶数按 2.2 节的公式算出来存到 meta 里。第三个点是HGETALL的替代。很多业务其实只需要读部分字段那就用HMGET但HMGET要求所有 field 在同一个 key 里。分桶之后只能按桶分组每个桶发一次HMGET然后 pipeline 打包。写起来啰嗦但比全量读便宜得多。3.3 List / ZSet / Set按时间片和成员哈希切片这三类结构各有各的拆法不能混用一套模板。List 最合适按时间切片。消息流、操作日志、评论列表这类数据天然有时间维度key 设计成feed:{uid}:{yyyyMM}每个月一个 ListLPUSH新数据进当前月读的时候按需拼最近几个月。这样单 key 的元素数天然被时间窗口限制住了而且历史数据可以按需设置更长的 TTL 甚至归档。要注意的是跨片的范围查询想读最近 100 条可能需要读 2 到 3 个片然后合并好在LRANGE支持负数索引实现起来不复杂。ZSet 按周期切分最自然。排行榜类需求日榜rank:{yyyyMMdd}、周榜rank:{yyyyWW}、月榜rank:{yyyyMM}各存各的互不干扰。缺点是跨周期的聚合排序需要应用层归并。如果业务确实需要“全站总榜”那就得用定时任务把周期榜的结果汇总到一个总榜里而不是让客户端去实时归并。Set 只能按成员哈希拆。标签集合、好友关系这类数据没有天然的时间序只能对成员本身做哈希。tags:{id}:{bucket}判断是否包含某成员时先算出桶号再SISMEMBER。这里有个必须接受的代价SINTER、SUNION、SDIFF这些集合运算彻底没法用了因为参与运算的两个集合分片规则不同。如果业务强依赖集合运算那就老老实实别拆改用别的方案比如用 BitMap 或者换到支持集合运算的存储。3.4 实在拆不动的场景压缩、换存储与协议优化不是所有大key都能拆。有三种情况我建议放弃拆分换思路。第一种是强事务场景。比如库存扣减、账户余额它们的正确性依赖单 key 的原子操作。拆了之后跨 key 的原子性只能靠 Lua 或者分布式锁复杂度暴涨出问题的概率远高于收益。这类 key 本来就该小——余额只有一个数字怎么会大如果大了说明设计有问题该拆的是业务模型不是存储结构。第二种是超大二进制对象。视频、图片、安装包这类东西根本不该进 Redis。正确的做法是存到对象存储Redis 里只放一个指针URL 或 ID。我见过有人把 PDF 文件 Base64 之后塞进 Redis一个 key 十几 MB这种属于用错了工具。第三种是必须整体读的复杂聚合。如果一个 5MB 的 JSON 每次都要整体反序列化成对象那切片和拼装只是把一次大传输变成多次小传输总字节数没变CPU 侧的序列化开销反而更高。这时候更该做的是压缩——开启 value 压缩比如用 Snappy、LZ4 在应用层压一遍再存通常能压到原来的 20% 到 30%比拆分省事得多。或者考虑把这份数据从缓存层挪到搜索层、文档层。4. 迁移落地双写、灰度与一致性校验三板斧4.1 双写期的读写路由设计拆分方案想得再漂亮上线才是真正的考验。历史数据不能停机迁移所以必须要有一段双写期。路由逻辑我用一个统一的组件收口public class SplitRouter { private final StringRedisTemplate redis; private final SplitSwitch splitSwitch; public void write(String uid, String field, String value) { if (splitSwitch.isDualWrite(uid)) { redis.opsForHash().put(legacyKey(uid), field, value); } if (splitSwitch.isSplitRead(uid)) { shardedHash.put(uid, field, value); } } public String read(String uid, String field) { if (splitSwitch.isSplitRead(uid)) { String v shardedHash.get(uid, field); if (v ! null) { return v; } return legacyRead(uid, field); } return legacyRead(uid, field); } }设计要点有三个。第一写路径以新结构为准旧结构只做兼容即新结构写成功、旧结构写失败可以容忍反过来不行。第二读路径先读新结构miss 才回源旧结构这样迁移过程中不会出现读到空数据的情况。第三旧 key 的 TTL 不能直接删掉要持续续期否则双写期间一部分用户的数据会因为旧 key 过期而重新走回源逻辑读放大严重。双写期的长度取决于数据规模和访问频率。一般我建议至少覆盖一个完整的访问周期比如一周确保所有活跃用户的数据都被自然迁移过一遍。对于长期不活跃的用户可以在双写结束时跑一次全量迁移脚本兜底。4.2 灰度切流与回滚预案灰度必须按用户 ID 取模来切不能按流量随机切。原因是同一个用户的数据必须始终走同一套逻辑否则会出现“这次读新结构、下次读旧结构”的抖动数据对不上。灰度节奏我一般这么排5% 跑一天观察错误率和延迟没问题放到 20% 跑一天然后 50%、100%。每一档都要盯三个指标新结构的HGET延迟分布、旧结构的读命中率应该逐步下降、以及双写的失败计数。回滚预案必须在上线前就准备好而不是出事再想。具体就是配置中心里放一个开关把isSplitRead全部置为 false读流量瞬间全部回落到旧结构。这时候新结构还留着不影响数据等排查清楚再重新灰度。这个开关必须做到秒级生效不能依赖重启。注意回滚开关只管读不管写。双写逻辑一旦开启就不建议关掉因为关掉之后新结构就停止更新再想恢复又得重新补数据。所以开关要设计成“读写分离的两个开关”而不是一个总开关。4.3 一致性校验的脚本实现思路双写期间最怕的是“以为写进去了其实没有”。所以要跑对账。校验的核心思路是遍历旧结构的所有用户把新结构的多个桶拼起来跟旧结构做摘要比对。public class ConsistencyChecker { public void check(String uid) { MapString, String legacy redis.opsForHash().entries(profile: uid); MapString, String split shardedHash.getAll(uid); if (!legacy.keySet().equals(split.keySet())) { log.warn(field set mismatch, uid{}, legacy{}, split{}, uid, legacy.size(), split.size()); return; } for (Map.EntryString, String e : legacy.entrySet()) { String other split.get(e.getKey()); if (!Objects.equals(e.getValue(), other)) { log.warn(value mismatch, uid{}, field{}, uid, e.getKey()); } } } }对账脚本要注意两点。第一不能一次跑全量要用SCAN分批每批 500 个 key跑完 sleep 一下避免把实例压垮。第二比对结果的输出要做聚合不能每条差异都打一行日志——线上跑的时候差异可能是几十万条日志直接把磁盘写满。做法是每个 uid 只记录差异数量和前三条样例。发现差异之后的修复策略我倾向于“以新结构为准重写旧结构”——因为新结构是未来的权威数据源。但如果差异集中在某个时间段那说明双写逻辑有 bug这时候应该先修代码再修复数据。5. 大key的发现手段与长期防护体系5.1 五种发现手段的适用场景对比治理的前提是能发现。我把常用的发现手段列一下各有各的适用范围。手段命令/方式优点局限内置扫描redis-cli --bigkeys开箱即用按类型给出最大 key基于 SCAN 采样可能漏掉只报最大不报全部内存查询MEMORY USAGE key SAMPLES 0精确到单 key 字节数需要先知道 key 名全量扫代价高慢日志SLOWLOG GET直接反映线上真实耗时只能抓到慢的命令抓不到“快但频繁”的大key离线分析解析 RDB 文件全量精确不影响线上需要额外机器有延迟客户端埋点统计命令参数长度能抓写入侧提前拦截需要改代码接入实际生产里我是组合用的。日常巡检跑--bigkeys一周一次出个 Top 50 名单慢日志实时采集超过 50ms 的命令全部上报RDB 离线分析每月一次做精确摸底。三者交叉验证基本不会漏。MEMORY USAGE那个命令要多说一句它默认会采样估算加SAMPLES 0才是全量精确计算但代价是可能阻塞。所以线上千万别对着几百万元素的 key 执行我吃过这个亏——一次MEMORY USAGE卡了 1.2 秒直接触发了主从切换。5.2 写入侧的硬拦截与阈值告警发现是被动的防护要主动。我在编码层加了两道闸。第一道是序列化层的体积检查。所有写 Redis 的操作都走一个统一的RedisWriter组件写入前检查 value 的字节数超过配置的阈值就直接抛异常并打点让问题在测试环境就暴露而不是等到线上。阈值按业务配置缓存类给 16KB会话类给 4KB。public void setEx(String key, String value, long seconds) { int bytes value.getBytes(StandardCharsets.UTF_8).length; if (bytes maxValueBytes) { metrics.counter(redis.write.reject).increment(); throw new IllegalStateException( value too large: bytes bytes, key key); } redis.opsForValue().set(key, value, seconds, TimeUnit.SECONDS); }第二道是元素数量的软告警。集合类写入时无法预知最终大小所以改成写后检查每写入 1000 次采样一次HLEN超过 5000 就发告警超过 50000 就自动触发迁移任务。这个逻辑听起来粗糙但实测非常有效——大部分大key都是慢慢长起来的早期发现处理成本极低。还有一条容易被忽略的给所有集合类 key 强制设置 TTL。我见过太多“临时数据”因为忘了设过期时间跑了两年变成几百万条。在封装层里把 TTL 做成必填参数比任何事后治理都管用。6. 高频追问与踩坑实录6.1 拆分之后的批量操作陷阱最容易踩的坑是MGET和集群的CROSSSLOT报错。把一个大 String 拆成 128 片之后如果直接redisTemplate.opsForValue().multiGet(keys)在集群模式下会直接抛异常因为这 128 个 key 分布在不同的槽上。解决方案有两条。方案 A 是给所有分片 key 加 hash tag比如prod:{12345}:seg:0这样同一个商品的 128 片全部落在同一个槽上MGET可以正常执行也支持 Lua 原子操作。代价是这个商品的所有分片压在同一个节点如果这个商品是爆款节点就成了热点。方案 B 是不加 tag改用 pipeline 逐个 GET。这样分片自然分散到不同节点压力均匀但拿不到原子性而且 pipeline 的往返次数虽然被压缩成 1 次命令处理仍然是 N 次。我的选择标准是这样的单次读取的分片数小于 50走方案 A 加 tag因为延迟更低分片数超过 50 或者是热点数据走方案 B 分散压力。这个取舍没有标准答案必须结合具体数据量判断。6.2 原子性、Lua 与事务的边界拆分之后原本一条HSET能搞定的事可能要写 2 个 key。如果业务要求要么全成功要么全失败就得用 Lua 或者MULTI/EXEC。但这两个机制在集群模式下都要求所有 key 在同一个槽所以又回到了 hash tag 的老问题。有个更隐蔽的坑Lua 脚本里的 key 数量是有上限的虽然官方没明确说死但脚本执行期间会阻塞整个实例脚本里操作几十个 key 会让阻塞时间线性增长。所以我的经验是Lua 只用于 2 到 5 个 key 的小规模原子操作超过这个数就该重新设计数据模型而不是硬用 Lua 兜。还有一个反直觉的结论大部分所谓的“原子性需求”其实是伪需求。用户画像的多个字段之间本来就没有强一致要求晚几百毫秒更新完全可接受。真正需要原子的只有计数、库存这类场景而这类数据本来就不该大。所以在设计拆分方案时先质疑一下“是否真的需要原子”往往能省掉一半复杂度。6.3 拆分过度反而更慢的真实案例这个坑我必须单独讲因为它是我自己踩的。早期做用户标签拆分时我把一个只有 200 个字段的 Hash 也套用了分桶方案拆成了 8 个桶。结果上线后发现接口 P99 反而涨了 15ms——原因很简单原本一次HGETALL能拿到的数据现在要发 8 次 pipeline 请求虽然网络往返被合并了但 Redis 侧的命令解析、槽位路由、结果聚合全都翻了 8 倍。后来复盘定了一条铁律只有当 key 真的超过阈值才拆且拆分收益必须大于拆分成本。200 个字段的 Hash 完全没必要拆5000 个字段以上才进拆分流程。这个阈值后来写进了团队的编码规范避免新人无脑照搬。6.4 常见问题速查表现象可能原因排查手段处置动作接口偶发超时无明显规律大key 的HGETALL阻塞主线程查慢日志看是否有大 value 命令拆分或改为HMGET按需读集群单节点内存异常高大key 导致槽位倾斜--bigkeys扫一遍对比各节点内存拆分打散或加 hash tag 后定向迁移删除 key 时服务卡顿DEL同步释放大量内存观察删除时段的主线程阻塞指标改用UNLINK老版本用分批HDEL主从延迟突然增大大key 写入产生巨大复制包查主从offset差值拆分写入、降低单次写入体积双写后数据对不上路由逻辑或桶号计算不一致跑一致性校验脚本抽样比对修代码后以新结构为准重刷旧数据分片后读延迟反而升高拆分过度往返次数增加统计单次请求的分片数量合并小桶或撤销不必要的拆分RDB 落盘时内存暴涨fork 期间大key 的 COW 复制观察fork前后的内存曲线拆分、开启压缩、调整save策略最后再分享一个我在实际项目中的体会大key治理这件事技术方案只占三成剩下七成靠的是规范约束和早期发现。我见过太多团队把拆分方案写得非常漂亮但因为没有写入侧的硬拦截半年之后新的大key 又长出来了等于白干。所以真正有效的做法是把阈值检查、TTL 强制、巡检告警这三件事固化到基础组件里让业务方想写大key 都写不进去这比事后救火省心一百倍。 Redis大key判定标准与多key拆分方案
凌晨两点被电话叫起来原因是一条 Redis 慢查询告警某条 HGETALL 命令耗时 800ms把接口 P99 从 120ms 顶到了 900ms。登上机器一看那个 Hash 里塞了 260 万个 field整个 value 接近 300MB。这类事故在有一定体量的业务里几乎避不开所以我常拿“Redis 大key的判定标准与多key拆分方案”这个话题去面候选人——不是考背诵而是看这个人有没有真的在生产上救过火。这篇文章就把我在实际项目里踩过的、验证过的、以及面试时听到的好答案烂答案一次性摊开讲清楚。大key这件事说穿了不复杂单个 key 承载的数据量或访问量超出了 Redis 单线程模型能从容处理的范围。但它牵扯出的东西很多——内存分布、网络带宽、持久化、主从复制、集群槽位倾斜每一个都能独立把服务打挂。多key拆分是治理手段里最主流的一种但它不是万能药拆错了反而把简单问题搞复杂。下面这些内容适合三类人写业务代码时习惯hset一把梭的初中级开发、正在准备面试想搞明白原理的求职者以及线上已经出现慢查询需要紧急止血的运维同学。我会从判定标准讲到拆分设计再落到四类数据结构的可直接抄的代码最后把迁移和踩坑都过一遍。1. 大key的判定标准与被放大的三重危害1.1 多大算大三条不同口径的判定线很多人面试时被问“多大算大key”条件反射答“超过 10KB”。这个答案太单薄因为 String 和 Hash 的“大”根本不是一回事。我一般按三个口径分口径类型经验阈值典型触发的问题字节体积Stringvalue 10KB高频访问场景收紧到 1KB网络往返耗时、带宽占用元素数量Hash / List / Set / ZSet元素数 5000或总体积 1MBHGETALL、SMEMBERS、LRANGE 全量读阻塞访问热度任意类型单 key QPS 5000单节点集群槽位热点、单核 CPU 打满这三条线要分开看。一条 100KB 的 String 如果每秒读十万次它比一个 5MB 但一天只读一次的 Hash 危险得多反过来一个 200 万元素的 Set 哪怕 QPS 只有 10一次SMEMBERS也能让整个实例卡住半秒以上因为那 200 万个元素的序列化和网络发送全在 Redis 的单线程里做。字节线也不是拍脑袋定的。Redis 处理命令时value 需要走“读取-序列化-写入 socket 缓冲区”这条链10KB 大概对应一次 0.1ms 量级的处理而 1MB 就是 10ms 量级。业务侧通常要求 Redis 单次操作控制在 1ms 以内所以 10KB 是个比较务实的界。元素数量线的 5000 也是类似逻辑——5000 个短 field 拼起来差不多 100KB 到 300KB再大就该警惕。需要强调一点判定阈值必须跟业务场景绑定不能跨团队照抄。缓存型业务比如商品详情容忍度可以高一些因为读放大有 CDN 和本地缓存顶着而计数型、会话型的场景1KB 都算大。我在某个内容平台项目里定的规则就是“String 8KB 或集合类 2000 元素一律进周巡检名单”跑了一年多误报率很低。1.2 危害拆解一次大key阻塞的完整链路光说“会阻塞”太笼统我把它拆成五条链路每一条都能对上真实现象。第一条是命令执行阻塞。Redis 6.0 之后虽然引入了 IO 多线程处理网络读写但命令执行始终是单线程的。一个HGETALL返回 2MB 数据这 2MB 的遍历、内存拷贝、resp 协议编码全在那一个线程里完成期间所有其他客户端的命令都在排队。2MB 大概 10~20ms如果这个 key 被高频调用就变成持续性的排队雪崩。第二条是网络带宽挤占。假设一个 200 万元素的 Hash 被HGETALL每秒调用 50 次那就是 300MB × 50 15GB/s 的出流量。这个数字已经超出绝大多数实例的网卡上限结果是所有正常的请求都跟着超时。带宽打满的表面现象往往是“偶发超时”“连接池被打穿”跟大key好像没关系排查时特别容易走偏。第三条是删除阻塞这条最容易被忽略。你用DEL删一个 200 万元素的 HashRedis 需要先释放这 200 万个对象的引用、回收内存整个过程同步执行实测能卡住两三秒。正确做法是UNLINK它把内存回收丢到后台线程异步做主线程只做一次 key 摘除。Redis 4.0 才有 UNLINK老版本只能用SCAN 分批HDEL慢慢删。第四条是持久化放大。RDB 落盘时大key会导致fork之后的写时复制COW内存膨胀因为父进程在 fork 期间只要有写入被改动的内存页就要复制一份。一个 300MB 的 Hash 如果整体被改写可能直接多出几百 MB 的额外内存极端情况下触发 OOM。AOF 也是同理大key的一次写入会产生一条巨大的 AOF 记录重写和回放都会被拖慢。第五条是集群槽位倾斜。在集群模式下一个大key整体落在某一个槽上而槽又落到某一个节点上。结果是那个节点的内存和 CPU 使用率远高于其他节点扩容也没用——因为热点还是那一个槽。这种现象在监控图上非常典型所有节点的内存都在 40%就一个节点 85%。1.3 面试时真正被考察的思维链我面人的时候问“你怎么处理大key”最想听到的是一条完整的链怎么发现、怎么判定、怎么止血、怎么根治、怎么做长期防护。只答“拆成多个小key”的候选人我会追问“拆多少片、怎么算的、拆完原子性怎么办”多半就答不上来了。比较理想的回答层次是这样的先说发现手段--bigkeys扫描、MEMORY USAGE、慢日志、RDB 离线分析再说危害阻塞、带宽、持久化、倾斜然后给治理方案拆分、压缩、换存储最后补一句预防写入拦截、阈值告警、编码规范。这条链能完整走下来的人基本上手上是真管过 Redis 的。2. 拆分方案的整体设计先定维度再定粒度2.1 三条拆分主线及其适用边界拆分不是只有“按哈希取模”一条路。我把它归成三条主线选哪条取决于数据结构和读写模式。第一条是业务维度拆分。这是最自然的方式比如按用户 ID 拆、按租户拆、按业务线拆。典型例子是用户会话session:{uid}本身就是按用户分开的天然不构成大key。真正需要业务拆分的场景是“一个大对象里塞了多个业务域的数据”比如商品详情里既有基础属性又有营销信息又有库存快照正确做法是把它们拆成独立 key各自设不同的过期时间。第二条是哈希分桶拆分。适合单个业务对象的内部结构无法再细分的情况比如一个用户的画像标签有 5000 个字段。做法是对 field 名或元素本身做哈希取模落到 N 个桶里每个桶是一个独立的 key。这种方式拆分均匀度高代价是失去整体的原子性和一次性读取能力。第三条是 value 内部切片。主要针对超大 String比如一个 8MB 的 JSON 文档或一张 Base64 编码的图片。做法是按固定字节数切成若干片每片一个 key读取时重新拼装。还有一条补充思路值得单独提冷热分离。一个 5000 字段的对象实际高频访问的可能只有 20 个字段剩下的都是长尾。那就把热字段拎出来单独存一个小 Hash冷字段留在原地或者挪到冷存储。这个方案对读性能提升最明显改造量也最小但前提是你得先摸清楚访问分布——MONITOR采样或者客户端埋点都能拿到。2.2 桶数量的计算两个约束取最大值“拆几个桶”是最容易被敷衍过去的环节。我见过有人随手拆 10 个结果单桶还是 20 万 field等于没拆。正确的算法是同时满足两个约束约束一单桶元素数 ≤ 上限比如 1000约束二单桶字节数 ≤ 上限比如 1MB桶数 N max(ceil(总元素数 / 元素上限), ceil(总体积 / 字节上限))然后向上取到 2 的幂举个具体例子。某项目有个用户标签 Hash200 万个 field平均每个 field 加 value 约 100 字节总体积约 200MB。代入公式按元素数2,000,000 / 1000 2000 个桶按字节数200MB / 1MB 200 个桶取最大值 2000向上取 2 的幂得到 2048拆完平均每桶约 977 个 field、97KB 左右完全在安全范围内。选 2 的幂是为了把取模换成位与运算hash 2047比hash % 2048快一截虽然 Redis 侧其实不差这点但客户端侧调用量大的时候还是有点意义。注意桶数量一旦上线就尽量别再改。因为桶号是靠取模算出来的桶数从 2048 改成 1024所有历史数据的桶号全变等于要做一次全量迁移。所以初期宁可多拆一点留出增长空间。2.3 拆分前必须先回答的四个问题我每次做拆分方案评审都会强制要求把这四个问题写进文档里答不上来就不许动手。问题一读模式是单字段读还是整体读如果业务 90% 是整体读比如渲染整个详情页那拆成多个 key 之后需要 N 次往返或者一次 pipeline端到端延迟不一定下降这时候冷热分离比硬拆更合适。如果主要是单字段读拆分收益极大因为读一个字段只需要访问一个桶。问题二需不需要跨桶原子性如果需要就必须在 key 里加 hash tag比如profile:{12345}:0保证同一个对象的多个桶落在同一个槽上这样才能用 Lua 或者 MULTI 包起来。但加了 hash tag 就意味着所有桶压在同一个节点上失去了分散压力的意义。这是个明确的权衡点必须显式决策。问题三有没有顺序性要求List 拆片时尤其要注意。如果按时间窗口切片feed:{uid}:202506这种LPUSH的顺序天然保持新数据进新片没问题。但如果按成员哈希切片LRANGE出来的顺序就完全乱了。所以 List 一般不按哈希拆只按时间或按序号区间拆。问题四有没有全量遍历需求如果业务存在“遍历所有元素”的操作比如统计、导出、对账拆分之后就要遍历 N 个桶SCAN的复杂度上升。这时候要么维护一个索引 key 记录所有桶号要么接受遍历成本上升。3. 四类数据结构的可直接落地的拆分实践3.1 String 超大 value切片存储与拼装读取某项目的商品详情缓存是一个 8MB 的 JSON。直接GET的耗时接近 100ms而且每次大促前预热时会持续压满带宽。改造方案是按 64KB 切片。切片大小的选择有讲究。太小会导致 key 数量爆炸、pipeline 命令数过多太大则单片仍然偏重。64KB 到 256KB 是比较舒服的区间8MB 切成 64KB 是 128 片。public class ChunkedStringStore { private static final int CHUNK_SIZE 64 * 1024; private static final String PREFIX prod:detail:; private final StringRedisTemplate redis; public ChunkedStringStore(StringRedisTemplate redis) { this.redis redis; } public void put(String id, byte[] payload, Duration ttl) { int total (payload.length CHUNK_SIZE - 1) / CHUNK_SIZE; MapString, String batch new HashMap(total 1); for (int i 0; i total; i) { int from i * CHUNK_SIZE; int to Math.min(from CHUNK_SIZE, payload.length); byte[] slice Arrays.copyOfRange(payload, from, to); batch.put(chunkKey(id, i), Base64.getEncoder().encodeToString(slice)); } batch.put(metaKey(id), String.valueOf(total)); redis.executePipelined((RedisCallbackObject) conn - { batch.forEach((k, v) - { byte[] kb k.getBytes(StandardCharsets.UTF_8); byte[] vb v.getBytes(StandardCharsets.UTF_8); conn.stringCommands().setEx(kb, ttl.getSeconds(), vb); }); return null; }); } public byte[] get(String id) { String totalStr redis.opsForValue().get(metaKey(id)); if (totalStr null) { return null; } int total Integer.parseInt(totalStr); ListString keys new ArrayList(total); for (int i 0; i total; i) { keys.add(chunkKey(id, i)); } ListString slices redis.opsForValue().multiGet(keys); ByteArrayOutputStream out new ByteArrayOutputStream(total * CHUNK_SIZE); for (String s : slices) { if (s null) { return null; } out.writeBytes(Base64.getDecoder().decode(s)); } return out.toByteArray(); } private String chunkKey(String id, int idx) { return PREFIX id :seg: idx; } private String metaKey(String id) { return PREFIX id :meta; } }几个实操细节必须说明。第一切片是按字节切的绝对不能在中途把每一片单独按 UTF-8 解码——一个中文字符占 3 个字节很可能被切成两半解码就出乱码。正确的做法是全程保持byte[]全部拼完再统一 decode。上面这段代码用 Base64 编码后存 String是为了兼容StringRedisTemplate如果直接用RedisTemplateString, byte[]可以省掉编解码开销。第二片数要单独存一个 meta key否则读的时候根本不知道有多少片。meta key 的 TTL 要跟数据片一致但不能反过来——如果 meta 先过期了残留的数据片就变成孤儿 key只能靠定期扫描清理。第三读的时候用multiGet一次发出所有片请求StringRedisTemplate底层会走 pipeline128 次往返压缩成 1 次。如果不走集群模式这是最省事的方案。3.2 Hash 巨型对象二次哈希分桶用户画像、购物车、配置表这类数据基本都用 Hash 存。当 field 数量涨到几十万HGETALL就成了定时炸弹。分桶方案如下public class ShardedHash { private static final int BUCKETS 2048; private static final int MASK BUCKETS - 1; private static final String PREFIX profile:; private final StringRedisTemplate redis; public ShardedHash(StringRedisTemplate redis) { this.redis redis; } private int bucketOf(String field) { int h field.hashCode(); h ^ (h 16); return h MASK; } private String bucketKey(String uid, int bucket) { return PREFIX uid : bucket; } public void put(String uid, String field, String value) { redis.opsForHash().put(bucketKey(uid, bucketOf(field)), field, value); } public String get(String uid, String field) { Object v redis.opsForHash().get(bucketKey(uid, bucketOf(field)), field); return v null ? null : v.toString(); } public MapString, String getAll(String uid) { ListString keys new ArrayList(BUCKETS); for (int i 0; i BUCKETS; i) { keys.add(bucketKey(uid, i)); } ListObject results redis.executePipelined((RedisCallbackObject) conn - { for (String k : keys) { conn.hashCommands().hGetAll(k.getBytes(StandardCharsets.UTF_8)); } return null; }); MapString, String merged new HashMap(); for (Object r : results) { if (r instanceof Map) { ((Map?, ?) r).forEach((k, v) - merged.put(String.valueOf(k), String.valueOf(v))); } } return merged; } }这里最关键的实现点是哈希函数的选择。String.hashCode()对短字符串分布还行但对形如tag_0001、tag_0002这种有规律的 field 名低位容易聚集。所以我在上面做了h ^ (h 16)的高低位混淆跟 HashMap 里那套扰动函数是一个思路。如果 field 名规律性特别强建议直接上 CRC32 或者 MurmurHash分布更均匀。第二个点是空桶的处理。2048 个桶里如果这个用户只有 30 个字段那 2018 个桶都是不存在的空 key。HGETALL一个不存在的 key 返回空 Map代价很小但 2048 次 pipeline 调用仍然是实打实的开销。所以实际项目里我一般会做一个自适应桶数不是固定的 2048而是根据对象的实际字段数量动态算。字段少于 1000 的直接单 key 存超过才分桶桶数按 2.2 节的公式算出来存到 meta 里。第三个点是HGETALL的替代。很多业务其实只需要读部分字段那就用HMGET但HMGET要求所有 field 在同一个 key 里。分桶之后只能按桶分组每个桶发一次HMGET然后 pipeline 打包。写起来啰嗦但比全量读便宜得多。3.3 List / ZSet / Set按时间片和成员哈希切片这三类结构各有各的拆法不能混用一套模板。List 最合适按时间切片。消息流、操作日志、评论列表这类数据天然有时间维度key 设计成feed:{uid}:{yyyyMM}每个月一个 ListLPUSH新数据进当前月读的时候按需拼最近几个月。这样单 key 的元素数天然被时间窗口限制住了而且历史数据可以按需设置更长的 TTL 甚至归档。要注意的是跨片的范围查询想读最近 100 条可能需要读 2 到 3 个片然后合并好在LRANGE支持负数索引实现起来不复杂。ZSet 按周期切分最自然。排行榜类需求日榜rank:{yyyyMMdd}、周榜rank:{yyyyWW}、月榜rank:{yyyyMM}各存各的互不干扰。缺点是跨周期的聚合排序需要应用层归并。如果业务确实需要“全站总榜”那就得用定时任务把周期榜的结果汇总到一个总榜里而不是让客户端去实时归并。Set 只能按成员哈希拆。标签集合、好友关系这类数据没有天然的时间序只能对成员本身做哈希。tags:{id}:{bucket}判断是否包含某成员时先算出桶号再SISMEMBER。这里有个必须接受的代价SINTER、SUNION、SDIFF这些集合运算彻底没法用了因为参与运算的两个集合分片规则不同。如果业务强依赖集合运算那就老老实实别拆改用别的方案比如用 BitMap 或者换到支持集合运算的存储。3.4 实在拆不动的场景压缩、换存储与协议优化不是所有大key都能拆。有三种情况我建议放弃拆分换思路。第一种是强事务场景。比如库存扣减、账户余额它们的正确性依赖单 key 的原子操作。拆了之后跨 key 的原子性只能靠 Lua 或者分布式锁复杂度暴涨出问题的概率远高于收益。这类 key 本来就该小——余额只有一个数字怎么会大如果大了说明设计有问题该拆的是业务模型不是存储结构。第二种是超大二进制对象。视频、图片、安装包这类东西根本不该进 Redis。正确的做法是存到对象存储Redis 里只放一个指针URL 或 ID。我见过有人把 PDF 文件 Base64 之后塞进 Redis一个 key 十几 MB这种属于用错了工具。第三种是必须整体读的复杂聚合。如果一个 5MB 的 JSON 每次都要整体反序列化成对象那切片和拼装只是把一次大传输变成多次小传输总字节数没变CPU 侧的序列化开销反而更高。这时候更该做的是压缩——开启 value 压缩比如用 Snappy、LZ4 在应用层压一遍再存通常能压到原来的 20% 到 30%比拆分省事得多。或者考虑把这份数据从缓存层挪到搜索层、文档层。4. 迁移落地双写、灰度与一致性校验三板斧4.1 双写期的读写路由设计拆分方案想得再漂亮上线才是真正的考验。历史数据不能停机迁移所以必须要有一段双写期。路由逻辑我用一个统一的组件收口public class SplitRouter { private final StringRedisTemplate redis; private final SplitSwitch splitSwitch; public void write(String uid, String field, String value) { if (splitSwitch.isDualWrite(uid)) { redis.opsForHash().put(legacyKey(uid), field, value); } if (splitSwitch.isSplitRead(uid)) { shardedHash.put(uid, field, value); } } public String read(String uid, String field) { if (splitSwitch.isSplitRead(uid)) { String v shardedHash.get(uid, field); if (v ! null) { return v; } return legacyRead(uid, field); } return legacyRead(uid, field); } }设计要点有三个。第一写路径以新结构为准旧结构只做兼容即新结构写成功、旧结构写失败可以容忍反过来不行。第二读路径先读新结构miss 才回源旧结构这样迁移过程中不会出现读到空数据的情况。第三旧 key 的 TTL 不能直接删掉要持续续期否则双写期间一部分用户的数据会因为旧 key 过期而重新走回源逻辑读放大严重。双写期的长度取决于数据规模和访问频率。一般我建议至少覆盖一个完整的访问周期比如一周确保所有活跃用户的数据都被自然迁移过一遍。对于长期不活跃的用户可以在双写结束时跑一次全量迁移脚本兜底。4.2 灰度切流与回滚预案灰度必须按用户 ID 取模来切不能按流量随机切。原因是同一个用户的数据必须始终走同一套逻辑否则会出现“这次读新结构、下次读旧结构”的抖动数据对不上。灰度节奏我一般这么排5% 跑一天观察错误率和延迟没问题放到 20% 跑一天然后 50%、100%。每一档都要盯三个指标新结构的HGET延迟分布、旧结构的读命中率应该逐步下降、以及双写的失败计数。回滚预案必须在上线前就准备好而不是出事再想。具体就是配置中心里放一个开关把isSplitRead全部置为 false读流量瞬间全部回落到旧结构。这时候新结构还留着不影响数据等排查清楚再重新灰度。这个开关必须做到秒级生效不能依赖重启。注意回滚开关只管读不管写。双写逻辑一旦开启就不建议关掉因为关掉之后新结构就停止更新再想恢复又得重新补数据。所以开关要设计成“读写分离的两个开关”而不是一个总开关。4.3 一致性校验的脚本实现思路双写期间最怕的是“以为写进去了其实没有”。所以要跑对账。校验的核心思路是遍历旧结构的所有用户把新结构的多个桶拼起来跟旧结构做摘要比对。public class ConsistencyChecker { public void check(String uid) { MapString, String legacy redis.opsForHash().entries(profile: uid); MapString, String split shardedHash.getAll(uid); if (!legacy.keySet().equals(split.keySet())) { log.warn(field set mismatch, uid{}, legacy{}, split{}, uid, legacy.size(), split.size()); return; } for (Map.EntryString, String e : legacy.entrySet()) { String other split.get(e.getKey()); if (!Objects.equals(e.getValue(), other)) { log.warn(value mismatch, uid{}, field{}, uid, e.getKey()); } } } }对账脚本要注意两点。第一不能一次跑全量要用SCAN分批每批 500 个 key跑完 sleep 一下避免把实例压垮。第二比对结果的输出要做聚合不能每条差异都打一行日志——线上跑的时候差异可能是几十万条日志直接把磁盘写满。做法是每个 uid 只记录差异数量和前三条样例。发现差异之后的修复策略我倾向于“以新结构为准重写旧结构”——因为新结构是未来的权威数据源。但如果差异集中在某个时间段那说明双写逻辑有 bug这时候应该先修代码再修复数据。5. 大key的发现手段与长期防护体系5.1 五种发现手段的适用场景对比治理的前提是能发现。我把常用的发现手段列一下各有各的适用范围。手段命令/方式优点局限内置扫描redis-cli --bigkeys开箱即用按类型给出最大 key基于 SCAN 采样可能漏掉只报最大不报全部内存查询MEMORY USAGE key SAMPLES 0精确到单 key 字节数需要先知道 key 名全量扫代价高慢日志SLOWLOG GET直接反映线上真实耗时只能抓到慢的命令抓不到“快但频繁”的大key离线分析解析 RDB 文件全量精确不影响线上需要额外机器有延迟客户端埋点统计命令参数长度能抓写入侧提前拦截需要改代码接入实际生产里我是组合用的。日常巡检跑--bigkeys一周一次出个 Top 50 名单慢日志实时采集超过 50ms 的命令全部上报RDB 离线分析每月一次做精确摸底。三者交叉验证基本不会漏。MEMORY USAGE那个命令要多说一句它默认会采样估算加SAMPLES 0才是全量精确计算但代价是可能阻塞。所以线上千万别对着几百万元素的 key 执行我吃过这个亏——一次MEMORY USAGE卡了 1.2 秒直接触发了主从切换。5.2 写入侧的硬拦截与阈值告警发现是被动的防护要主动。我在编码层加了两道闸。第一道是序列化层的体积检查。所有写 Redis 的操作都走一个统一的RedisWriter组件写入前检查 value 的字节数超过配置的阈值就直接抛异常并打点让问题在测试环境就暴露而不是等到线上。阈值按业务配置缓存类给 16KB会话类给 4KB。public void setEx(String key, String value, long seconds) { int bytes value.getBytes(StandardCharsets.UTF_8).length; if (bytes maxValueBytes) { metrics.counter(redis.write.reject).increment(); throw new IllegalStateException( value too large: bytes bytes, key key); } redis.opsForValue().set(key, value, seconds, TimeUnit.SECONDS); }第二道是元素数量的软告警。集合类写入时无法预知最终大小所以改成写后检查每写入 1000 次采样一次HLEN超过 5000 就发告警超过 50000 就自动触发迁移任务。这个逻辑听起来粗糙但实测非常有效——大部分大key都是慢慢长起来的早期发现处理成本极低。还有一条容易被忽略的给所有集合类 key 强制设置 TTL。我见过太多“临时数据”因为忘了设过期时间跑了两年变成几百万条。在封装层里把 TTL 做成必填参数比任何事后治理都管用。6. 高频追问与踩坑实录6.1 拆分之后的批量操作陷阱最容易踩的坑是MGET和集群的CROSSSLOT报错。把一个大 String 拆成 128 片之后如果直接redisTemplate.opsForValue().multiGet(keys)在集群模式下会直接抛异常因为这 128 个 key 分布在不同的槽上。解决方案有两条。方案 A 是给所有分片 key 加 hash tag比如prod:{12345}:seg:0这样同一个商品的 128 片全部落在同一个槽上MGET可以正常执行也支持 Lua 原子操作。代价是这个商品的所有分片压在同一个节点如果这个商品是爆款节点就成了热点。方案 B 是不加 tag改用 pipeline 逐个 GET。这样分片自然分散到不同节点压力均匀但拿不到原子性而且 pipeline 的往返次数虽然被压缩成 1 次命令处理仍然是 N 次。我的选择标准是这样的单次读取的分片数小于 50走方案 A 加 tag因为延迟更低分片数超过 50 或者是热点数据走方案 B 分散压力。这个取舍没有标准答案必须结合具体数据量判断。6.2 原子性、Lua 与事务的边界拆分之后原本一条HSET能搞定的事可能要写 2 个 key。如果业务要求要么全成功要么全失败就得用 Lua 或者MULTI/EXEC。但这两个机制在集群模式下都要求所有 key 在同一个槽所以又回到了 hash tag 的老问题。有个更隐蔽的坑Lua 脚本里的 key 数量是有上限的虽然官方没明确说死但脚本执行期间会阻塞整个实例脚本里操作几十个 key 会让阻塞时间线性增长。所以我的经验是Lua 只用于 2 到 5 个 key 的小规模原子操作超过这个数就该重新设计数据模型而不是硬用 Lua 兜。还有一个反直觉的结论大部分所谓的“原子性需求”其实是伪需求。用户画像的多个字段之间本来就没有强一致要求晚几百毫秒更新完全可接受。真正需要原子的只有计数、库存这类场景而这类数据本来就不该大。所以在设计拆分方案时先质疑一下“是否真的需要原子”往往能省掉一半复杂度。6.3 拆分过度反而更慢的真实案例这个坑我必须单独讲因为它是我自己踩的。早期做用户标签拆分时我把一个只有 200 个字段的 Hash 也套用了分桶方案拆成了 8 个桶。结果上线后发现接口 P99 反而涨了 15ms——原因很简单原本一次HGETALL能拿到的数据现在要发 8 次 pipeline 请求虽然网络往返被合并了但 Redis 侧的命令解析、槽位路由、结果聚合全都翻了 8 倍。后来复盘定了一条铁律只有当 key 真的超过阈值才拆且拆分收益必须大于拆分成本。200 个字段的 Hash 完全没必要拆5000 个字段以上才进拆分流程。这个阈值后来写进了团队的编码规范避免新人无脑照搬。6.4 常见问题速查表现象可能原因排查手段处置动作接口偶发超时无明显规律大key 的HGETALL阻塞主线程查慢日志看是否有大 value 命令拆分或改为HMGET按需读集群单节点内存异常高大key 导致槽位倾斜--bigkeys扫一遍对比各节点内存拆分打散或加 hash tag 后定向迁移删除 key 时服务卡顿DEL同步释放大量内存观察删除时段的主线程阻塞指标改用UNLINK老版本用分批HDEL主从延迟突然增大大key 写入产生巨大复制包查主从offset差值拆分写入、降低单次写入体积双写后数据对不上路由逻辑或桶号计算不一致跑一致性校验脚本抽样比对修代码后以新结构为准重刷旧数据分片后读延迟反而升高拆分过度往返次数增加统计单次请求的分片数量合并小桶或撤销不必要的拆分RDB 落盘时内存暴涨fork 期间大key 的 COW 复制观察fork前后的内存曲线拆分、开启压缩、调整save策略最后再分享一个我在实际项目中的体会大key治理这件事技术方案只占三成剩下七成靠的是规范约束和早期发现。我见过太多团队把拆分方案写得非常漂亮但因为没有写入侧的硬拦截半年之后新的大key 又长出来了等于白干。所以真正有效的做法是把阈值检查、TTL 强制、巡检告警这三件事固化到基础组件里让业务方想写大key 都写不进去这比事后救火省心一百倍。