在之前的文章中，我们有说过bitmap，bitmap在很多场景可以应用，比如黑白名单，快速判定，登录情况等等。总之，bitmap是以其高性能出名。其基本原理是一位存储一个标识，其他衍生知道咱就不说了，而redis就是以这种原生格式存储的。
实际上，redis是基于string的数据结构实现了bitmap的功能。
1. redis基本的bitmap操作命令最基本的，redis的bitmap有设置和读取两个值，即 setbit/getbit, 非常容易理解，即设置某个标识为1，那么取值判定的时候，就可以得到true.
这很容易理解，也是最基本的。当然，它还提供其他的一些操作：BITCOUNT 做数据量统计, BITOP 做bitmap的交并差运算... 我们也不必过多讨论它。
2. java中的原生bitmap可以说redis的bitmap实现相当之简单，所以java也就顺便实现了一个bitmap的版本：BitSet .
java中的bitmap实现，也是按位存储，但是是基于long的存储。
所以，我们可以得出一个浅显的结论，bitmap很简单，一点都不神秘。但是，大道至简，它高性能，它自然还是有好处的，咱们该用还得用。显然，java版本的bitmap虽然很很好用，但是它只是应用级别的，只能在进程内使用，有太多的其他问题没考虑，所以咱们还得要依赖于redis的bitmap.
问题：如果我有很多的数字标识想要写入redis中，然后再进行读取判定，该怎么办呢？
很简单的，我们可以一个个地调用 setbit 命令，依次写入redis中。这自然能解决问题，但是明显会带来很多的网络io。
其次，我们可以使用pipeline调用setbit进行批量写入。这当然是一种优化方案，只是仍然不是最优。
那有没有什么更好的办法呢？
3. java和redis的bitmap互操作对于批量的操作，redis是基于string实现，而java是基于bitset实现。其功能都基本差不多，判定、写入、交并差运算。那么，除了一个个按照各自语法进行添加外，有没有可能进行数据结构上的对等呢？
这个思路是很自然的，因为我们已经完全理解了各自的实现原理，为什么不呢？直接将BitSet转换为byte[]写入redis，直接将redis的bitmap当作string读出来不就可以了吗？
事实真是如此吗？实际上有点差别，原因是一个是大端存储，一个是小端存储。
比如：比如对于存储byte值: 00000010 , redis中会解释为偏移为6的值为1, 而在java中则会解析为数字2存在于bitmap中。也就是说两个的判定结果是不一样的，一个是6，一个是2。如果把java中的值给调换一下，变成 01000000，那么就和redis是一样的了。
而从redis中转变到java中，则需要将每个byte位做一逆向操作判定，具体实现如下：
经验证，将8位的byte进行位置反转，能够完美匹配两种数据结构。
如此一来，就可以轻松将整个bitmap进行初始化设置到redis中，从而在redis的bitmap中，使用 getbit 进行高效判定了。
不要害怕今日的苦，你要相信明天，更苦！
到此这篇关于redis bitmap数据结构之java对等操作的文章就介绍到这了,更多相关redis bitmap数据结构内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
