由于基于bitmap技术的圈群场景在Clickhouse和Doris的压测表现不是很理想，查阅了资料发现很少有文章提到bitmap在高并发人群圈选的性能问题，难道钱能解决的问题就不是问题了？由于硬件资源有限只能通过工程去弥补这个问题，于是我做了一系列的尝试和测试，有了以下的一些测试和演进方案。
测试方案
方案1：基于SQL哈希，缓存结果
这个方式能够解决同一SQL的多次查询，如果遇到真实的高并发场景，依旧还是无法真正的解决问题。
如果是模拟真实场景下的压力测试，规则中的值应该是随机生成的，这种方案不攻自破了。
方案2：使用内存表
既然频繁从硬盘I/O会占用CPU，那我直接使用内存表如何？经过测试最终测试效果不太理想，CPU依旧还是居高不下。
https://github.com/ClickHouse/ClickHouse/issues/6880 中提到
Through the result of callgrind could we see that the major overhead comes from the serialization.
通过 callgrind 的结果，我们可以看到主要的查询开销来自序列化。
基于Redis bitmaps人群圈选 v0.1
Clickhouse或者Doris如果在高并发场景下频繁的访问磁盘进行I/O操作并且又有bitmap对CPU计算的依赖，CPU基本上都会飙升，导致TPS下降，即使使用内存表还是无法直接解决CPU占用过高的问题。
由于之前做人群名单导出的时候，使用过Redis进行存储RoaringBitmap的结果，但是通过二进制的方式而非使用Redis bitmaps。
受到文章画像系统人群服务数据存储架构的演进与创新的启发，阅读了下Redis bitmaps文档才发现Redis bitmaps支持的操作，基本上可以完全支持人群圈选，如果要基于Redis bitmaps做人群圈选，需要使用Redis bitmaps方式进行存储。
参考文档：Redis bitmaps
在开始验证之前就遇到了一个痛点问题：
使用SETBIT方式保存结果过慢
由于使用SETBIT方式保存结果过慢，差点让我放弃了这个想法，最终通过参考这篇文章解决了这个问题。
redis bitmap数据结构之java对等操作
单元测试方案
CrowdSelector.java
packagecom.example.demo.redis;importcom.fasterxml.jackson.databind.JsonNode;importcom.fasterxml.jackson.databind.node.ArrayNode;importredis.clients.jedis.Jedis;importredis.clients.jedis.args.BitOP;importjava.util.*;publicclassCrowdSelector{privateJedisjedis;privateList<String>tempKeys=newArrayList<>();publicCrowdSelector(Jedisjedis){this.jedis=jedis;}publicStringevaluateRule(JsonNoderule){if(rule.has("tag")){return"tag:"+rule.get("tag").asText();}Stringop=rule.get("op").asText();ArrayNoderules=(ArrayNode)rule.get("rules");List<String>childKeys=newArrayList<>();for(inti=0;i<rules.size();i++){JsonNodechild=rules.get(i);childKeys.add(evaluateRule(child));}StringresultKey="temp:result:"+UUID.randomUUID().toString();tempKeys.add(resultKey);if("AND".equalsIgnoreCase
