找回密码
 立即注册
首页 业界区 业界 假如给你1亿的Redis key,如何高效统计?

假如给你1亿的Redis key,如何高效统计?

恃液 2025-6-9 10:35:44
前言

有些小伙伴在工作中,可能遇到过这样的场景:老板突然要求统计Redis中所有key的数量,你随手执行了KEYS *命令,下一秒监控告警疯狂闪烁——整个Redis集群彻底卡死,线上服务大面积瘫痪。
今天这篇文章就跟大家一起聊聊如果给你1亿个Redis key,如何高效统计这个话题,希望对你会有所帮助。
1 为什么不建议使用KEYS命令?

Redis的单线程模型是其高性能的核心,但也是最大的软肋。
当Redis执行 KEYS * 命令时,内部的流程如下:
1.png

Redis的单线程模型是其高性能的核心,但同时也带来一个关键限制:所有命令都是串行执行的。
当我们执行 KEYS * 命令时:
Redis必须遍历整个key空间(时间复杂度O(N))
在遍历完成前,无法处理其他任何命令
对于1亿个key,即使每个key查找只需0.1微秒,总耗时也高达10秒!
致命三连击

  • 时间复杂度:1亿key需要10秒+(实测单核CPU 0.1μs/key)
  • 内存风暴:返回结果太多可能撑爆客户端内存
  • 集群失效:在Cluster模式中只能查当前节点的数据。
如果Redis一次性返回的数据太多,可能会有OOM问题:
  1. 127.0.0.1:6379> KEYS *
  2. (卡死10秒...)
  3. (error) OOM command not allowed when used memory > 'maxmemory'
复制代码
超过了最大内存。
那么,Redis中有1亿key,我们要如何统计数据呢?
2 SCAN命令

SCAN命令通过游标分批遍历,每次只返回少量key,避免阻塞。
Java版基础SCAN的代码如下:
  1. public long safeCount(Jedis jedis) {
  2.     long total = 0;
  3.     String cursor = "0";
  4.     ScanParams params = new ScanParams().count(500); // 每批500个
  5.    
  6.     do {
  7.         ScanResult<String> rs = jedis.scan(cursor, params);
  8.         cursor = rs.getCursor();
  9.         total += rs.getResult().size();
  10.     } while (!"0".equals(cursor)); // 游标0表示结束
  11.    
  12.     return total;
  13. }
复制代码
使用游标查询Redis中的数据,一次扫描500条数据。
但问题来了:1亿key需要多久?

  • 每次SCAN耗时≈3ms
  • 每次返回500key
  • 总次数=1亿/500=20万次
  • 总耗时≈20万×3ms=600秒=10分钟!
3 多线程并发SCAN方案

现代服务器都是多核CPU,单线程扫描是资源浪费。
看多线程优化方案如下:
2.png

多线程并发SCAN代码如下:
  1. public long parallelCount(JedisPool pool, int threads) throws Exception {
  2.     ExecutorService executor = Executors.newFixedThreadPool(threads);
  3.     AtomicLong total = new AtomicLong(0);
  4.    
  5.     // 生成初始游标(实际需要更智能的分段)
  6.     List<String> cursors = new ArrayList<>();
  7.     for (int i = 0; i < threads; i++) {
  8.         cursors.add(String.valueOf(i));
  9.     }
  10.     CountDownLatch latch = new CountDownLatch(threads);
  11.    
  12.     for (String cursor : cursors) {
  13.         executor.execute(() -> {
  14.             try (Jedis jedis = pool.getResource()) {
  15.                 String cur = cursor;
  16.                 do {
  17.                     ScanResult<String> rs = jedis.scan(cur, new ScanParams().count(500));
  18.                     cur = rs.getCursor();
  19.                     total.addAndGet(rs.getResult().size());
  20.                 } while (!"0".equals(cur));
  21.                 latch.countDown();
  22.             }
  23.         });
  24.     }
  25.    
  26.     latch.await();
  27.     executor.shutdown();
  28.     return total.get();
  29. }
复制代码
使用线程池、AtomicLong和CountDownLatch配合使用,实现了多线程扫描数据,最终将结果合并。
性能对比(32核CPU/1亿key):
方案线程数耗时资源占用单线程SCAN1580sCPU 5%多线程SCAN3218sCPU 800%4 分布式环境的分治策略

如果你的系统重使用了Redis Cluster集群模式,该模式会将数据分散在16384个槽(slot)中,统计就需要节点协同。
流程图如下:
3.png

每一个Redis Cluster集群中的master服务节点,都负责统计一定范围的槽(slot)中的数据,最后将数据聚合起来返回。
集群版并行统计代码如下:
  1. public long clusterCount(JedisCluster cluster) {
  2.     Map<String, JedisPool> nodes = cluster.getClusterNodes();
  3.     AtomicLong total = new AtomicLong(0);
  4.    
  5.     nodes.values().parallelStream().forEach(pool -> {
  6.         try (Jedis jedis = pool.getResource()) {
  7.             // 跳过从节点
  8.             if (jedis.info("replication").contains("role:slave")) return;
  9.             
  10.             String cursor = "0";
  11.             do {
  12.                 ScanResult<String> rs = jedis.scan(cursor, new ScanParams().count(500));
  13.                 total.addAndGet(rs.getResult().size());
  14.                 cursor = rs.getCursor();
  15.             } while (!"0".equals(cursor));
  16.         }
  17.     });
  18.    
  19.     return total.get();
  20. }
复制代码
这里使用了parallelStream,会并发统计Redis不同的master节点中的数据。
5 毫秒统计方案

方案1:使用内置计数器

如果只想统计一个数量,可以使用Redis内置计数器,瞬时但非精确。
  1. 127.0.0.1:6379> info keyspace
  2. # Keyspace
  3. db0:keys=100000000,expires=20000,avg_ttl=3600
复制代码
优点:毫秒级返回。
缺点:包含已过期未删除的key,法按模式过滤数据。
方案2:实时增量统计

实时增量统计方案精准但复杂。
基于键空间通知的实时计数器,具体代码如下:
  1. @Configuration
  2. public class KeyCounterConfig {
  3.    
  4.     @Bean
  5.     public RedisMessageListenerContainer container(RedisConnectionFactory factory) {
  6.         RedisMessageListenerContainer container = new RedisMessageListenerContainer();
  7.         container.setConnectionFactory(factory);
  8.         
  9.         container.addMessageListener((message, pattern) -> {
  10.             String event = new String(message.getBody());
  11.             if(event.startsWith("__keyevent@0__:set")) {
  12.                 redisTemplate.opsForValue().increment("total_keys", 1);
  13.             } else if(event.startsWith("__keyevent@0__:del")) {
  14.                 redisTemplate.opsForValue().decrement("total_keys", 1);
  15.             }
  16.         }, new PatternTopic("__keyevent@*"));
  17.         
  18.         return container;
  19.     }
  20. }
复制代码
使用监听器统计数量。
成本分析

  • 内存开销:额外存储计数器
  • CPU开销:增加5%-10%处理通知
  • 网络开销:集群模式下需跨节点同步
6 如何选择方案?

本文中列举出了多个统计Redis中key的方案,那么我们在实际工作中如何选择呢?
下面用一张图给大家列举了选择路线:
4.png

各方案的时间和空间复杂度如下:
方案时间复杂度空间复杂度精度KEYS命令O(n)O(n)精确SCAN遍历O(n)O(1)精确内置计数器O(1)O(1)不精确增量统计O(1)O(1)精确硬件法则:

  • CPU密集型:多线程数=CPU核心数×1.5
  • IO密集型:线程数=CPU核心数×3
  • 内存限制:控制批次大小(count参数)
常见的业务场景:

  • 电商实时大屏:增量计数器+RedisTimeSeries
  • 离线数据分析:SCAN导出到Spark
  • 安全审计:多节点并行SCAN
终极箴言
✅ 精确统计用分治
✅ 实时查询用增量
✅ 趋势分析用采样
❌ 暴力遍历是自杀
真正的高手不是能解决难题的人,而是能预见并规避难题的人
在海量数据时代,选择比努力更重要——理解数据本质,才能驾驭数据洪流。
如果这篇文章对您有所帮助,或者有所启发的话,帮忙关注一下我的同名公众号:苏三说技术,我的所有文章都会在公众号上首发,您的支持是我坚持写作最大的动力。

求一键三连:点赞、转发、在看。
关注公众号:【苏三说技术】,在公众号中回复:进大厂,可以免费获取我最近整理的10万字的面试宝典,好多小伙伴靠这个宝典拿到了多家大厂的offer。
本文收录于我的技术网站:http://www.susan.net.cn

来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
您需要登录后才可以回帖 登录 | 立即注册