SETBIT偏移量过大导致内存暴涨，因其按字节对齐整块分配，如设第100万bit即分配125KB并填充零字节；Bitmap底层为字符串，不支持稀疏结构，且分段需业务层路由与兜底处理。
偏移量过大直接导致内存暴涨，不是因为Redis卡顿或配置不对，而是SETBIT按字节对齐整块分配——设第100万bit，它就给你分配125KB并填满零字节。
为什么SETBIT一设大offset就吃光内存
Redis的Bitmap底层是字符串（raw/embstr），不支持稀疏结构。你调用SETBIT user:active 1000000 1，它会计算所需字节数：1000000 ÷ 8 + 1 = 125001字节，并一次性malloc出来，中间全为0。哪怕你只设了3个bit，只要最大offset是100万，这125KB就占着不动。
- 稀疏度＞99.5%时，有效bit占比极低，但
BITCOUNT、BITPOS仍要遍历整块内存，CPU缓存失效 - RDB/AOF把所有零字节照常落盘，备份体积虚高
- 集群中单key过大还会触发slot倾斜，影响迁移和扩缩容
分段位图怎么分：选段长、算key、设offset
核心是把“一个超大Bitmap”拆成“多个可控大小的Bitmap”，每段独立key，业务层负责路由。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 段长建议选
10000～65536：太小（如100）会导致key数爆炸，SCAN和KEYS压力大；太大（如50万）起不到压缩效果 - 路由公式固定：
seg_id = Math.floor(offset / SEG_LEN)，local_offset = offset % SEG_LEN - key命名示例：
user:active:seg:12（对应全局offset 120000～129999），local_offset范围始终在[0, SEG_LEN) - 务必用
Math.floor而非parseInt或~~，避免负数offset出错
分段后必须手动处理的三个坑
Redis不感知分段逻辑，所有“理所当然”的行为都要自己兜底。
-
GETRANGE跨段读取时，某段key可能根本不存在（返回nil），而BITCOUNT遇到nil直接报错，得先EXISTS判空再聚合 -
EXPIRE必须对每个子key单独执行，漏设一个就会造成“逻辑已过期但物理数据残留”，后续统计失真 -
SCAN清理旧段时，MATCH "user:active:seg:*"要加冒号转义（如果业务key含冒号），且游标需完整遍历，不能靠COUNT估算
别指望BITOP跨段运算，应用层聚合才是现实路径
BITOP AND user:active:7d user:active:seg:0 user:active:seg:1 ...这种写法无效——BITOP只支持同key内多值或同类型key，不识别分段语义。
- 需要交集/并集时，必须在应用层逐段
GET二进制串，用语言内置位运算（如Python的&、|）合并，再SET回新key - 连续签到统计这类场景，优先用
BITFIELD批量读写+本地循环判断，比拉取整段再处理更省带宽 - 如果业务允许近似结果，可考虑改用
RedisBloom的CF.ADD，但注意它无法精确读写任意bit位
分段本质是把内存压力换成了key数量压力和路由复杂度。真正该反思的是：用Bitmap存“过去三年每天是否登录”这种极度稀疏的状态，本身就是误用——时间序列或活跃日集合（SET）更合适。
