bitmap技术解析：redis与roaringBitmap
bitmap的表象意义是，使用一个01标识位来表示是否的状态，可以达到节省空间和高效判定的效果。在我们的实际工作中，也有着许多的应用场景，相信了解bitmap定会给你带来一些额外的收获。
1. bitmap使用场景说明
比如，我想记录某用户某天是否登录过，我们有很多做法。简单的，只要用户登录，就在db中记录一条数据，要判断用户某天是否登录过，只需查询对应日期是否有记录即可。如果想统计当日登录的人数，count下记录就可以了（可能需要去重））。这样不是不可以，只是如果我们想优化下性能怎么办？这时我们就可以使用bitmap了，以日期为单位创建独立bitmap，一个用户id一个标识，要想判断用户是否登录过，直接取对应位标识即可。
再比如，我们有一批白名单用户，在白名单里则放行，否则拒绝访问。同样，我们可以用一行行的记录用db来保存处理，但这可能很占空间，或者性能不怎么样。同样，使用bitmap可以快速处理这种场景。
再比如，用于快速去重一些处理，第一次处理时，将标识位改为1，后续将进行幂等，用bitmap可以快速过滤。
2. bitmap的通俗理解
bitmap简单理解来说就是，bit的映射，将一个个的key映射到bit位上去，这样就可以快速通过key直接定位到标识上去了。另外，因都是一个个的bit，所以进行count操作很方便。对于两个bitmap的and/or位运算也是很方便和快速的。
3. redis的bitmap实现
理解了面上的bitmap的意思，要怎么做也就大概会有个思路了。
谈到redis，大家的映射问题：高性能，高并发，缓存解决方案。好像有了redis，就有了底气和别人一比高下了似的。那么，在bitmap方面，它是否也神奇之处呢？
实际上，redis的bitmap实现比较简单，和字面上的意思差不多，它是基于string实现的。
简单来说就是，string底层的存储也是二进制的，也就是说string天生就看起来和bitmap的存储类似，比如'ab'的底层存储就是\x61\x62, 拆解成二进制就是 0110 0001 0110 0010。如果我我们直接将其代表bitmap操作数，那么总共就有6个数据有值，分别是2,3,8,10,11,15位有值。这样说bitmap应该很清晰了。
接下来我们来讨论下一个空间问题。我们知道一个16位的二进制可以表示最大 65536，32位最大表示 4294967296，好像一个比较小的位就可以表示很大的数据了。但是这和我们说的bitmap还不一样，在这里，一个16位的二进制数只能表示16个bitmap值，32位数只能表示32个值。从这点来说，bitmap好像很浪费空间呢。我们知道，现在的大多数机器都是64位的。所以，如果我以这种结构存储的话，应该只能存64个标识了。
那么自然的，我们必须要使用一个合适的结构来存储这些bit，redis中使用string结构来存储bitmap，也就是说将string转换成二进制后，用其每一位来表示一个标识。这样的话，能够存放多少个标识就扩展到了string最大限制上去了。redis限制string最大是512M，也就是2^19KB=2^29B=2^32b，即最大2^32位。
redis的bitmap操作命令，简单示例如下：（咱们不是文档，如需手册，请参考官网）
setbit key offset 1|0 getbit key bitcount key
下面，我们简单看下redis的setbit的实现源码，具体看看其处理逻辑。
// bitops.c // 操作命令: setbit key offset 0|1 /* SETBIT key offset bitvalue */ void setbitCommand(client *c) { robj *o; char *err = "bit is not an integer or out of range"; uint64_t bitoffset; ssize_t byte, bit; int byteval, bitval; long on; // 解析 offset 值 if (getBitOffsetFromArgument(c,c->argv[2],&bitoffset,0,0) != C_OK) return; // 解析 0|1 值 if (getLongFromObjectOrReply(c,c->argv[3],&on,err) != C_OK) return; // 只接受0|1的输入，其他一律报错 /* Bits can only be set or cleared... */ if (on & ~1) { addReplyError(c,err); return; } // 获取key对应的string对象，方便后续操作 int dirty; if ((o = lookupStringForBitCommand(c,bitoffset,&dirty)) == NULL) return; // 计算偏移量: 1byte=8bit, 所以真正的位所在就等于 byte大定位 + 小移位 // 从高到低计数, 即类似于 big-endian /* Get current values */ byte = bitoffset >> 3; byteval = ((uint8_t*)o->ptr)[byte]; bit = 7 - (bitoffset & 0x7); bitval = byteval & (1 << bit); /* Either it is newly created, changed length, or the bit changes before and after. * Note that the bitval here is actually a decimal number. * So we need to use `!!` to convert it to 0 or 1 for comparison. */ if (dirty || (!!bitval != on)) { // 先取反保留当前值, 再重新设置on 进去 /* Update byte with new bit value. */ byteval &= ~(1 << bit); byteval |= ((on & 0x1) << bit); ((uint8_t*)o->ptr)[byte] = byteval; // 集群扩散 signalModifiedKey(c,c->db,c->argv[1]); notifyKeyspaceEvent(NOTIFY_STRING,"setbit",c->argv[1],c->db->id); server.dirty++; } // 返回旧的值给客户端 /* Return original value. */ addReply(c, bitval ? shared.cone : shared.czero); } // 查找key对应的 string 对象 /* This is a helper function for commands implementations that need to write * bits to a string object. The command creates or pad with zeroes the string * so that the 'maxbit' bit can be addressed. The object is finally * returned. Otherwise if the key holds a wrong type NULL is returned and * an error is sent to the client. */ robj *lookupStringForBitCommand(client *c, uint64_t maxbit, int *dirty) { size_t byte = maxbit >> 3; robj *o = lookupKeyWrite(c->db,c->argv[1]); if (checkType(c,o,OBJ_STRING)) return NULL; if (dirty) *dirty = 0; if (o == NULL) { o = createObject(OBJ_STRING,sdsnewlen(NULL, byte+1)); dbAdd(c->db,c->argv[1],o); if (dirty) *dirty = 1; } else { o = dbUnshareStringValue(c->db,c->argv[1],o); size_t oldlen = sdslen(o->ptr); o->ptr = sdsgrowzero(o->ptr,byte+1); if (dirty && oldlen != sdslen(o->ptr)) *dirty = 1; } return o; }
很简单吧，不过应对一些场景还是绰绰有余了，选对场景很重要。
redis的bitmap实现简单，易于理解，但也有比较大的弊端。这种基于string的实现方式简单是简单，但存在以下几个问题：
1. 会存在较大间隙值，比如一开始就存储一个较大的偏移标识进去，比如8位的偏移，就可能让内存占用上M级别（然而你还什么都没干）；
2.存储范围受限，最大只能存int型的数字偏移，如果以userid为偏移，在用户量小且以自增id生成用户id也许没问题，但其他情况就不好说了；
3.随着数据量越来越大，单次设置标识的耗时就会越来越长（大key问题），且一不小心使用get命令进行读取数据时，redis就尴尬了；
4. roaringbitmap实现
上篇讲到redis的实现，简单易懂，但是会存在一个极大空间浪费的问题，而且受限于数组大小，存储空间有限。那有没有什么办法，可以压缩存储空间？
roaringbitmap使用多级分段存储方式，避免了直接存储的问题：一是空隙值问题，二是数值限制问题。它主要通过将64位2个32位存储，将32位分2个16位存储的方式实现。其操作主要有:add/contains/getlongcadinaty... 等常规接口。
其大致存储结构图如下：
具体实现如下：
// 1. 引入依赖包 <dependency> <groupId>org.roaringbitmap</groupId> <artifactId>RoaringBitmap</artifactId> <version>0.9.28</version> </dependency> // 2. 建立单元测试 @Test public void testRoaringBitmap() { Roaring64NavigableMap bitmapObj = new Roaring64NavigableMap(); bitmapObj.add(11122233366L); boolean exists = bitmapObj.contains(1); long eleSize = bitmapObj.getLongCardinality(); System.out.println("exits:" + exists + ", eleSize:" + eleSize); } // 具体实现 // Roaring64NavigableMap /** * Set all the specified values to true. This can be expected to be slightly faster than calling * "add" repeatedly. The provided integers values don't have to be in sorted order, but it may be * preferable to sort them from a performance point of view. * * @param dat set values */ public void add(long... dat) { for (long oneLong : dat) { addLong(oneLong); } } /** * Add the value to the container (set the value to "true"), whether it already appears or not. * * Java lacks native unsigned longs but the x argument is considered to be unsigned. Within * bitmaps, numbers are ordered according to {@link Long#compareUnsigned}. We order the numbers * like 0, 1, ..., 9223372036854775807, -9223372036854775808, -9223372036854775807,..., -1. * * @param x long value */ @Override public void addLong(long x) { // 高低位32位拆分 (int) (id >> 32) int high = high(x); int low = low(x); // Copy the reference to prevent race-condition Map.Entry<Integer, BitmapDataProvider> local = latestAddedHigh; BitmapDataProvider bitmap; if (local != null && local.getKey().intValue() == high) { bitmap = local.getValue(); } else { bitmap = highToBitmap.get(high); if (bitmap == null) { // 使用 RoaringBitmap 来保存低层数据, 一级存储 // 使用 treemap 保存整个结构，保证查找快速 bitmap = newRoaringBitmap(); pushBitmapForHigh(high, bitmap); } // 使用临时保存当前高位实例的方式，避免经常查找map带来的性能消耗 // 但实际上这要求客户端的操作是按序操作的，这样才能很好利用这个特性，如果只是随机值的话，效果就大打折扣了 latestAddedHigh = new AbstractMap.SimpleImmutableEntry<>(high, bitmap); } // 存储低位信息 bitmap.add(low); // 扩容处理 invalidateAboveHigh(high); } private void invalidateAboveHigh(int high) { // The cardinalities after this bucket may not be valid anymore if (compare(firstHighNotValid, high) > 0) { // High was valid up to now firstHighNotValid = high; int indexNotValid = binarySearch(sortedHighs, firstHighNotValid); final int indexAfterWhichToReset; if (indexNotValid >= 0) { indexAfterWhichToReset = indexNotValid; } else { // We have invalidate a high not already present: added a value for a brand new high indexAfterWhichToReset = -indexNotValid - 1; } // This way, sortedHighs remains sorted, without making a new/shorter array Arrays.fill(sortedHighs, indexAfterWhichToReset, sortedHighs.length, highestHigh()); } allValid = false; } // 低位存储实现 // roaringbitmap /** * Add the value to the container (set the value to "true"), whether it already appears or not. * * Java lacks native unsigned integers but the x argument is considered to be unsigned. * Within bitmaps, numbers are ordered according to {@link Integer#compareUnsigned}. * We order the numbers like 0, 1, ..., 2147483647, -2147483648, -2147483647,..., -1. * * @param x integer value */ @Override public void add(final int x) { // 再分高低位存储, 即32位拆分为2个16位, (char) (x >>> 16) final char hb = Util.highbits(x); // 已经存储过了，则直接更新值即可 // highLowContainer = new RoaringArray(); final int i = highLowContainer.getIndex(hb); if (i >= 0) { // 此处查找成功，只是代表高位已经被某些值存储过了，但低位仍然在变化 highLowContainer.setContainerAtIndex(i, highLowContainer.getContainerAtIndex(i).add(Util.lowbits(x))); } else { // 否则新插入一个你们数, 默认以数组形式存储, 默认初始化大小为4 final ArrayContainer newac = new ArrayContainer(); highLowContainer.insertNewKeyValueAt(-i - 1, hb, newac.add(Util.lowbits(x))); } } // involves a binary search int getIndex(char x) { // before the binary search, we optimize for frequent cases if ((size == 0) || (keys[size - 1] == x)) { return size - 1; } // 使用二分查找法查找值的存在性，实际上内部还有其他优化 // no luck we have to go through the list return this.binarySearch(0, size, x); } // insert a new key, it is assumed that it does not exist void insertNewKeyValueAt(int i, char key, Container value) { extendArray(1); System.arraycopy(keys, i, keys, i + 1, size - i); keys[i] = key; System.arraycopy(values, i, values, i + 1, size - i); values[i] = value; size++; } // RoaringArray protected Container getContainerAtIndex(int i) { return this.values[i]; } // 数组的低位存储实现 // ArrayContainer /** * running time is in O(n) time if insert is not in order. */ @Override public Container add(final char x) { // 要插入的值大于当前容量/未大于当前容量分别处理 if (cardinality == 0 || (cardinality > 0 && (x) > (content[cardinality - 1]))) { // 大于 4096 后，扩展为 bitmap存储结构 if (cardinality >= DEFAULT_MAX_SIZE) { return toBitmapContainer().add(x); } // 扩容，策略分多种情况处理 if (cardinality >= this.content.length) { increaseCapacity(); } // 直接数组存储具体值即可 // 也就是说，表面看起来这里可能会被插入重复的值，但是实际这里插入的是比最大值还大的值 // 更小的值则会先查找存在性，再进行找位插入 content[cardinality++] = x; } else { int loc = Util.unsignedBinarySearch(content, 0, cardinality, x); // 小的值被插入到中间，如果找到相同的值，则本次add将被忽略 // 也就是说，这种实现的是数据的有序插入 if (loc < 0) { // Transform the ArrayContainer to a BitmapContainer // when cardinality = DEFAULT_MAX_SIZE if (cardinality >= DEFAULT_MAX_SIZE) { return toBitmapContainer().add(x); } if (cardinality >= this.content.length) { increaseCapacity(); } // insertion : shift the elements > x by one position to // the right // and put x in it's appropriate place System.arraycopy(content, -loc - 1, content, -loc, cardinality + loc + 1); content[-loc - 1] = x; ++cardinality; } } return this; } // temporarily allow an illegally large size, as long as the operation creating // the illegal container does not return it. private void increaseCapacity(boolean allowIllegalSize) { int newCapacity = (this.content.length == 0) ? DEFAULT_INIT_SIZE : this.content.length < 64 ? this.content.length * 2 : this.content.length < 1067 ? this.content.length * 3 / 2 : this.content.length * 5 / 4; // never allocate more than we will ever need if (newCapacity > ArrayContainer.DEFAULT_MAX_SIZE && !allowIllegalSize) { newCapacity = ArrayContainer.DEFAULT_MAX_SIZE; } // if we are within 1/16th of the max, go to max if (newCapacity > ArrayContainer.DEFAULT_MAX_SIZE - ArrayContainer.DEFAULT_MAX_SIZE / 16 && !allowIllegalSize) { newCapacity = ArrayContainer.DEFAULT_MAX_SIZE; } this.content = Arrays.copyOf(this.content, newCapacity); } // bitmap的低位存储实现 // BitmapContainer // 转移老数据到bitmap的低位存储中 /** * Copies the data in a bitmap container. * * @return the bitmap container */ @Override public BitmapContainer toBitmapContainer() { BitmapContainer bc = new BitmapContainer(); bc.loadData(this); return bc; } void loadData(final ArrayContainer arrayContainer) { this.cardinality = arrayContainer.cardinality; for (int k = 0; k < arrayContainer.cardinality; ++k) { final char x = arrayContainer.content[k]; // 取整64, 这个移位是真没看懂, 反正超过31之后的 bitmap[(x) / 64] |= (1L << x); } } @Override public Container add(final char i) { final long previous = bitmap[i >>> 6]; long newval = previous | (1L << i); bitmap[i >>> 6] = newval; if (USE_BRANCHLESS) { cardinality += (int)((previous ^ newval) >>> i); } else if (previous != newval) { ++cardinality; } return this; }
整体说明，当数据为空时，结构自然为空，当只有一位数据时，就非常小，当数据量越来越大，空间也跟着变大（这很正常）。只要不是超大数量级的bitmap，空间就不会很大。但如果将每个位上都存储上值，那么它占用的空间比简单的bitmap数据结构是要大些的，因为它的每个key还保存至少超过1bit的数据，甚至是原始数据，另外还有一些额外的treemap的数据结构的开销。
另外，当总体量级上千万的话，其实这种存储方案，存在大对象的问题，你可能就需要jvm参数调优来解决，或者整体换方案了。
5. 还有没有其他更好的实现？
上面两种方案，其实都不错，但好像都还有些问题存在。我们主要针对大数据量的问题，两个方案都没办法解决，那么是否就真的无解了呢？其实，办法还是有的，比如我们做一些自定义的数据分段，比如 1-100的存在bitmap1， 101-200存在bitmap2，这样就可以解决大容量的问题了。
只是这种方案需要我们小心处理自定义分段带来的技术复杂性问题，也得小心对待，尤其是重要的生产场景，必须要有大量的性能测试和准确性测试，否则挖坑给自己就不好玩了。
文章原创地址：bitmap技术解析：redis与roaringBitnap
