我们可以使用Redis的bitmap（位图）来存储数据。
1. 什么叫做Redis的bitmap
即：操作String数据结构的key所存储的字符串指定偏移量上的位，返回原位置的值
1.1 优点：
节省空间：通过一个bit位来表示某个元素对应的值或者状态，其中key就是对应元素的值。实际上8个bit可以组成一个Byte，所以是及其节省空间的。
效率高：setbit和getbit的时间复杂度都是O(1)，其他位运算效率也高。
1.2 缺点：
本质上位只有0和1的区别，所以用位做业务数据记录，就不需要在意value的值。
2. Redis的bitmap命令
2.1 setbit命令
设置或修改key上的偏移量（offset）的位（value）的值。
语法：setbit key offset value
返回值：指定偏移量（offset）原来存储的值。
注意：如果offset过大，则会在中间填充0
offset最大到2^32-1，即可推出最大的字符串为512M
bitmap的setkey指令
2.2 getbit命令
查询key所存储的字符串值，获取偏移量上的位。
语法：getbit key offset
返回值：返回指定key上的偏移量，若key不存在，那么返回0。
bitmap的getbit指令
2.3 bitcount 命令
计算给定key的字符串值中，被设置为1的位bit的数量
语法：bitcount key [start] [end]
返回值：1比特位的数量
注意：setbit是设置或者清除bit位置。这个是统计key出现1的次数。
需要注意的是：[start][end]（单位）实际是byte，这是什么意思呢？进入redis实际上是乘以8。
// 计算长度为 count 的二进制数组指针 s 被设置为 1 的位数量
// 这个函数只能在最大为 512 MB 的字符串上使用
size_t redisPopcount(void *s, long count) {
size_t bits = 0;
unsigned char *p = s;
uint32_t *p4;
// 通过查表来计算，对于 1 字节所能表示的值来说
// 这些值的二进制表示所带有的 1 的数量
// 比如整数 3 的二进制表示 0011 ，带有两个 1
// 正好是查表 bitsinbyte[3] == 2
static const unsigned char bitsinbyte[256] = {
0,1,1,2,1,2,2,3,1,2,2,3,2,3,3,4,1,2,2,3,2,3,3,4,2,3,3,4,3,4,4,5,1,2,2,3,2,3,3,4,2,3,3,4,3,4,4,5,2,3,3,4,3,4,4,5,3,4,4,5,4,5,5,6,1,2,2,3,2,3,3,4,2,3,3,4,3,4,4,5,2,3,3,4,3,4,4,5,3,4,4,5,4,5,5,6,2,3,3,4,3,4,4,5,3,4,4,5,4,5,5,6,3,4,4,5,4,5,5,6,4,5,5,6,5,6,6,7,1,2,2,3,2,3,3,4,2,3,3,4,3,4,4,5,2,3,3,4,3,4,4,5,3,4,4,5,4,5,5,6,2,3,3,4,3,4,4,5,3,4,4,5,4,5,5,6,3,4,4,5,4,5,5,6,4,5,5,6,5,6,6,7,2,3,3,4,3,4,4,5,3,4,4,5,4,5,5,6,3,4,4,5,4,5,5,6,4,5,5,6,5,6,6,7,3,4,4,5,4,5,5,6,4,5,5,6,5,6,6,7,4,5,5,6,5,6,6,7,5,6,6,7,6,7,7,8};
/* Count initial bytes not aligned to 32 bit. */
while((unsigned long)p & 3 && count) {
bits += bitsinbyte[*p++];
count--;
}
/* Count bits 16 bytes at a time */
// 每次统计 16 字节
// 关于这里所使用的优化算法，可以参考：
// http://yesteapea.wordpress.com/2013/03/03/counting-the-number-of-set-bits-in-an-integer/
p4 = (uint32_t*)p;
while(count>=16) {
uint32_t aux1, aux2, aux3, aux4;
aux1 = *p4++;
aux2 = *p4++;
aux3 = *p4++;
aux4 = *p4++;
count -= 16;
aux1 = aux1 - ((aux1 >> 1) & 0x55555555);
aux1 = (aux1 & 0x33333333) + ((aux1 >> 2) & 0x33333333);
aux2 = aux2 - ((aux2 >> 1) & 0x55555555);
aux2 = (aux2 & 0x33333333) + ((aux2 >> 2) & 0x33333333);
aux3 = aux3 - ((aux3 >> 1) & 0x55555555);
aux3 = (aux3 & 0x33333333) + ((aux3 >> 2) & 0x33333333);
aux4 = aux4 - ((aux4 >> 1) & 0x55555555);
aux4 = (aux4 & 0x33333333) + ((aux4 >> 2) & 0x33333333);
bits += ((((aux1 + (aux1 >> 4)) & 0x0F0F0F0F) * 0x01010101) >> 24) +
((((aux2 + (aux2 >> 4)) & 0x0F0F0F0F) * 0x01010101) >> 24) +
((((aux3 + (aux3 >> 4)) & 0x0F0F0F0F) * 0x01010101) >> 24) +
((((aux4 + (aux4 >> 4)) & 0x0F0F0F0F) * 0x01010101) >> 24);
}
/* Count the remaining bytes. */
// 不足 16 字节的，剩下的每个字节通过查表来完成
p = (unsigned char*)p4;
while(count--) bits += bitsinbyte[*p++];
return bits;
}
bitcount指令的使用
2.4 bitop命令
对一个或多个保存二进制的字符串key进行元操作，并将结果保存到destkey上。
语法：operation可以是and、or、not、xor的一种。
bitop and destkey key [key...]，对一个或多个key逻辑并，结果保存到destkey。
bitop or destkey key [key...]，对一个或多个key逻辑或，结果保存到destkey。
bitop xor destkey key [key...]，对一个或多个key逻辑异或，结果保存到destkey。
bitop xor destkey key，对一个或多个key逻辑非，结果保存到destkey。
除了NOT之外，其他操作多可以接受一个或多个key作为输入。
（敲黑板，划重点）BITOP的时间复杂度是O(N)，当处理大型矩阵或者大量数据统计时，最好将任务指派到附属节点（slave）进行，避免阻塞主节点。
优势
1.基于最小的单位bit进行存储，所以非常省空间。
2.设置时候时间复杂度O(1)、读取时候时间复杂度O(1)，操作是非常快的。
3.二进制数据的存储，进行相关计算的时候非常快。
4.方便扩容
限制
redis中bit映射被限制在512MB之内，所以最大是2^32位。
3. bitmap的使用场景
使用方式很多，根据不同的业务需求来，但是总的来说就两种，以用户为例子：
1.一种是某一用户的横向扩展，即此个key值中记录这当前用户的各种状态值，允许无限扩展(2^32内)
点评：这种用法基本上是很少用的，因为每个key携带uid信息，如果存储的key的空间大于value，从空间角度看有一定的优化空间，如果是记录长尾的则可以考虑。
2.一种是某一用户的纵向扩展，即每个key只记录当前业务属性的状态，每个uid当作bit位来记录信息(用户超过2^32内需要分片存储)
点评：基本上项目使用的场景都是基于这种方式的，按业务区分方便回收资源，key值就一个，将uid的存储转为了位的存储，十分巧妙的通过uid即可找到相应的值，主要存储量在value上，符合预期。
1.视频属性的无限延伸
需求分析：
一个拥有亿级数据量的短视频app，视频存在各种属性(是否加锁、是否特效等等)，需要做各种标记。
可能想到的解决方案：
1.存储在mysql中，肯定不行，一个是随着业务增长属性一直增加，并且存在有时间限制的属性，直接对数据库进行加减字段是非常不合理的做法。即使是存在一个字段中用json等压缩技术存储也存在读效率的问题，并且对于大几亿的数据来说，废弃的字段回收起来非常麻烦。
2.直接记录在redis中，根据业务属性＋uid为key来存储。读写效率角度没毛病，但是存储的角度来说key的数据量都大于value了，太耗费空间了。即使是用json等压缩技术来存储。也存在问题，解压需要时间，并且大几亿的数据回收也是难题。
设计方案：
使用redis的bitmap进行存储。
key由属性id＋视频分片id组成。value按照视频id对分片范围取模来决定偏移量offset。10亿视频一个属性约120m还是挺划算的。
伪代码：
function set($business_id , $media_id , $switch_status=1){
$switch_status = $switch_status ? 1 : 0;
$key = $this->_getKey($business_id, $media_id);
$offset = $this->_getOffset($media_id);
return $this->redis->setBit($key, $offse, $switch_status);
}
function get($business_id , $media_id){
$key = $this->_getKey($business_id,$media_id);
$offset = $this->_getOffset($media_id);
return $this->redis->getBit($key , $offset);
}
function _getKey($business_id, $media_id){
return 'm:'.$business_id.':'.intval($media_id/10000);
}
function _getOffset($media_id){
return $media_id % 10000;
}
这样基本实现了属性的存储，后续增加新属性也只是business_id再增加一个值。
至于为什么分片呢？分片的粒度怎么衡量？
分片有两个原因：1. 在不密集分布中，长度过长，会有大量的0无用值占用内存资源 2.bitmap有长度限制2^32。
分片粒度怎么衡量：1.如果主键id存在的断层那么请尽可能选择的粒度可以避开此段id范围，防止空间浪费，因为来一个00000…9999个0…01，那么因为存一个属性而存了全部的，就浪费了。2.分片粒度可参考某一单位时间的增长值来判断，这样也有利于预算占了多少空间，虽然空间不会占很多。
2.用户在线状态
需求分析：
需要对子项目提供一个接口，来提供某用户是否在线？
设计方案：
使用bitmap是一个节约空间效率又高的一种方法，只需要一个key，然后用户id为偏移量offset，如果在线就设置为1，不在线就设置为0，3亿用户只需要36MB的空间。
伪代码：
$status = 1;
$redis->setBit('online', $uid, $status);
$redis->getBit('online', $uid);
需要加上如例子1一样分片的方式。10亿真的太多了。10w分一片。
3.统计活跃用户
需求分析：
需要计算活跃用户的数据情况。
设计方案：
使用时间作为缓存的key，然后用户id为offset，如果当日活跃过就设置为1。之后通过bitOp进行二进制计算算出在某段时间内用户的活跃情况。
伪代码：
$status = 1;
$redis->setBit('active_20170708', $uid, $status);
$redis->setBit('active_20170709', $uid, $status);
$redis->bitOp('AND', 'active', 'active_20170708', 'active_20170709');
上亿用户需要加上如例子1一样分片的方式。几十万或者以下，可无需分片省的业务变复杂。
其他 类似情况：
key：日期；
offset：用户id【数字或者二进制】；
value：是否登录/做任意操作；
按日期生成一个位图（bitmap）
计算月活：可把30天的所有bitmap做or计算，在进行bitcount计算；
计算留存率：昨日留存=昨天今天连续登录的人数/昨天登录的人数，即昨天的bitmap与今天的bitmap进行and计算，在除以昨天bitcount的数量。
4.用户签到
需求分析：
用户需要进行签到，对于签到的数据需要进行分析与相应的运运营策略。
设计方案：
使用redis的bitmap,由于是长尾的记录，所以key主要由uid组成，设定一个初始时间，往后没加一天即对应value中的offset的位置。
伪代码：
$start_date = '20170708';
$end_date = '20170709';
$offset = floor((strtotime($start_date) - strtotime($end_date)) / 86400);
$redis->setBit('sign_123456', $offset, 1);
//算活跃天数
$redis->bitCount('sign_123456', 0, -1)
无需分片，一年365天，3亿用户约占300000000*365/8/1000/1000/1000=13.68g。存储成本是不是很低。
使用bitmap过程中可能会遇到的坑
1.bitcout的陷阱
如果你有仔细看前文的用法，会发现有这么一个备注“返回一个指定key中位的值为1的个数(是以byte为单位不是bit)”，这就是坑的所在。
有图有真相：
所以bitcount 0 0 那么就应该是第一个字节中1的数量的，注意是字节，第一个字节也就是0,1,2,3,4,5,6,7这八个位置上。
4.使用 set 和 BitMap 存储的对比、
通过上面的对比，我们可以看到，如果独立用户数量很多，使用 BitMap 明显更有优势，能节省大量的内存。但如果独立用户数量较少，还是建议使用 set 存储，BitMap 会产生多余的存储开销。
使用经验
type = string，BitMap 是 sting 类型，最大 512 MB。
注意 setbit 时的偏移量，可能有较大耗时
位图不是绝对好。