本文將主要介紹Bitmap的使用姿勢以及其適用場景，主要知識點包括

• bitmap 基本使用
• 榷訓統計應用場景中bitmap使用姿勢
• 點贊去重應用場景中bitmap使用姿勢
• 布隆過濾器bloomfilter基本原理及體驗case

I. 基本使用

1. 配置

我們使用SpringBoot 2.2.1.RELEASE 來搭建專案環境，直接在 pom.xml 中添加redis依賴

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

如果我們的redis是默認配置，則可以不額外添加任何配置；也可以直接在 application.yml配置中，如下

spring:
  redis:
    host: 127.0.0.1
    port: 6379
    password:

2. 使用姿勢

bitmap主要就三個操作命令， setbit ， getbit 以及 bitcount

a. 設定標記

即 setbit ，主要是指將某個索引，設定為1(設定0表示抹去標記)，基本語法如下

# 請注意這個index必須是數字，后面的value必須是0/1
setbit key index 0/1

對應的SpringBoot中，借助RestTemplate可以比較容易的實作，通常有兩種寫法，都可以

@Autowired
private StringRedisTemplate redisTemplate;

/**
 * 設定標記位
 *
 * @param key
 * @param offset
 * @param tag
 * @return
 */
public Boolean mark(String key, long offset, boolean tag) {
    return redisTemplate.opsForValue().setBit(key, offset, tag);
}

public Boolean mark2(String key, long offset, boolean tag) {
    return redisTemplate.execute(new RedisCallback<Boolean>() {
        @Override
        public Boolean doInRedis(RedisConnection connection) throws DataAccessException {
            return connection.setBit(key.getBytes(), offset, tag);
        }
    });
}

上面兩種寫法的核心區別，就是key的序列化問題，第一種寫法使用默認的jdk字串序列化，和后面的getBytes() 會有一些區別，關于這個，有興趣的小伙伴可以看一下我之前的博文: RedisTemplate配置與使用#序列化問題

b. 判斷存在與否

即 getbit key index ，如果回傳1，表示存在否則不存在

/**
 * 判斷是否標記過
 *
 * @param key
 * @param offest
 * @return
 */
public Boolean container(String key, long offest) {
    return redisTemplate.opsForValue().getBit(key, offest);
}

c. 計數

即 bitcount key ，統計和

/**
 * 統計計數
 *
 * @param key
 * @return
 */
public long bitCount(String key) {
    return redisTemplate.execute(new RedisCallback<Long>() {
        @Override
        public Long doInRedis(RedisConnection redisConnection) throws DataAccessException {
            return redisConnection.bitCount(key.getBytes());
        }
    });
}

3. 應用場景

前面的基本使用比較簡單，在介紹String資料結構的時候也提過，我們重點需要關注的是bitmap的使用場景，它可以干嘛用，什么場景下使用它會有顯著的優勢

• 榷訓統計
• 點贊
• bloomfilter

上面三個場景雖有相似之處，但實際的應用場景還是些許區別，接下來我們逐一進行說明

a. 榷訓統計

統計應用或網站的榷訓，這個屬于比較常見的case了，如果是用redis來做這個事情，首先我們最容易想到的是Hash結構，一般邏輯如下

• 根據日期，設定key，如今天為 2020/10/13 , 那么key可以為 app_20_10_13
• 其次當用戶訪問時，設定field為userId, value設定為true
• 判斷榷訓則是統計map的個數 hlen app_20_10_13

上面這個邏輯有毛病么？當然沒有問題，但是想一想，當我們的應用做的很nb的時候，每天的榷訓都是百萬，千萬級時，這個記憶體開銷就有點嚇人了

接下來我們看一下bitmap可以怎么做

setbit app_20_10_13 uesrId 1
bitcount app_20_10_13

簡單對比一下上面兩種方案

當資料量小時，且userid分布不均勻，小的為個位數，大的幾千萬，上億這種，使用bitmap就有點虧了，因為userId作為index，那么bitmap的長度就需要能容納最大的userId，但是實際榷訓又很小，說明bitmap中間有大量的空白資料

反之當資料量很大時，比如百萬/千萬，userId是連續遞增的場景下，bitmap的優勢有兩點：1.存盤開銷小， 2.統計總數快

c. 點贊

點贊的業務，最主要的一點是一個用戶點贊過之后，就不能繼續點贊了（當然某些業務場景除外），所以我們需要知道是否可以繼續點贊

上面這個hash當然也可以實作，我們這里則主要討論一下bitmap的實作邏輯

like_1121
getbit like_1121 userId

Hash以及bitmap的選擇和上面的考量范圍差不多

d. 布隆過濾器bloomfilter

布隆過濾器可謂是大名鼎鼎了，我們這里簡單的介紹一下這東西是啥玩意

• 底層存盤為一個bitmap
• 當來一個資料時，經過n個hash函式，得到n個數值
• 將hash得到的n個數值，映射到bitmap，標記對應的位置為1

如果來一個資料，通過hash計算之后，若這個n個值，對應的bitmap都是1，那么表示這個資料可能存在；如果有一個不為1，則表示這個資料一定不存在

請注意：不存在時，是一定不存在；存在時，則不一定

從上面的描述也知道，bloomfilter的底層資料結構就是bitmap，當然它的關鍵點在hash演算法；根據它未命中時一定不存在的特性，非常適用于快取擊穿的問題解決

體驗說明

Redis的布隆過濾器主要針對>=4.0，通過插件的形式提供，專案原始碼地址為: https://github.com/RedisBloom/RedisBloom ，下面根據readme的說明，簡單的體驗一下redis中bloomfilter的使用姿勢

# docker 方式安裝
docker run -p 6379:6379 --name redis-redisbloom redislabs/rebloom:latest

# 通過redis-cli方式訪問
docker exec -it redis-redisbloom bash

# 開始使用
# redis-cli
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> bf.add newFilter hello
(integer) 1
127.0.0.1:6379> bf.exists newFilter hello
(integer) 1
127.0.0.1:6379> bf.exists newFilter hell
(integer) 0

bloomfilter的使用比較簡單，主要是兩個命令 bf.add 添加元素， bf.exists 判斷是否存在，請注意它沒有洗掉哦

4. 小結

bitmap位圖屬于一個比較精巧的資料結構，通常在資料量大的場景下，會有出現的表現效果；redis本身基于String資料結構來實作bitmap的功能支持，使用方式比較簡單，基本上就下面三個命令

setbit key index 1/0
getbit key index
bitcount key

本文也給出了bitmap的三個常見的應用場景

bitcount
setbit/getbit

總的來講，bitmap屬于易用，巧用的資料結構，用得好即能節省記憶體也可以提高效率，用得不好貌似也不會帶來太大的問題