技术派之基于redis实现用户活跃排行榜

排行榜是一个很常见的需求场景了，当然对应的技术选型方案也可以说非常成熟，在技术派项目中，我们也引入了一个用户活跃度的排行榜，主要是基于redis的zset数据结构来实现，给大家实例演示一下，如何实现一个生产可用的排行榜

方案设计

在具体的代码介绍之前，先来了解一下业务场景

1. 场景说明

技术派中，提供了一个用户的活跃排行榜，当然作为一个博客社区，更应该实现的是作者排行榜；出于让大家更有参与感的目的，我们以用户活跃度来设计一个排行榜，区分日/月两个榜单

用户活跃度计算方式：

用户每访问一个新的页面 +1分
对于一篇文章，点赞、收藏 +2分；取消点赞、取消收藏，将之前的活跃分收回
文章评论 +3分
发布一篇审核通过的文章 +10分

榜单：

展示活跃度最高的前三十名用户

实际的榜单效果如下（可以在首页活跃排行榜侧边栏点击进入）

2. 方案设计

排行榜的业务属性比较清晰简单，对应的数据结构也可以很容易设计出来，核心的信息如下

存储单元

表示排行榜中每一位上应该持有的信息如下

// 用来表明具体的用户
long userId;
// 用户在排行榜上的排名
long rank;
// 用户的历史最高积分，也就是排行榜上的积分
long score;

数据结构

排行榜，一般而言都是连续的，借此我们可以联想到一个合适的数据结构LinkedList，好处在于排名变动时，不需要数组的拷贝

上图演示，当一个用户活跃度改变时，需要向前遍历找到合适的位置，插入并获取新的排名, 在更新和插入时，相比较于ArrayList要好很多，但依然有以下几个缺陷

问题1：用户如何获取自己的排名？

使用LinkedList在更新插入和删除的带来优势之外，在随机获取元素的支持会差一点，最差的情况就是从头到尾进行扫描

问题2：并发支持的问题？

当有多个用户同时更新score时，并发的更新排名问题就比较突出了，当然可以使用jdk中类似写时拷贝数组的方案

上面是我们自己来实现这个数据结构时，会遇到的一些问题，当然我们的主题是借助redis来实现排行榜，下面则来看下，利用redis可以怎么简单的支持我们的需求场景

3. redis使用方案

这里主要使用的是redis的ZSET数据结构，带权重的集合，下面分析一下可能性

set: 集合确保里面元素的唯一性
权重：这个可以看做我们的score，这样每个元素都有一个score；
zset：根据score进行排序的集合

从zset的特性来看，我们每个用户的积分，丢到zset中，就是一个带权重的元素，而且是已经排好序的了，只需要获取元素对应的index，就是我们预期的排名

排行榜实现

接下来我们看一下技术派中的活跃排汗榜单是如何实现的

核心包路径：com.github.pa...

15人已点赞

15 条评论

cht 2026年09月04日 23:44

@派聪明那有个问题，通过这些用户行为缓存到redis中，计算出当日的热度榜单，这些用户行为也要持久化到事实数据库中？当日的热度榜单过期会删除吗？这个项目的文章热门榜单是怎么实现的？

回复1 取消回复

派聪明 2026年09月04日 23:45

# 关于Redis排行榜的持久化与热门榜单问题##1. 用户行为是否持久化到数据库？ **不需要全量持久化。** 在该方案中： - 用户行为明细存在Redis的Hash中（key: `activity_rank_{userId}_{yyyyMMdd}`），保留31天，主要用于**幂等判定**和用户查询自己最近31天的活跃情况-排行榜本身存在Redis的ZSET中，日榜存31天、月榜存1年- 用户的核心行为（点赞、收藏、评论、发文等）本身就会落库到业务表中（如点赞表、评论表、文章表），Redis里只是**积分维度的冗余记录**，并非数据源头。所以不存在“必须把活跃记录写回数据库”的需求——榜单是时效性数据，过期即失效，这是可接受的业务设计##2. 当日热度榜单过期会删除吗？ **会。**代码中通过 `RedisClient.expire()` 设置了过期时间： - 日榜：31天（`31 * ONE_DAY_SECONDS`） - 月榜：1年（`12 * ONE_MONTH_SECONDS`） - 用户操作记录：31天Redis的过期删除策略（惰性删除+定期删除）会自动清理这些key，无需人工干预。 ##3. 文章热门榜单如何实现？技术派中的**文章热度/排行榜与用户活跃榜是两套机制**： **用户活跃榜**：如上所述，基于行为事件（Event/Listener监听点赞、评论、发文等 +拦截器捕获浏览行为）→计算活跃分 → Redis ZSET实时累加。 **文章热门榜**：项目中文章侧的排序更多依赖**数据库统计字段**（阅读数、点赞数、评论数、收藏数等存在文章表中），按时间范围（日/周/月）结合这些统计指标排序查询，配合缓存来减轻DB压力。也就是说，文章榜单是以**落库的计数数据**为基础，而用户活跃榜是以**Redis实时积分**为基础，两者设计思路不同： - 文章数据需要长期留存 →落库- 用户活跃度只需短期时效 → Redis + 过期这种差异体现了“按数据的生命周期和一致性要求选择存储方案”的设计原则。

cht 2026年09月04日 23:41

那有个问题，通过这些用户行为缓存到redis中，计算出当日的热度榜单，这些用户行为也要持久化到事实数据库中？当日的热度榜单过期会删除吗？

cyx 2026年03月19日 17:24

引用原文：进行完

@聪明派

逸风 2026年03月09日 23:14

@派聪明技术派中，你用Kafka处理用户点赞/评论行为的异步处理（保证“精确一次”语义）。如果消费端处理失败（比如写入MySQL报错），Kafka如何实现消息的重试或死信队列？你有没有实际遇到过消息堆积或重复消费的场景？如何排查？

派聪明 2026年03月09日 23:14

在技术派中，Kafka处理用户点赞/评论行为采用"精确一次"语义主要通过以下方式实现： 1. 精确一次语义实现： - 使用幂等性生产者(idempotent producer)避免消息重复发送 - 消费端结合事务性消费，确保消息处理与数据库更新的原子性 - 通过消费组offset管理，确保消息被精确处理一次 2. 处理失败机制： - 重试策略：配置max.poll.interval.ms和max.poll.records，控制重试频率 - 死信队列：将多次重试失败的消息发送至专门主题，后续人工干预 - 实现自定义错误处理器，区分可恢复与不可恢复异常 3. 消息堆积排查： - 监控consumer lag，识别处理瓶颈 - 检查分区分配是否均衡，避免某些分区过载 - 分析消费者线程池配置，适当提高并发度 4. 重复消费处理： - 实现幂等性消费者，基于业务主键或版本号去重 - 使用Kafka事务API，确保offset提交与业务操作原子性 - 记录已处理消息ID，实现本地幂等校验在实际项目中，我曾遇到过因数据库连接池耗尽导致的消息堆积，通过增加连接池大小和优化SQL语句解决。对于重复消费，通过引入分布式锁和业务幂等设计有效避免了数据不一致问题。

逸风 2026年03月09日 21:57

@派聪明如果系统需要统计“近24小时内最活跃的10个用户”，且要求实时更新，你会选择哪种Redis数据结构（如ZSET/Hash/List）？具体实现逻辑和性能考量是什么？

派聪明 2026年03月09日 21:58

对于统计"近24小时内最活跃的10个用户"且要求实时更新的需求，我会选择Redis的ZSET（有序集合）数据结构。实现逻辑： 1. 使用ZSET存储用户活跃数据，用户ID作为member，活跃度分数作为score 2. 设置两个ZSET键：一个用于日排行榜（24小时有效期），一个用于月排行榜 3. 当用户有活跃行为时（如访问页面、点赞、评论等），使用ZINCRBY命令增加对应用户的分数 4. 定期清理过期数据（日榜24小时后自动过期） 5. 使用ZREVRANGEWithScores命令获取分数最高的前10个用户及其活跃度性能考量： 1. ZSET的插入、更新和获取top N操作时间复杂度均为O(log N)，性能优异 2. 内存存储特性保证读写速度极快，满足实时更新需求 3. 使用ZINCRBY原子操作确保数据一致性，避免并发问题 4. 通过设置合理的过期时间自动清理历史数据，控制内存使用 5. 相比Hash和List，ZSET天生支持排序和范围查询，更适合排行榜场景这种方案已在技术派项目中验证可行，能够高效处理高并发下的用户活跃度统计和排名需求。

单身的蜜蜂 2026年02月01日 00:14

引用原文：没有做并发，幂等无法100%生效，依然可能存在重复添加/扣减活跃度的情况

什么原因导致幂等？什么原因导致并发？

单身的蜜蜂 2026年02月01日 00:16

@派聪明

1210fei 2026年01月29日 15:19

111111