既然大家有兴趣，就简单和大家说一下我的经验吧，但肯定不是完整的方案，因为每个case有很多需要注意的点和分支剧情，也要考虑到每个业务的具体场景，讲完整是不可能的。
@
zjqzxc @
TangMonk「6」这个问题可以用这个思路，比如内容是以时间排序的，那么就在每次查询的时候自动多带一个参数，也就是用户访问的时间点，并且在翻页的过程中记住这个时间点，在每页的查询语句里设置内容创建的时间要早于这个时间，这样用户不管翻多少页，由于有这个limit在，只要不删数据（即使删数据也可以用每页cache的方法，做到不影响其他页），总的结果集是固定的，所以每页的内容就是固定的。在用户重新进入第一页的时候，这个时间重新计算，这样就可以既不影响翻贴用户的阅读体验，又能够保证用户想看新内容的时候能够看的到。
当然如果你是做APP之类的瀑布流信息展现方式的话，就用Last_ID之类的方案好了，不过其实瀑布信息流也不应该叫做分页。
@
raincious 「7」和「8」这两个问题和业务场景结合的很深，但总的来说是一个平衡问题，在以下两者之间取得一个平衡：
1.以每页为cache单位，这样内容一旦增加（例如新增了一条信息在第一页），那所有的cache都应该被清空重建。这个策略在数据刷新很频繁的时候效率最低，在数据变更不频繁的时候效率最高。
2.以每条内容为cache单位，这样一旦有新数据出现，不会有任何旧的cache被重建，只要每条数据不删不改，cache是可以一直用下去的，所以在数据刷新很频繁的时候效率较高，但这样cache会分布的很散，所以在数据刷新不频繁的时候效率会较低（分支剧情：如果你可以用redis的hmget的话当我没说）。
两者你都无法接受的话，就可以考虑结合他们的优势，去做group cache，比如每页20条数据，你每10条数据做一个cache，这样悲观情况下取3次就能拿到整页的内容，乐观情况下2次即可，具体group里放数据的数量要根据你的使用场景去订。分支剧情：但如果这样做的话，就要考虑如果数据删除的话，会造成cache不对齐，那这时候你就可以考虑在每个group里前后多加x条数据，这样即使数据有改动，只要不是太频繁，就能做到现有的cache的重复利用。不过这个分支剧情貌似走的人比较少，对逻辑的严密性也比较高，在此只是提一下就不展开了。
随便写写，一定有错，求别抬杠，求别黑，谢谢。