當我們在談論Redis的數據結構時，我們通常會想到靈活多樣的String、無處不在的List、快速查找的Hash等等。但今天，我們要深入探討一個看似簡單、實則威力巨大的數據類型——BitMap（位圖）。它就像一個擁有超能力的開關陣列，能以不可思議的效率和極低的空間成本解決許多棘手問題。
什麼是BitMap？
從本質上講，BitMap並不是一種獨立的數據結構。在Redis底層，它是通過String類型來實現的。你可以把一個String想象成一個由比特（bit）組成的數組，數組的每個單元只能存儲0或1。
鍵(Key) ：就是你的Bitmap的名字。
偏移量(Offset) ：可以理解為這個比特數組的索引位置。
值(Value) ：在指定索引位置上只能是一個二進制位——0或者1。
所以，當你執行 SETBIT mykey 7 1 時，你實際上是在名為 mykey 的字符串的第7個比特位上設置了一個“1”。
BitMap的核心命令
要駕馭BitMap，你需要掌握幾個簡單的命令：
1.SETBIT key offset value *為指定的Key的偏移量設置值（0或1）。 *例如：SETBIT login:20240520 10001 1 （表示用户ID為10001的用户在2024-05-20登錄了）
2.GETBIT key offset *獲取指定Key的偏移量上的值。 *例如：GETBIT loginBIT login:20240520 10001 （返回1，表示該用户已登錄）
3.BITCOUNT key [start end] *統計指定位範圍內值為1的比特數量。這是最強大的命令之一！ *例如：BITCOUNT login:20240520 （返回當天總共有多少獨立用户登錄）
4.BITOP operation destkey key [key ...] *對一個或多個Bitmap進行位運算（AND, OR, XOR, NOT），並將結果存儲在目標Key中。 *例如：BITOP AND weekly_login login:mon login:tue ... （計算本週每天都登錄的用户）
5.BITPOS key bit [start] [end]
為什麼BitMap如此高效？
我們來算一筆賬。
假設你有1億用户（user_id範圍從1到100,000,000）。如果你想用傳統的Set來記錄每天的活躍用户，每個用户ID假設佔8字節，那麼每天的數據量大約是： 100,000,000 * 8 bytes ≈ 800 MB
現在，改用BitMap。你需要為每個用户分配一個比特位（offset）。記錄1億用户的活躍狀態只需要： 100,000,000 bits ≈ 12 MB
12MB vs 800MB！ 空間節省了超過98倍！這種空間效率在處理海量數據時是決定性的優勢。
實戰場景：我能用BitMap做什麼？
理論説再多不如看實戰。以下是BitMap的幾個經典應用場景：
1. 用户行為標記與統計
這是最常見的用途。比如記錄用户每日簽到、是否閲讀過某條消息、是否有某個權限等。
# 用户12345在2024年第200天簽到了
SETBIT sign:2024:12345 199 1 # 注意：偏移量從0開始，第200天對應199
# 檢查他第150天是否簽到 (GETBIT sign:2024:12345 149)
# 統計他今年總共簽到天數 (BITCOUNT sign:2024:12345)2. 實時活躍用户分析
結合 BITOP，可以進行復雜的羣體分析。
# 記錄週一和週二的活躍用户
SETBIT active:monday 100 1
SETBIT active:monday 101 1
SETBIT active:tuesday 100 1
SETBIT active:tuesday 102 1
# 找出兩天都活躍的用户（交集）
BITOP AND active_both_days active:monday active:tuesday
# BITCOUNT active_both_days 結果為 結果為1 (只有用户100)
# 找出兩天中至少一天活躍的用户（並集）
BITOP OR active_either_day active:monday active:tuesday
# BITCOUNT active_either_day 結果為3 (用户100,101,102)3. 布隆過濾器（Bloom Filter）
BitMap是實現布隆過濾器的絕佳後端。布隆過濾器是一種概率型數據結構，用於判斷一個元素一定不在集合中或可能在集合中。它非常適合做緩存穿透防護、爬蟲URL去重等。
（雖然Redis有官方模塊RedisBloom，但其核心思想就是用多個哈希函數將元素映射到BitMap的不同位置上）。
使用BitMap的注意事項
沒有完美的工具，BitMap也不例外：
稀疏性問題：如果你的用户ID非常稀疏（例如，只有少數幾個隨機的大數值用户ID），BitMap可能會浪費一些空間，因為它會分配從0到你設置的最大偏移量之間的所有內存。但在大多數連續自增ID的場景下，這不成問題。
大偏移量處理：首次設置一個非常大的偏移量（如 SETBIT huge 536870913 1）時，Redis需要分配相應的內存，可能會導致短暫的阻塞。建議提前初始化大的BitMap或在非高峯時段操作。
理解偏移量：偏移量是從0開始的整數。直接使用用户ID作為偏移量時要小心，如果用户ID不是從0或1開始的連續數字，會造成巨大的空間浪費。通常需要一個映射層。
總結
Redis的BitMap是一個典型的“小身材，大能量”的工具。它將信息壓縮到了極致，並通過簡單的位操作提供了強大的聚合計算能力。在面對海量用户的二分狀態（是/否）統計和關係分析時，它往往是性能最高、成本最低的解決方案。
