背景
业务方需要实现一个曝光去重的功能，决定采用布隆过滤器，又因为是多节点应用，为保证数据一致性，通过Redis实现。本文记录下开发时的思路，以及优化过程。
初次实现
Redis4.0以上对布隆进行了插件支持，可以用特定的指令进行元素添加和判重，但考虑到不是所有环境的Redis都支持插件安装，以及违背死磕精神，决定自行实现。
第一版的实现使用Guava的BloomFilter进行hash操作，redis通过String类型存放bit数组。
估算空间
在实现业务前，估算大致需要插入的元素以及能接受的误判率，来计算预计需要的空间（引用Guava中的方法）。
/**
* @param n 预计插入的元素
* @param p 误判率（0 < p < 1）
*/
long optimalNumOfBits(long n, double p) {
if (p == 0) {
p = Double.MIN_VALUE;
}
return (long) (-n * Math.log(p) / (Math.log(2) * Math.log(2)));
}
例如我们预计插入500个元素，误判率取千分之三，输入到函数中得到 6045 ，即6045 bit = 755.625 B = 0.73 KB ， 当然在Redis中数据结构还有额外存储，所以结果仅供参考。
Setbit & Getbit
布隆的Hash算法有很多，例如MURMUR128_MITZ_32，算法实现此处不赘述，可以google一下，经过数次hash后得到下标数组，储存着元素映射到数组的下标。
判重：
for (int i : offset) {
if (!redisTemplate.opsForValue().getBit(key, i)){
return false;
}
}
return true;
添加：
for (int i : offset) {
redisTemplate.opsForValue().setBit(key, i, true);
}
至此，布隆就实现完毕了。
Pipeline
虽然getbit和setbit都是O(1)操作，然而每个元素的 添加/判重 都需要进行数次setbit，其次数与插入量和布隆过滤器长度相关：
/**
* @param n 预估插入量
* @param m 布隆过滤器长度
*/
int optimalNumOfHashFunctions(long n, long m) {
return Math.max(1, (int) Math.round((double) m / n * Math.log(2)));
}
取上文中的6045bit以及500个预估插入，进行代入得到操作次数 = 5。
每 添加/判重 1个元素就需要进行 5 次bit操作，这期间建立了5次TCP连接，显然对通道造成浪费，我们用redis pipeline优化一下～
添加：
redisTemplate.executePipelined((RedisCallback) connection -> {
for (int i : offset) {
connection.setBit(redisTemplate.getKeySerializer().serialize(key), i, true);
}
return null;
});
判重：
List<Boolean> list = redisTemplate.executePipelined((RedisCallback) connection -> {
for (int i : offset) {
connection.getBit(redisTemplate.getKeySerializer().serialize(key), i);
}
return null;
});
List<List<Boolean>> valuePairs = Lists.partition(list, numHashFunctions);
Map<R, Boolean> result = Maps.newHashMapWithExpectedSize(values.size());
for (int i = 0; i < values.size(); i++) {
R v = values.get(i);
result.put(v, valuePairs.get(i).stream().reduce(true, Boolean::logicalAnd));
}
return result;
同时笔者将方法改造成可批量判重元素的形式，将结果集按操作次数拆分成数个子集（pipeline返回的结果集是有序的，这点很重要），每个子集各自累加，最终得到一张[元素:是否存在]的Map。
实测pipeline化后速度提升了不少，不过还没完。
bitfield
bit操作快，但请求次数也多，在上述pipeline上线后，redis在业务高峰时qps有明显的上升。
set/get bit每次只能操作单个bit位。是否可以一条命令操作完成多个bit位的操作？
BITFIELD key [GET type offset] [SET type offset value] [INCRBY type offset increment] [OVERFLOW WRAP|SAT|FAIL]
BITFIELD 命令可以将一个 Redis 字符串看作是一个由二进制位组成的数组， 并对这个数组中任意偏移进行访问。
BITFIELD可以指定多个子命令，有 get/set/incr 三种操作类型，可以在一条命令中完成复合操作，并返回结果集，当然命令的执行速度取决于由多少个子命令组成。
Redis官方解释开发bitfield的动机是为了方便操作bitmap，但不妨碍我们在布隆过滤器中使用它。
添加：
BitFieldSubCommands commands = BitFieldSubCommands.create();
for (int i : offset) {
commands.set(BitFieldSubCommands.BitFieldType.unsigned(1))
.valueAt(i)
.to(1);
}
redisTemplate.opsForValue().bitField(key, commands);
注意在定义子命令时要声明操作数的长度，指定为无符号1位即可。
判重：
BitFieldSubCommands commands = BitFieldSubCommands.create();
for (int i : offset) {
commands.get(BitFieldSubCommands.BitFieldType.unsigned(1))
.valueAt(i);
}
List<Long> result = redisTemplate.opsForValue().bitField(key, commands);
判重时对结果集的处理同pipeline。
使用bitfield后，经测试高qps现象有明显改善，但对cpu改善不大，因为redis内部执行的bit操作并没有减少。