Redis那玩意儿，咋用位存储来搞得又快又省空间呢？

直接说Redis用位存储这事儿，其实就像你有一大排灯泡，每个灯泡只有亮和灭两种状态，Redis里有个叫“位图”的东西，它本质上就是字符串，但Redis让你能直接操作这个字符串里的每一个二进制位，你可以把每一个位想象成一个小开关，用来表示“是”或“否”、“有”或“无”，这么干，最大的好处就是“省”和“快”。

为啥能省到极致？ 因为一个位（bit）只能存0或1，所以你想记录一个用户的两种状态（比如每天签到与否），通常你用一个整型变量（比如4字节32位）或者一个布尔值，但在位图里，你只需要1个位，根据《Redis设计与实现》里的说明，Redis的字符串底层是用动态数组（SDS）存的，位图就是基于这个，如果你有1亿个用户ID，你想记录他们某天是否登录，用普通的键值对可能得存1亿个键值，或者一个巨大的列表，内存吓死人，但用位图，你只需要开辟一个足够长的二进制位数组，每个用户ID对应一个偏移位置，1亿个用户，大约只需要12.5MB的内存（1亿位 / 8位/字节 ≈ 12.5MB）,这省得不是一点半点。

具体咋操作？快在哪儿？ Redis提供了几个直接操作位的命令，核心是 SETBIT 和 GETBIT，你把用户ID当作偏移量（比如用户ID是123456，就操作第123456个位），用 SETBIT key 123456 1 就表示这个用户签到了，写个1，查的时候用 GETBIT key 123456，马上就能返回是1还是0，这个操作复杂度是O(1)，直接算位置、找内存、读写位，速度极快,跟查字典一样。

更厉害的是，Redis还提供了批量位操作命令，BITCOUNT 能快速统计一个位图里有多少个1（比如统计总签到人数），BITOP 能对多个位图进行与、或、异或这些操作（比如找出连续两天都签到的用户），这些操作在底层是直接对字节数组进行高效运算，CPU特别擅长干这个，所以速度非常猛,比你在应用层写循环一个个判断快无数倍。

举个实在的例子 比如你们公司搞个连续签到活动，要记录一年里所有用户每天的签到情况，如果为每个用户每天存一条记录，数据量爆炸，用位图，你可以为每个用户创建一个键，这个键对应一个365位的位图，用户第一天签到，就在第0位设成1；第二天签到，第1位设成1，一年下来，一个用户只需要约46个字节（365位 / 8 ≈ 45.6字节），要查他某天是否签到，或者统计他本月签到次数（用 BITCOUNT 加范围参数）,都是瞬间的事。

需要注意的点 位图也不是万能钥匙，它最适合的就是这种海量的、简单的二值状态记录，如果你的偏移量（比如用的用户ID）特别大、特别稀疏，比如就几个用户，但用户ID是10亿，那Redis也得为你初始化一个足够大的位数组，可能会暂时浪费一些内存（但比存海量键值还是省太多），根据Redis官方文档的建议，对于大位图进行 BITOP 这类操作可能会比较耗时，因为它需要遍历很多字节，最好放在从节点上跑,别阻塞主节点。

总结一下 Redis的位存储，就是把你手里那些需要标记“是/否”、“有/无”的海量小状态，压缩到最小的二进制单位里，然后利用CPU对位运算的原生支持，进行闪电般的读写和统计，它解决问题的场景非常特定，但一旦用对了地方，比如用户行为标记、实时在线统计、布隆过滤器等，那在节省内存和提升速度方面，绝对是“神器”级别的存在，你把它理解成一个超级紧凑、速度飞快的二进制开关板,就对了。