重构产品分页存储体系，用Redis来优化数据处理和查询效率实践分享

前段时间，我们团队遇到了一个头疼的问题，我们的产品列表页面，就是用户进来APP第一眼看到的那个页面，加载速度变得越来越慢，尤其是当用户使用筛选条件，比如按价格排序、按品牌过滤，或者翻到很后面几页的时候，等待时间长得让人难以接受，技术团队开会分析后发现,问题的根子出在数据库上。

每次用户打开产品或进行翻页、筛选，系统都要直接去查询那个庞大的主数据库，你可以把主数据库想象成一个巨大的、整理得井井有条的仓库，但每次取货都要跑进仓库最深处，弯腰查找，非常耗时，特别是像“查一下最贵的100个产品里的第51到60个”这种请求，数据库需要进行复杂的计算（这种操作通常被称为OFFSET LIMIT查询），数据量越大，速度就越慢，这直接导致了用户等待时间过长,体验很差。

我们决定对这套分页存储体系进行一次彻底的重构，核心思路就是引入Redis来帮忙，Redis是一种速度极快的内存数据库，它把数据存放在服务器的内存里，读写速度比存在硬盘上的传统数据库快好几个数量级，我们的目标是把最常用、最耗时的查询结果提前算好，放在Redis这个“高速缓存区”里，下次用户再有同样的请求，就直接从缓存里拿结果，瞬间返回，再也不需要每次都去折腾那个“大仓库”了。

具体是怎么做的呢？我们并没有简单地把所有产品数据都扔进Redis,而是设计了一套组合拳。

对于最核心的“第一页”数据，我们给了它最高级别的待遇，我们设置了一个专门的Redis键，比如叫做products:list:first_page，每当后台管理员对产品信息有更新，比如上架新品或者调整价格，系统除了更新主数据库，还会立刻重新计算当前最新的第一页产品列表，并把结果完整地存到这个键里面，这样，绝大多数用户进入APP时，请求根本到不了主数据库，直接从Redis就能拿到热乎乎的第一页数据,速度提升了几十倍。

对付更复杂的筛选和排序分页，我们用了Redis的另一个强大功能——有序集合，举个例子，用户想按价格从高到低看产品，我们为“按价格排序”这个视图创建一个有序集合，集合的键是products:sort_by_price，集合里的每个成员就是产品的ID，而分数就是这个产品的价格，当产品价格变动时,我们同步更新这个集合。

当用户请求“按价格排序的第3页”时（假设一页10个产品），系统不再去主数据库做复杂的排序和分页计算，而是直接向Redis的这个有序集合发指令，Redis可以飞快地根据分数（价格）排序，然后精准地计算出排名第21到30的产品ID是哪些（因为第1页是1-10，第2页是11-20，以此类推），这个过程是在内存中完成的，速度极快，拿到这一页的产品ID列表后，系统再去用这些ID到主数据库里批量查询这些产品的详细信息（如名称、图片等），虽然这一步还是要查主数据库，但因为是按主键ID批量查询，速度也非常快,远胜于之前那种复杂的条件查询。

事情没有一劳永逸，我们还必须考虑缓存数据如何保持新鲜，如果后台修改了产品价格，但Redis里的有序集合没有更新，用户就会看到旧的价格信息，这就出现了数据不一致，为此，我们建立了一套缓存更新机制，只要产品数据发生变更，系统就会自动触发相关Redis缓存的更新或清除，比如价格变了，就更新products:sort_by_price这个有序集合；有新品上架或旧品下架，就可能需要清除products:list:first_page这个缓存,让它下次被请求时重新从数据库加载最新数据。

我们还给这些缓存数据设置了合理的过期时间，即使没有数据更新，第一页的缓存可能在24小时后自动失效，然后重新加载,这样可以防止出现极端的脏数据情况。

经过这一番重构，效果是立竿见影的，产品列表页的加载时间和筛选翻页的响应速度得到了巨大的提升，用户的抱怨也大大减少，这次实践让我们深刻体会到，合理利用Redis这样的高速缓存，将计算好的结果前置，是优化系统性能、提升用户体验非常有效的手段，它就像一个设置在数据库前方的“高速服务区”，把最繁忙、最重复的查询任务揽下来,从而保障了整个系统的流畅与稳定。