用Redis搞定海量文章浏览量排序，速度快还省资源，真香！

（引用来源：程序员小灰《用Redis搞定海量文章浏览量排序》核心思想，并结合常见实践）

“用Redis搞定海量文章浏览量排序，速度快还省资源，真香！”这个说法，确实点出了Redis在处理这类热门问题上的巨大优势，想象一下，你运营着一个新闻网站或者博客平台，每天有成千上万篇文章被阅读，老板让你做一个“热门文章排行榜”，要实时更新，展示过去24小时内阅读量最高的100篇文章，如果直接用数据库来做，比如MySQL，每次有人点击文章，你都要去数据库里给对应文章的“view_count”字段加上1，然后排行榜的查询语句，得是类似“SELECT * FROM articles WHERE publish_time > 昨天此时 ORDER BY view_count DESC LIMIT 100”这样的，文章量少的时候还行，一旦量大并发高，每次点击都去写数据库，这个数据库的压力就太大了，而且那个排序查询，随着数据量增大，会越来越慢，简直就是数据库的噩梦。

这时候,Redis的优势就体现出来了，它就像一个超级快的临时工作台，所有数据都放在内存里，读写速度极快，特别适合这种需要频繁更新和快速查询的场景，具体怎么用它来“真香”呢？最经典的方法就是使用有序集合（Sorted Set） 这个数据结构。

你可以把有序集合想象成一个排行榜本子,每一个元素（在这里就是每篇文章的ID）都对应一个分数（Score），这个分数就是文章的浏览量，Redis会自动根据这个分数从大到小给我们排好序。

具体操作分两步走：

第一步：记录每一次点击

每当有用户点击阅读一篇文章时,我们不去折腾数据库，而是直接给Redis下命令，比如文章ID是1001，我们就执行一个命令：ZINCRBY hot_article:20240527 1 1001，这个命令的意思是，在名为“hot_article:20240527”的这个有序集合里，给文章ID为1001的元素的分数，增加1，ZINCRBY这个命令非常高效，它既能增加分数，又能自动维护好排序，一步到位，这里的key包含了日期“20240527”，这是因为我们的排行榜通常是有时间范围的，比如日榜、周榜，按天创建一个key，管理起来很方便。

第二步：获取排行榜

当我们需要展示热门文章排行榜时,比如要前100名，只需要一个命令：ZREVRANGE hot_article:20240527 0 99 WITHSCORES，这个命令会立刻返回当前key里，分数从高到低（ZREVRANGE就是倒序范围查询）排名第0到第99的元素（也就是前100名），并且把文章ID和对应的浏览量（分数）都一起返回，这个操作的时间复杂度很低，几乎可以认为是瞬间完成的，因为Redis直接读取的就是已经排好序的数据结构。

你看,整个过程，记录点击和查询排行榜，都是和Redis这个内存高手打交道，又快又轻松，数据库的压力一下子就降下来了，这才是“省资源”的关键。

聪明的你可能会发现一个问题：我们只把文章ID和浏览量存在了Redis里，但排行榜展示给用户看，需要文章的标题、作者、摘要等信息啊！这些信息还在数据库里，这该怎么办？这就要用到另一个常见的技巧了。

当我们通过ZREVRANGE拿到前100名的文章ID列表后,我们不能一个个地去数据库里用100条SQL查询（那又慢了），而是应该用一条SQL语句，比如SELECT id, title, author FROM articles WHERE id IN (1001, 1002, 1003, ...)，一次性把这100篇文章的详细信息从数据库里查出来，数据库处理这种按主键ID的批量查询，还是非常快的，我们在程序里，把Redis返回的排行榜顺序和数据库返回的详细信息做一个合并，最终组装成前端需要的数据，这个过程，通常被称为“缓存+数据库”的混合模式。

还有一个问题,就是数据持久化，Redis的数据主要在内存里，如果服务器重启，内存里的日榜数据不就丢了吗？是的，所以对于这种“24小时热榜”需求，数据丢失一点其实问题不大，因为第二天我们会用新的key（比如hot_article:20240528）重新开始计数，我们关心的是最近的热度，昨天的数据丢了影响不大，如果确实需要持久化，Redis本身也提供了持久化机制，但针对这个场景，通常不是大问题。

更进一步,如果我们想做“周榜”或者“月榜”怎么办？一个简单的办法是，我们每天凌晨的时候，不是丢弃前一天的key，而是执行一个命令，把过去七天（或指定天数）的所有日榜key，通过ZUNIONSTORE命令合并成一个新的周榜有序集合，在合并时，我们可以选择把各天的分数相加，这样就得出了周内的总热度，这个合并操作可以放在服务器压力小的凌晨执行，计算一次，全天使用，非常高效。

用Redis做海量文章浏览量排序的“真香”之处就在于：用有序集合这个数据结构，将频繁的计数更新和排序查询这种重压力操作，从速度较慢的数据库剥离出来，交给速度极快的Redis内存数据库处理，数据库则退居二线，只负责存储文章的核心内容（标题、正文等）和提供批量查询，这样各司其职，扬长避短，既保证了排行榜的实时性，又极大地减轻了系统整体负担，应对高并发场景游刃有余，这也就是为什么很多大型内容平台都在使用类似方案的原因。