本文將主要介紹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屬於易用，巧用的資料結構，用得好即能節省記憶體也可以提高效率，用得不好貌似也不會帶來太大的問題

Redis高階特性之Bitmap使用姿勢及應用場景介紹