redis sds扩容采用预分配策略：小于1mb时新空间=2×(len+addlen)，≥1mb时=新长度+1mb+1；7.0后用alloc-len算空闲，但预分配逻辑不变，导致alloc与实际len严重脱钩。
SDS扩容时预分配空间远超当前所需
Redis的sdsMakeRoomFor函数在扩容时不是“按需分配”，而是主动多分——这是内存消耗增加的直接原因。比如原字符串长度为 800KB，追加 100KB 数据，新长度是 900KB，但 Redis 判定其 小于 SDS_MAX_PREALLOC（1MB），于是按规则分配 2 × 900KB = 1.8MB，实际只用了 900KB，空闲近 1MB。
这种策略本意是减少后续多次追加带来的 realloc 开销，但代价是：一次写入就占两倍内存；若后续不再追加，这部分空间长期闲置。
- 小于 1MB 的字符串：新分配空间 =
2 × (len + addlen)（含结尾'\0'） - 大于等于 1MB 的字符串：新分配空间 =
(len + addlen) + 1MB + 1 - Redis 7.0 后取消了
free字段，改用alloc - len计算空闲量，但预分配逻辑未变
embstr 编码转 raw 后失去内存紧凑性
当一个短字符串（≤44 字节）以 embstr 编码存储时，redisObject 和 SDS 头部、buf 是一次性连续分配的，总开销小、缓存友好。但只要对它做任意修改（如 APPEND 或 SET 覆盖），Redis 就会强制将其转换为 raw 编码。
raw 编码下，redisObject 和 SDS 分开分配，且 SDS 自身又按预分配规则扩容——原本 50 字节的字符串，可能瞬间变成两个独立内存块：一个 16 字节 redisObject + 一个 2MB 的 SDS buf（因扩容触发 2 倍策略）。
-
embstr是只读的，任何写操作都会触发sdstocap→sdsMakeRoomFor→ 内存重分配 - 转换后无法自动缩回
embstr，即使你再删掉内容，alloc仍维持高位 - 使用
MEMORY USAGE key可验证：同一语义内容，raw比embstr多出 30%~200% 内存占用
大 key 场景下 alloc 与实际数据严重脱钩
SDS 的 alloc 字段记录的是已分配总空间，len 才是真实长度。两者差值就是“幽灵内存”——不存数据，但被 Redis 占着不放。尤其在反复增删的场景中，len 可能从 10MB 降到 100KB，但 alloc 仍卡在 20MB 不动（惰性释放机制决定它不会自动缩容）。
更麻烦的是，这个“幽灵内存”会被计入 INFO memory 的 used_memory，影响淘汰策略、触发 maxmemory 驱逐，甚至让监控误判为内存泄漏。
- 缩容靠
sdsRemoveFreeSpace，但 Redis 不自动调用，仅在 RDB/AOF 持久化或OBJECT ENCODING检查时被动触发 -
DEBUG SLEEP或CLIENT PAUSE期间手动执行MEMORY PURGE（Redis 7.0+）可强制回收，但生产环境慎用 - 对长期存在的大 key，建议用
RESTORE+DUMP组合重建，强制归零alloc
proto-max-bulk-len 限制掩盖了底层分配失控风险
很多人以为 “512MB 是硬上限”，其实这只是 RESP 协议层的解析安全阈值（proto-max-bulk-len 默认 536870912）。SDS 本身支持 64 位长度，理论上能到 16EB。真正卡住你的，往往是扩容策略在接近上限时的指数级放大效应。
例如一个 510MB 的字符串，再 APPEND 1MB，新长度 511MB，仍 ？不，它已远超 1MB，触发“+1MB”策略：分配 <code>511MB + 1MB + 1 ≈ 512MB —— 看似合理。但若此时已有 10MB 空闲（alloc - len = 10MB），Redis 仍会重新 malloc 一块 512MB 新内存，复制全部数据，再释放旧块。单次操作引发 1GB 内存抖动。
- 该行为在 AOF rewrite 或 RDB fork 时会被放大，极易触发系统 OOM Killer
-
CONFIG SET proto-max-bulk-len调大只会让问题延后，不能解决预分配失当本质 - 线上应通过
redis-cli --bigkeys或MEMORY USAGE定期扫描alloc / len > 2的 key
最易被忽略的一点：SDS 的预分配和惰性释放是正交策略——前者拼命多分，后者死活不收。它们共同作用的结果，不是“省了 realloc 次数”，而是在内存里悄悄堆起一座座只有 len 标高的空楼。
