Redis作为高频访问的缓存组件，其内存资源往往十分昂贵。很多团队在业务早期随意设计key结构，导致同样的数据量在Redis中占用的内存远超理论值。要从根本上提升缓存空间利用率，需要从数据结构选型、编码优化、压缩手段以及淘汰策略几个维度系统梳理。
一、数据结构选型对空间的影响
最常见的空间浪费来自使用字符串类型缓存复杂对象。例如把一个用户对象序列化成JSON字符串后以user:1001为key存入，这种做法每个字段名都会重复存储，并且Redis自身对每个字符串key都有独立的元数据开销。当对象字段较多且用户量巨大时，冗余十分惊人。
更优的方案是利用Hash结构将同一对象的字段聚合。Redis的Hash在元素较少时会采用listpack（旧版为ziplist）编码，以紧凑的连续块存储字段与值，省去了大量独立key的指针与字典开销。以下示例展示了两种存储方式：
# 不推荐：多个字符串key SET user:1001:name "张三" SET user:1001:age 28 SET user:1001:city "北京" # 推荐：单个Hash HSET user:1001 name "张三" age 28 city "北京"
在实测中，十万用户对象用字符串平铺会占用约七十余MB，而改用Hash且控制单key字段数在百以内，内存可降至四十MB左右。但需注意Hash的key不能无限膨胀，否则会触发编码升级为哈希表，反而增加内存与查询耗时。
二、编码优化与内存碎片控制
Redis针对不同数据类型提供了多种底层编码。以Hash和ZSet为例，元素少且值小时使用listpack，超过阈值后转为标准哈希表或跳表。listpack使用一块连续内存存放数据，没有额外指针，空间利用率极高。我们可以通过配置hash-max-listpack-entries与hash-max-listpack-value来放宽紧凑编码的条件。
内存碎片也是隐形杀手。频繁更新、删除不同大小的对象会让内存分配器产生无法利用的空隙。使用jemalloc虽能缓解，但长期运行仍建议开启activedefrag主动碎片整理。同时，尽量让缓存对象大小均匀，避免大对象与小对象混杂。如下配置可提升紧凑编码上限：
# redis.conf 片段 hash-max-listpack-entries 512 hash-max-listpack-value 256 zset-max-listpack-entries 256 zset-max-listpack-value 128 activedefrag yes
除了编码，过期键的清理机制也影响空间。若大量key同时过期，可能造成内存骤降但碎片残留。采用随机过期时间打散，并结合maxmemory-policy allkeys-lru能在内存触顶时自动回收最久未用数据，保持利用率平稳。
三、压缩与序列化策略
当缓存内容为长文本或复杂嵌套结构时，直接序列化存入非常占空间。引入轻量压缩算法能在客户端先压缩再写入。Snappy与LZ4具备极快的压缩解压速度，对JSON、HTML片段等文本压缩率可达百分之四十到六十，对Redis吞吐影响极小。
下面以Python为例，展示用LZ4压缩用户列表后再存Redis，读取时解压：
import lz4.frame
import redis
import json
r = redis.Redis(host='127.0.0.1', port=6379, db=0)
def cache_users(key, users):
raw = json.dumps(users).encode('utf-8')
compressed = lz4.frame.compress(raw)
r.set(key, compressed)
def get_users(key):
data = r.get(key)
if not data:
return None
raw = lz4.frame.decompress(data)
return json.loads(raw.decode('utf-8'))
该方式将网络传输与内存占用同步降低。但应注意压缩对小对象收益有限，且会增加CPU开销，因此建议仅对超过一千字节的value启用。配合前面提到的Hash聚合与紧凑编码，整体缓存空间利用率往往能提升一倍以上，同时保障访问延迟在可接受范围。