在前面我们分享过一次redis常用数据结构和使用场景，文章对Redis基本使用做了一个简单的API说明，但是对于其中String类型中的bitmap（位图）我们需要重点说明一下，因为他的作用真的不容忽略，因为bitmap在内存资源节约上真的是太棒啦！同时因为计算机是基于二进制来运算的，所以bitmap还有天然的计算优势，如果使用bitmap来进行计算逻辑的话，性能会有大幅度提升。下面我们来分享下Redis中bitmap的实际应用场景。

统计用户每日签到

一年固定有365天或366天，这样可以用366个二进制位，即最多50个字节就可以记录每个用户一年的登录情况。某天登录把对应的二进制位改为1即可，当查询时，使用bitcount计算即可。既节省了空间，又提高了效率。假如说有1000W用户，500M空间存储足以。

用户每日签到图

统计活跃用户（去重），窗口随机

以每天的日期作为key，每个用户ID是一个二进制位，举个例子：假如说2020-01-01这一天，用户A（第一个bit位）登录了，用户B（第七个bit位）登录了；2020-01-02这一天，只有用户A登录，那么统计2020-01-01～2020-01-02这两天的活跃用户数。即可用以下命令计算：

• 第一天：
  setbit 2020-01-01 1 1
  setbit 2020-01-01 7 1
• 第二天：
  setbit 2020-01-02 1 1

统计：
先去重：bitop or destkey 2020-01-01 2020-01-02
获取结果：bitcount destkey 0 -1

用户在线状态实时统计

用户ID为offset，如果在线就设置为1，不在线就设置为0，5000W用户只需要6MB的空间。还是使用bitcount命令进行统计汇总。

数据双写去重

以上bitmap的操作都是基于用户角度来进行统计的示例，但是bitmap作用远远不仅如此。下面我们重点来看下Redis的bitmap在数据双写中扮演的重要角色。

在最近的业务数据（大约一个亿数据）迁移的时候遇到了一个比较棘手的问题，因为需要进行老系统的兼容，数据迁移完成之后需要进行双写。但是双写数据不在一个系统并且组内还没有引入分布式事务框架（比如阿里的seate），那么如何保证双写的两部分数据库数据的一致性呢？如果出现了网络抖动、连接数据库超时等异常场景如何去补偿数据？其实对于这种问题，那就是需要定时check两个双写数据库的数据，假设先入数据库数据为A库，后入数据库数据为B库，以A入库的数据库为主，去check后入库的B库数据。如果check发现数据不一致（一般都是B库数据库数据丢失情况），则将B库数据未能成功写入的数据重新写入，并且需要保证B库数据不会重复推送。

如果我们check数据条数不一致时，我们可以通过哪些方式来排查出未能成功同步的数据，并且重新推送呢？可能会有以下方案：

1. 先逐条查询A数据库数据，然后去查询B数据库是否存在，如果不存在则将该数据写入到数据库B（数据库压力过大）
2. B数据库增加唯一键，check对数据不一致时，将A数据库的数据全量推给B数据库，如果出现异常则报错即可（数据库会有大量报错，不友好）
3. B数据库增加唯一键，利用MySQL数据库的INSERT INTO ... ON DUPLICATE KEY UPDATE（不存在插入，存在则更新）方式，重新将A数据推送给B（字段过多，性能低下）
4. B数据库增加唯一键，利用Mysql数据库的REPLACE INTO方式，重新将A数据推送给B（效率很差，多进程并发一下就会锁表）
5. B数据库增加唯一键，利用Mysql数据库的INSERT IGNORE INTO，重新将A数据推送给B（不建议使用，可能会丢数据）
6. 依赖DBA，让B库通过binlog方式监听A数据的变更，但是需要引入其他中间件，比如cancel（cancel存在单点问题，程序复杂性变高）
7. 在数据库A增加触发器，当有数据变更时，通知数据库B同步（影响数据库性能）

基于以上方案，我们需要一个减轻Mysql压力同时提高系统check性能的方案，于是我们打算使用Redis的bitmap来check数据。架构方案如下图所示：

双写数据check图

主要分为2个过程

过程1）数据进行双写A库和B库，B库写成功后再写入Redis，为check定时任务做准备；

过程2）每日定时任务check，先校验A库和B库数据总条数是否一致，如果不一致则判断Redis是否存在，存在则代表双写成功，无则表示双写失败，然后重新推送。

那我们为什要使用bitmap呢？

• 我们先看下bitmap占用的空间，8个bit可以组成一个Byte，Redis指令 SETBIT key offset value，offset为数据的偏移量（我们使用Mysql的主见ID），所以大概的空间占用计算公式是：($offset/8/1024/1024)MB，占用空间随着数据量越大越明显
• 设置偏移量时的时间复杂度为O（1）
• 当我们check完数据后，需要将Redis的的key进行清除，因为check是以天为单位，所以只需要删除一个按照天为单位的key即可，对比Redis的value用String结构存要方便很多，同时提高操作性能

好的，以上是我们对bitmap（位图）实际使用场景对一个总结，当然bitmap的应用远不仅如此，比如面试过程中可能问到，在内存受限的情况下，如何在一个整数大集合找出出现次数大于等于一次的整数个数等，这里的重点一般是体现在内存受限！

不断分享开发过程用到的技术和面试经常被问到的问题，如果您也对IT技术比较感兴趣可以「关注」我