Redis用lrange做分页，感觉挺方便但也有点小坑要注意

Redis的list结构配合lrange命令来实现分页，是很多开发者会自然想到的一种方案，因为它看起来非常直观和简单，它的基本思路就是把需要分页的数据，按顺序存放到一个list中，然后通过lrange命令，指定起始索引和结束索引来获取一页的数据，这听起来很完美，但实际用起来，确实是“挺方便但也有点小坑”。

先说方便的地方，这也是为什么大家喜欢用它。

最直接的方便就是实现简单，你不需要像用关系型数据库那样写复杂的SQL语句，计算offset和limit，在Redis里，你只需要一个命令：LRANGE key start stop，你的key是article:list，里面存了一堆文章ID，要取第一页（每页10条），就是LRANGE article:list 0 9；取第二页就是LRANGE article:list 10 19，代码写起来非常干净利落,几乎没有学习成本。

性能通常很高，Redis基于内存操作，list底层是快速链表（当list元素较多时），通过索引定位到范围的起始点后，遍历获取指定数量的元素是非常快的，尤其是在数据量不是特别巨大的情况下，这种分页方式的响应速度非常可观，能有效减轻数据库的压力，感觉上就像是从一个很长的队列里，直接切出一段给你,非常高效。

正是这种“简单”和“高效”的表象下，藏着几个需要特别注意的“小坑”，如果忽视它们,可能会在项目后期带来麻烦。

第一个大坑，可能是最容易被忽略的：列表长度的变化带来的数据重复或丢失。

想象一个动态性很强的场景，比如一个新闻列表，随时都有新文章发布,你使用lrange做分页：

1. 用户A访问第一页，拿到了10条最新的新闻,ID是100到91。
2. 就在这时，系统发布了一条新新闻，ID为101，它被LPUSH到了列表的最前面，整个列表向前“挪动”了一位。
3. 用户A接着点击第二页，此时命令是LRANGE key 10 19。
4. 问题来了：由于之前新数据的插入，原来在第一页末尾的ID91，现在被挤到了第11位（索引10），用户A在第二页的第一条，又看到了ID91这条新闻，这就发生了数据重复。

反过来，如果列表中的元素被删除了（比如某些内容下架），会导致列表长度变短，后续分页时可能会丢失数据或者拿到空数据，这个问题的根源在于，lrange的索引是基于当前列表的实时状态计算的，它不具备数据库事务中“快照隔离”那样的能力，无法保证两次分页查询间数据视图的一致性,这对于需要严格数据连续性的场景是致命的。

第二个坑，是关于性能的“反转”。

前面说性能高，那是在数据量适中的前提下，Redis的list底层实现，在元素较少时是ziplist（压缩列表），存取效率很高，但当元素数量超过配置阈值时，会转为linkedlist（双向链表），双向链表的特点是，随机定位索引位置的效率是O(n)。

这意味着什么？当你使用LRANGE key 1000000 1000009去取第10万页的数据时，Redis需要从链表头部开始，一步步遍历100万次，才能找到第1000000个元素的位置，然后再往后取10个，这个操作的成本非常高，几乎等同于一次全表扫描！这和你取第一页LRANGE key 0 9的速度是天壤之别。lrange分页只适合“浅分页”，即用户只会往前翻几十上百页的场景，一旦需要深度分页，性能会急剧下降，甚至成为系统瓶颈。

第三个坑，是功能上的局限。

关系型数据库的分页往往伴随着复杂的查询条件（where）、排序（order by）和关联查询（join），而Redis的list本身只是一个有序的序列，它不具备复杂的查询能力，如果你需要根据分类、标签、时间范围等动态条件来分页，单纯靠一个list是做不到的，你可能需要维护多个list（比如按不同分类），或者结合Redis的Sorted Set（有序集合）等其他数据结构,这无疑增加了设计和维护的复杂度。

总结一下

回到开头那句话，用Redis的lrange分页，确实挺方便，但小坑也不少，它就像一把瑞士军刀里的小刀，切水果、开快递很顺手,但你绝不能指望它去砍大树。

在选择这种方案时,你必须心里有数：

• 适用场景：数据相对静态,或者对极短时间内的数据一致性要求不高。
• 分页深度：用户通常只会浏览前几页,几乎没有深度翻页的需求。
• 查询条件：分页逻辑非常简单,不需要复杂的过滤和排序。

如果你的业务场景不符合以上几点，那么可能就需要考虑其他方案了，比如直接使用数据库的分页（尽管有offset深度分页问题，但可通过其他如“游标”方式优化），或者使用Elasticsearch这类专门的搜索引擎来处理复杂查询和分页，简单有简单的代价，在选择技术方案时,清晰地认识到其优缺点至关重要。