用户ID转位偏移量需统一减1，即offset = user_id - 1；负数、字符串或过大ID（>2³²）不合法，分库分表/UUID/Snowflake等非连续ID须先映射为连续整数。
Bitmap 里用户 ID 怎么转成位偏移量
直接用 user_id 当偏移量最简单，但有风险：如果 user_id 是数据库自增主键，从 1 开始，那第 1 个用户就该写到 offset 0，所以得统一减 1 —— 即 offset = user_id - 1。别跳过这步，否则所有位都错一位。
常见错误是直接把 user_id 当 offset 用，结果 SETBIT online_users 1001 1 把第 1002 位设为 1（因为 offset 从 0 算），而你本意是标记 ID=1001 的用户在线。
- 必须保证
user_id是正整数，负数或字符串会报ERR value is not an integer or out of range - 如果用户 ID 来自分库分表、UUID 或 Snowflake，不能直接当 offset —— 得先映射到连续整数（比如用 Redis Hash 做 ID→seq 映射，再查 seq）
- 大 ID（比如 > 2^32）在某些旧版 Redis（
SETBIT 和 GETBIT 怎么配合判断在线状态
SETBIT 写状态，GETBIT 读状态，二者 offset 必须完全一致。关键不是“怎么调用”，而是“什么时候写、什么时候读”——在线状态得靠客户端主动上报，Redis 本身不自动感知连接存续。
- 用户登录成功后立刻执行
SETBIT online_users1 - 用户登出或 WebSocket 断连时执行
SETBIT online_users0 - 判断是否在线：用
GETBIT online_users，返回1表示在线，0表示离线，nil（即空响应）也等价于0 - 别用
EXISTS判断 key 是否存在来代替GETBIT—— Bitmap key 可能存在但某位是 0，结果误判为“在线”
Bitmap 内存占用和实际用户量的关系
Bitmap 内存不是按用户数算的，是按最大 offset 算的。比如你只标记了用户 ID=1 和 ID=1000000，在线用户仅 2 人，但 Redis 仍要分配约 1000000/8 ≈ 125KB 连续空间。
- 如果用户 ID 稀疏（如 ID 跳变大、删过大量用户），Bitmap 浪费严重，考虑改用
SET或带 TTL 的STRING（每个用户一个 key） - 可用
BITCOUNT online_users统计当前在线总数，但注意它扫描整个底层字节数组 —— offset 越大越慢，1000 万 offset 下耗时可能达毫秒级 - 用
BITPOS online_users 1找第一个在线用户 offset，适合做“找活跃用户”类场景，但别依赖它做分页 —— 没有游标，重复调用结果不稳定
如何避免多实例部署时的位偏移冲突
单 Redis 实例没问题，但微服务多实例写同一个 Bitmap 时，如果各自用本地缓存的用户 ID 序列、或没对齐 ID 映射规则，就会写错 offset。
- 禁止各服务自己生成 offset —— offset 计算逻辑必须集中（例如统一由用户中心服务提供
user_id → offset接口） - 如果用了分片 Redis，Bitmap 不能跨实例，必须确保所有用户操作路由到同一分片（比如用
user_id % shard_count做哈希路由） - 上线新服务前，用脚本校验：随机抽 100 个在线用户，分别查
GETBIT和查 DB 状态，确保一致；否则说明 offset 对不上
真正麻烦的是 ID 映射逻辑一旦上线就不能轻易改 —— 改了 offset 就等于重置所有在线状态。上线前多压测，别等半夜报警才发现 90% 用户显示离线。
