问题 Link to heading

分页是web应用中非常常见的需求，分页结果来自数据库查询，如何对这个分页结果使用Redis进行缓存呢？

下面我说说常见的几种方案，并简单说说各自优劣。

方案一 Link to heading

最简单的方式是按照sql作为缓存key(如将语句 “select * from comments limit 10 offset 0” md5)，结果作为value，如果同样的sql查询发生了，我们就可以命中缓存

pro:

• 实现简单

con:

• 缓存的数据极有可能存在冗余，如条件"limit 10 offset 0"和"limit 10 offset 5"，重复的数据存储在不同的redis key中
• 只要查询的sql变化，就不会命中缓存
• 缓存一致性很难保证，如果更新了数据或者添加了新的记录，有的缓存会失效，但很难直接知道哪个key失效了(如总共100条记录，更新了第50条记录，难以知道哪次sql查询缓存了第50条记录)，最简单的做法就是将所有的满足pattern的key清空，比如上述的key可以加上前缀 sql_cache:6f7cb75b5cfe12ca1f51647b0f440251 使用 keys sql_cache:* 找出所有的key，然后清空。

在分页这种场景下，使用最常用的缓存方式有很多问题，所以还是不考虑这种方式。

方案二 Link to heading

redis的list配合hash也可以满足分页需求，将一类记录(如一篇博文下的所有评论id)按照需要的顺序PUSH到一个key下(如blog:2)，将评论的内容放到hash中，使用LRANGE blog:2:comments 0 10，可以做到对查询直接进行分页，使用HMGET获取评论的具体内容

pro:

• 缓存的数据不存在冗余
• 支持元素更新，可以hset来更新某一个元素

con:

• 只适用于分页顺序不会发生变化的，一旦需要更改元素之间的顺序，需要重新生成整个list
• 因为只有一个key，所以在并发写的情况下，LIST中的顺序和数据库中的顺序可能不一样，不太适合频繁写的场景

方案三 Link to heading

redis的zset配合hash是第三种方案。排序权重就是zset中的score值，比如可以用时间戳作为元素的score，分页使用ZRANGEBYSCORE命令，配合上zrangebyscore支持的limit offset，取具体的数据还是使用hash。

pro: 前两条和方案二的相同，外加解决了方案二的两个缺陷。

• 支持对元素顺序的更改，如果是按照更新时间戳排序，可以使用zadd改变某个元素的score值
• 即使在并发写的情况，由于元素的顺序只和score值有关，所以并不会出现顺序不一致的情况

方案四 Link to heading

set/list、hash配合sort命令，redis提供的sort命令可以直接对hash的属性进行排序 sort命令本身也支持limit offset参数。

方案五 Link to heading

看到网上有人说可以使用redis的scan(增量遍历)来做分页，这个就不太合适了。

redis的scan Link to heading

redis的scan是一种增量遍历(incrementally iterate)，什么叫增量遍历呢? 我的理解是增量遍历是按需遍历，不是一次性把所有数据都读出来，像keys这样的命令就是全量遍历了。下面是scan文档中提供的scan命令的能力。

scan能做到: Link to heading

• 从完整遍历开始到完整遍历结束期间，一直存在于键值中的所有元素都会被返回；换而言之，如果有一个元素在整个遍历期间都存在于被遍历的数据集中，那么scan肯定会返回这个元素
• 如果在整个遍历期间，一个元素没有出现在数据集中，那么遍历返回的结果中将不包含这个元素

scan的缺陷: Link to heading

• 同一个元素可能会被返回多次，重复的元素需要应用层面处理
• 如果一个元素在scan的过程中被添加或者被删除，那么这个元素可能会被返回，可能不会，行为未定义

scan返回的元素数量 Link to heading

• 不保证每次执行都返回某个给定数量的元素，甚至可能会返回0个元素，但只要命令返回的游标不为0，那么遍历就没有结束。
• 即使提供了COUNT选项，也不保证每次返回的值是指定的COUNT数量

上面的缺陷和返回数量的不可控，注定scan是没办法在分页这个场景下使用的。