bitcount统计在线设备数快因o(1)时间复杂度，但仅返回1的个数而无法定位具体设备，故适用于监控大盘而非业务逻辑；需配合bitpos、bitop或映射表等方案满足运营需求。
BITCOUNT 统计在线设备数为什么快，但不能直接用
因为 BITCOUNT 确实能在 O(1) 时间内返回整个位图中值为 1 的 bit 数量，看起来是统计“当前在线设备总数”的完美解法。但问题在于：它只告诉你“有多少个 1”，不告诉你“哪些 offset 是 1”。你没法知道具体是哪台设备在线，更没法做分页、导出、按区域筛选这类运营需求。
实际生产中，BITCOUNT 更适合做秒级大盘监控（比如看后台 Dashboard 上那个“在线数：2,489,103”），而不是业务逻辑主路径。一旦需要关联设备元数据（如 IP、型号、归属分组），就必须配合其他结构查表，或者改用 BITPOS 扫描 + 分批拉取。
- 单 key 存一亿设备，
BITCOUNT耗时稳定在微秒级，但BITPOS key 1扫第一个在线设备可能要几毫秒——偏移量越靠后越慢 - Redis 7.0+ 支持
BITPOS key 1 COUNT 100，可一次找前 100 个在线位，比循环调用高效得多 - 别对大 offset 位图频繁扫
BITPOS，容易阻塞主线程；建议拆 key 或加缓存层
SETBIT 心跳写入必须带 EXPIRE，否则会累积脏数据
很多人把设备 ID 当作 offset，每天用 SETBIT online:20261019 123456 1 更新状态，却忘了过期。结果第二天这个 key 还在，里面全是昨天的“1”，导致 BITCOUNT 统计严重虚高。
正确做法是：每次心跳都重置 key 生存时间。不是靠客户端定时删，而是服务端在写入时强制刷新 TTL：
SETBIT online:20261019 123456 1 EXPIRE online:20261019 86400
注意这两条命令必须原子执行——用 Lua 脚本封装，否则存在竞态（比如 SETBIT 成功但 EXPIRE 失败）：
EVAL "redis.call('SETBIT', KEYS[1], ARGV[1], 1); redis.call('EXPIRE', KEYS[1], ARGV[2]); return 1" 1 online:20261019 123456 86400
- 不要用
SETEX，因为它只支持字符串整体设置，不支持位操作 - 避免用
SETBIT+PEXPIRE分开调用，网络延迟或失败会导致 key 永久不过期 - 如果心跳频率高（如每 10 秒一次），TTL 建议设为心跳间隔的 3 倍（即 30 秒），兼顾容错与及时下线
多天状态聚合必须用 BITOP，但要注意 key 对齐和内存峰值
要算“过去 7 天都在线的设备”，本质是 7 个位图做 AND 运算：BITOP AND result:7day online:20261013 online:20261014 ... online:20261019。这很高效，但有两个硬约束：
- 所有参与
BITOP的 key 必须有相同长度（即最大 offset 一致），否则短的会被自动补零——这可能导致误判：某设备第 5 天没心跳，对应位是 0，但第 6 天 key 长度不够，被补成 0，AND 后还是 0，结果“没在线”被当成“不存在” -
BITOP是同步阻塞操作，7 个 1GB 的位图做 AND，Redis 主线程会卡住几百毫秒，集群环境下还可能触发 slowlog 报警 - 推荐预生成固定长度位图：比如统一按 1 亿设备容量初始化，用
SETBIT key 99999999 0触发分配，后续所有天都复用该长度
更稳妥的做法是把聚合下沉到离线任务：每天凌晨用 Spark 读 Redis 位图 dump，做位运算后写回一个汇总 key，线上只查这个结果。
设备 ID 映射 offset 容易溢出或碰撞，必须做压缩
直接把原始设备 ID（如 UUID 字符串或 64 位整数）当 offset 用，风险极大。Redis offset 是 uint64，最大支持 2^64−1 ≈ 1.8×10¹⁹，看似够用，但实际会遇到两类问题：
- UUID 转数字可能超范围，比如
uuid.uuid4().int在 Python 中是 128 位，直接强转会截断或报错 - 不同设备 ID 映射到同一 offset（哈希冲突），比如用简单取模
id % 100000000，千万级设备下冲突概率不可忽略 - 稀疏 ID（如数据库自增主键跳着增长）会导致位图内部大量空洞，内存浪费严重——Redis 按最大 offset 分配字节，中间全补零
推荐方案：用布隆过滤器 + 单调递增映射表（如 MySQL 自增 ID）做两级压缩。上线时先查映射表，不存在则插入并获取新 offset；查询时反查表还原设备 ID。这样 offset 紧凑、可控、无冲突。
复杂点在于映射表本身成了单点瓶颈，所以得加本地缓存（Caffeine）+ 异步批量写入，同时容忍短暂映射延迟——毕竟心跳检测本就是“推断”，不是强实时。
