Mastering Redis Bitmap for Efficient Binary State Statistics in Mobile Apps

In mobile application scenarios we often need to associate a key with a collection of data, such as determining a user’s login state, showing a user’s monthly sign‑in count, or aggregating sign‑ins for billions of users. When the number of users or visits reaches millions or even hundreds of millions, an extremely efficient collection type is required for large‑scale statistics.

Four Statistical Types

The article distinguishes four common statistical patterns: binary state statistics, aggregate statistics, sorted statistics, and cardinality statistics. This piece focuses on the binary state type, where each element can only be 0 or 1.

Why String Is Memory‑Intensive

Using Redis String to store a binary flag for each user incurs significant overhead. A Redis string is implemented with the SDS (Simple Dynamic String) structure, which contains:

len : 4 bytes, the used length of the buffer.

alloc : 4 bytes, the total allocated length (usually > len).

buf : the byte array that holds the actual data, plus an extra terminating "\0" byte.

In addition, every Redis object carries a RedisObject header that stores metadata such as the last access time and reference count, further increasing memory consumption.

Bitmap: A Space‑Saving Alternative

Bitmap stores bits directly in the underlying SDS buffer, using each bit to represent a binary state. One bit per user means 100 million users occupy only about 12 MB (100 000 000 / 8 / 1024 / 1024). The space‑usage formula is: (offset / 8 / 1024 / 1024) MB Bitmap’s internal structure treats the buffer as an array of bytes, each byte holding eight bits, as illustrated in the following diagram:

Determining User Login State with Bitmap

Redis provides GETBIT and SETBIT commands to read and write individual bits. By using a single key (e.g., login_status) and treating the user ID as the offset, we can set a bit to 1 for online and 0 for offline.

SETBIT login_status 10086 1   // mark user 10086 as logged in

GETBIT login_status 10086      // returns 1 if online, 0 otherwise

SETBIT login_status 10086 0   // log out the user

Storing 50 million users this way consumes only about 6 MB of memory.

Tracking Monthly Sign‑In Records

Each day’s sign‑in can be represented by one bit. A key pattern such as uid:sign:{userId}:{yyyyMM} stores a month’s bits, where the offset equals day‑1 (because offsets start at 0).

SETBIT uid:sign:89757:202105 15 1   // user 89757 signs in on May 16, 2021

GETBIT uid:sign:89757:202105 15   // check sign‑in on that day

BITCOUNT uid:sign:89757:202105      // total sign‑ins in May

To find the first sign‑in day of the month, Redis offers BITPOS:

BITPOS uid:sign:89757:202105 1   // returns the offset of the first 1‑bit

Since offsets start at 0, add 1 to obtain the calendar day.

Counting Users with 7‑Day Continuous Sign‑Ins

Store each day’s sign‑in bitmap under a separate key (e.g., bitmap:20210101, bitmap:20210102, …). By applying a bitwise AND across the seven daily bitmaps, the resulting bitmap marks users who signed in on all seven days.

// Bitwise AND of three example days
BITOP AND destmap bitmap:01 bitmap:02 bitmap:03
BITCOUNT destmap   // number of users with 7‑day continuous sign‑ins

A bitmap of 100 million bits occupies roughly 12 MB; seven such bitmaps need about 84 MB. Setting an expiration on daily bitmaps helps reclaim memory.

Conclusion

When a statistical scenario only requires binary states—such as online/offline flags, blacklist checks, or sign‑in tracking—using Redis Bitmap dramatically reduces memory consumption while providing fast O(1) read/write operations.