亿级Redis Keys统计难题：从Set到Bitmap的四种高性能方案解析

在实际业务中，你是否大规模地使用过 Redis？还是仅仅把它当作一个简单的缓存工具？当你面对上亿级别的数据时，很多基础操作都会带来新的挑战。

在Redis中，集合（Set）无疑是使用最广泛的数据结构之一。它对应着很多现实场景：比如，签到系统里一天对应的一系列用户ID；电商系统中，一个商品下的大量评论；或者社交应用中，某个用户的好友列表。这些场景的核心都是“一个Key对应一系列数据”。

然而，存储数据往往只是第一步，我们真正的目的是为了统计。社交APP需要计算双方的共同好友；电商系统要筛选出最新的评论；签到系统得统计连续一个月都签到的用户数量。

大型互联网应用的数据量往往是惊人的，动辄百万、千万，甚至上亿。面对如此庞大的keys集合，如何高效地进行统计就成为一个必须解决的工程问题。答案并非一成不变，关键在于针对不同场景选择最合适的集合类型与处理方案。

聚合统计的挑战与瓶颈

聚合统计指的是对多个集合元素进行交、并、差等运算。当你需要进行这类操作时，Redis的Set似乎是个不错的选择，因为它天然去重并提供了相应的API。

交集运算
以统计共同好友为例，我们可以用用户ID作为Key，其好友ID列表作为Value。Redis提供了SINTER命令来计算多个集合的交集：

SINTER key1 key2 key3

但问题来了，当你有上亿个keys时，直接使用SINTER会怎样？答案是：它会变得极慢。因为SINTER需要遍历所有指定的集合来计算交集，其时间复杂度在数据量巨大时是难以接受的，在千万乃至亿级数据场景下，这种操作会直接导致服务超时。

并集与差集运算
类似地，统计多个集合的所有元素（并集）可以使用SUNION命令，而计算一个集合有、另一个集合没有的元素（差集）则用SDIFF命令。

SUNION key1 key2 key3
SDIFF key1 key2

它们同样面临性能瓶颈。SUNION会在内存中合并并去重所有数据，对内存是巨大考验；SDIFF在数据量大的情况下，性能也会急剧下降。

Set还是Hash？这是个问题

很多人习惯性地认为“集合就用Set”，但在生产环境中，我们更应关注业务场景的具体需求。

• Set的适用场景：数据无需排序、需要严格去重，并且经常进行集合运算（交、并、差）。
• Hash的适用场景：当你的需求包括按时间排序、分页查询，或者需要快速判断某个特定元素是否存在时，Hash可能更合适。Hash可以存储更多元数据（如时间戳），且HGET操作是O(1)时间复杂度，适合精确查询。当然，它的缺点是无法直接进行集合运算，需要额外实现去重逻辑。

破解亿级Keys统计的四种实战方案

面对一亿个keys，没有一个放之四海而皆准的“银弹”，只有最适合当前业务的最优解。以下是几种经过验证的高性能方案：

方案一：分片（Sharding）
将庞大的集合拆分成多个更小的、可控的子集合。例如，按用户ID进行分片：

user_001_friends:0
user_001_friends:1
user_001_friends:2
...

在进行集合运算时，可以分批处理这些分片，从而避免单次操作数据量过大的问题。

方案二：异步计算与缓存
绝对不要在实时的用户请求链路中执行耗时的集合运算。正确的做法是将计算过程异步化，并将结果缓存起来。例如，共同好友关系可以每天在后台计算一次，然后将结果存入Redis并设置24小时的过期时间。后续请求直接读取缓存，性能得到极大保障。

方案三：使用Bitmap（位图）
如果你的数据状态是二值的（例如签到：已签到/未签到），那么Bitmap是节省内存的神器。存储1亿用户的签到状态，使用Set可能需要数GB内存，而使用Bitmap仅需约12.5MB。它通过位运算来高效统计，非常适用于大规模布尔值统计场景。

方案四：采用HyperLogLog
如果你只需要统计不重复元素的个数（即基数），而不关心具体是哪些元素，那么HyperLogLog是最佳选择。它的优势极其明显：内存占用极小（约12KB），能够以可控的误差率（约0.81%）统计数以亿计的基数。当然，它无法获取具体元素内容，这需要根据业务容忍度来判断。

实战经验分享

我们曾在某个社交应用的共同好友功能中踩过坑。最初直接使用SINTER命令，在用户量达到千万级后，接口响应时间从几十毫秒飙升到数秒，频繁超时。

后续的优化方案是：

1. 首先进行分片，将单个用户的好友列表拆分存储。
2. 改为异步任务计算用户间的共同好友，并将结果持久化到缓存中。
3. 前端请求时，优先读取缓存结果，仅对缓存未命中的情况触发异步计算。
   经过这套组合优化，该功能的响应时间最终稳定在了100毫秒以内。

总结与思考

Redis很强大，但它并非万能。面对海量数据，我们需要思考的不是“Redis能不能做”，而是“怎么做才最合适、最经济、最高效”。

在选择方案前，务必先厘清以下几个问题：你的数据量究竟有多大？主要的查询模式是怎样的（精确查询、范围统计还是聚合运算）？对实时性的要求有多高？以及，你的内存预算是多少？回答清楚这些问题，才能找到真正适合你业务的技术方案。更多关于高并发架构设计的讨论，欢迎来云栈社区与我们交流。