redis set内存暴涨的根本原因是底层从intset升级为hashtable导致开销激增；千万级数据下，hashtable版set内存可达1.2gb+，而intset仅约120mb。
Redis Set内存暴涨的根本原因
Set在千万级数据下内存飙升，不是因为“它不行”，而是底层编码切换导致的隐性开销。当sadd进来的用户ID超过set-max-intset-entries（默认512）且为大整数（比如10位以上用户ID），Redis会从紧凑的intset自动升级为hashtable。这时每个元素不再只占8字节，而是要额外存储哈希桶指针、节点结构、字符串对象头——实测1000万用户ID，hashtable版Set可能吃掉1.2GB+内存，而intset可能只要120MB。
用BitMap替代Set的前提与限制
如果点赞/关注关系能映射到连续或可预估范围的整型ID（例如用户ID是自增主键、且最大值已知），bitfield或setbit就是更优解。它把“用户A是否点赞内容B”压缩成1个bit，1000万条记录仅需约1.2MB内存。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须确保用户ID是正整数，且最大值可控（如≤2^32−1）；字符串UID（如UUID）无法直接使用
-
getbit查单个状态极快，但bitcount统计总数时若范围过大（如全量扫描），会阻塞主线程，建议配合BITCOUNT分段或用HyperLogLog做近似去重计数 - 不能直接获取所有已点赞的用户ID列表——BitMap本身不存ID，只存“存在性”，需要额外索引表或离线导出
实在要用Set，怎么扛住千万级写入
硬要保留Set语义（比如必须支持smembers、sunion等集合运算），就得主动规避hashtable陷阱，并控制单key膨胀：
- 优先保证插入的member全是小整数：比如将全局用户ID通过
id % 10000映射到0–9999范围内，再用intset存；但要注意冲突和去重逻辑需上层兜底 - 强制分片：按内容ID哈希，把一个热门帖子的点赞拆成
like:post:123:a、like:post:123:b等多个Set，每个控制在50万以内，避免单key过大 - 禁用
SMEMBERS全量拉取：改用SSCAN游标分页读取，防止一次请求拖垮Redis内存和网络带宽 - 写入时用
pipeline批量提交，但注意单次pipeline不要超过5000条，否则可能触发Redis命令队列积压或超时
别忽略连接与客户端层面的放大效应
很多“Set变慢”问题其实出在客户端——Python的redis-py默认不启用连接池，每调用一次sadd都新建TCP连接；Java的Jedis若没配maxTotal，高并发下会创建海量连接打满服务端fd。真实瓶颈常在这里，而不是Set本身。
- Python务必用
ConnectionPool，并设max_connections=200以上 - Java项目检查JedisPool配置，
minIdle和maxIdle至少设为50，避免频繁创建销毁连接 - 线上禁止用
redis-cli执行SMEMBERS或KEYS *，这类命令在千万级数据下极易引发Redis阻塞
