移动端系统里有用户和文章，文章可设置权限对部分用户开放。现要实现的功能是，用户浏览自己能看的最新文章，并可以上滑分页查看。

 涉及到的数据库表有：用户表TbUser、文章表TbArticle、用户可见文章表TbUserArticle。其中，TbUserArticle的结构和数据如下图，字段有：自增长主键id、用户编号uid、文章编号aid。

自增长主键和分布式增长主键如何选（题外讨论）：

TbUserArticle的主键是自增id，它有个缺陷是，当你的数据库有主从复制时，主从库的自增可能因死锁等原因导致不同步。不过，我们可以知道，这里的TbUserArticle的主键id不会用在其它表里，所以可以是自增id。不像用户表的主键，它就不能用自增id，因为用户表主键(uid)会经常出现在其它表中，当主从库自增不一致时，很多有uid字段的表数据在从库中就不正确了。用户表主键最好是用分布式增长主键算法生成的id（比如Snowflake雪花算法）。

那么你可能就要说了，TbUserArticle的主键为什么不直接用雪花算法产生，不管有没有用，先让主从库主键值一致总是有恃无恐。要知道，雪花算法产生的id一般是18位，而redis的zset的score是double类型，只能表达到16位"整数"部分(精确的说是9007199254740992=2的53次方)。因此，TbUserArticle的主键选择自增id。那么能不能产生一个16位（具体是53bit）的分布式增长id用于支持zset的score呢，当然也是可以的，因为目前的雪花算法是可以根据实际系统环境压缩bit位的，怎么压缩bit位呢，有许多方案，以后有需要我可以把它写出来。

建议：主键一般都要选自增id或分布式增长id，这种主键好处多多，它符合自增长(物理存储时都是在末尾追加数据，减少数据移动)、唯一性、长度小、查询快的特性，是聚集索引的很好选择。

zset的作法及其优点说明：

1.zset的score倒序取数可以很好的满足取最新数据的需求。

2.用TbUserArticle的文章编号当value，用自增长id当score。自增id的唯一性可很方便的取下一页数据，直接取小于上次最后一笔的score即可（用lastScore表示）。而如果用文章的时间做score，则要考虑两笔文章的时间是同分同秒问题，当lastScore落在同分同秒的两篇文章之间时，就尴尬了，虽然有解，但麻烦了一点。有时的场景你用不了自增id当score，只能用文章时间，那怎么解决呢，方案就是当是同分同秒时，再根据文章编号做比较就好了，zset的score相同时，也是再根据value排序的，这块的代码实现请看下文第五点，只需稍微改点代码即可。

3.当新增或重新添加一项时，zset也会保持score排序。而如果用的是redis的list，一般就得从db重载缓存，新增进来的数据项就算是最新的，也不敢直接添加到list第一笔，因为并发情况下，保证不了最新就是在第一笔；至于重新添加进非最新项，那更是要从db取数重新装载缓存（一般是直接删除缓存，要用的时候才装载）。

4.第一次从db加载数据到zset时，可只取前N笔到zset。因为我们移动端的数据浏览，一般是只看最新N笔，当看到昨天浏览过的数据一般就不会再往下浏览。

5.控制zset为固定长度，防止一直增长，一是减少缓存开销，二是队列长度越短操作性能越高。而且redis服务端有两个参数：zset-max-ziplist-entries(zset队列长度，默认值128)和 zset-max-ziplist-value(zset每项大小，默认值64字节)，它们的作用是，当zset长度小于128，且每个元素的大小小于64字节时，会启用ziplist(压缩双向链表)，它的内存空间可以减少8倍左右，而且操作性能也更快。如果不满足这两个条件则是普通的skiplist（跳跃表）。另，数据结构hash和list默认长度是512。如果系统有100万个用户，每个用户都有自己的队列缓存，那么使用ziplist将节省非常大的内存空间，并提升很大的性能。

注意，当从zset移除一项数据，则看场景是否需要清空队列。否则有可能添加进来了一项很旧的数据，它会跑到缓存队列最底部，如果此旧数据比db中未进队列的数据还旧，那么队列中的数据就不正确了。(此时，用户滑到缓存最后一页时，就有可能浏览到这项不正确的数据，为什么是“有可能”，因为当取到zset最后一笔，很可能不够一页(一页10笔计算的话，90%会取不够一页)，而不够一页就会从db直接取一页，从db直接取就不会有这项不正确的数据。而当zset又添加进一项新数据，末端那笔旧数据就会被T出队列（因为队列保持固定长度），zset数据又恢复正确了。不管怎样，这种问题几率虽不高，也是有解决方案，可搞个临界点处理此问题，不细说，否则又是长篇大论，最好的方案就是根据实际场景设计，比如从zset队列移除数据的情况多不多)。而如果添加到zset的数据都是最新数据，则不会有此问题。

 当用唯一主键id做score时，这可是非常有用，你可以直接根据id定位到项了，至于如何大用它，我会再出篇博客。

从redis缓存按页取数一般要考虑的点：

1.当根据cacheKey未取到数据时（可能是缓存过期了导致redis无此cacheKey数据），则触发重载数据(reload)：从db取limit N笔数据，装载到redis zset队列中，并直接取N笔的第一页数据返回；2.如果db本身也无对应数据，则添加"no_db_mark"标识到cacheKey队列中，下次请求则不会再触发db重载数据；3.当取到缓存末尾时，从db取一页数据直接返回。这种情况是很少的，要根据业务场景合理规划缓存长度。

上代码：

代码注释比较详细和有用，请直接看代码。

其中，批量添加数据到zset的函数AddItemsToZset很有用，它使用lua一次性添加多笔数据到zset（注意，使用lua时，要保证lua执行快，否则它会阻塞其它命令的执行），经测试：AddItemsToZset添加1w笔数据，只需要39ms；10w笔需要448ms。因为我们只取前N笔数据到缓存，因此一般不会添加超过1w笔。

另一个通用有用的函数是GetPageDataByLastScoreFromRedis，它支持从指定的score开始取pageSize笔数据，即支持了zset分页。它是第二页(及之后)的取数，而如果取第一页取数，则直接用redis原生函数即可redis.GetRangeWithScoresFromSortedSetDesc(cacheKey, 0, pageSize - 1);。