利用MongoDb进行分页方案

为什么80%的码农都做不了架构师？>>>   

MongoDb的一个应用方案，具体场景是，框架是 Play1.x后端+Delphi前端，查询是数据过多，所以有用缓存减小网络压力，前端利用类似瀑布流的技术拉取数据，后端一次查出数据，分页返回。

这里提出两个方案，具体如下： 

一、分析 

综合上次开会，在缓存方面有两种意见，即是否将sessionid作为计算缓存hashkey的条件之一。其实这两种意见可以将此次的服务端的缓存分为两种作用。 

第一种，只做数据的反向缓冲，有减小网络压力之用。将数据从数据库取出，分批取回客户端。这种情况就是用sessionid计算hashkey的情况。如果只做反向的缓冲，则不须考虑数据的时效性。因为用缓冲与不用缓冲的区别只是在于是否一次加载完成。

另一种，就是不计算sessionid。这时将起反向缓冲与数据缓存作用，同时减小网络与数据库的。多个用户的多个请求只要请求参数一致，即hashkey一致，则取同一缓存。 

二、方案 

在后端，采用mongoDB作为缓存，将第一次请求结果缓存下来。缓存的地方在play的Controller层中，利用反射取值，这样可减少代码量。在数据返回时，带有livetime，可让客户端知道数据是否过期。 针对分析中的两种情况，提出下面两种方案： 

 A、 针对缓冲

缓存策略： 使用 url + requestParam + sessionid + timestamp 做hashkey。根据具体需求，将数据分成N段。每次请求取最前一段的数据，取完后缓存删除此段，当数据超过livetime点之后MongoDB也会自动删除此hashkey的所有数据。   

B、 针对缓冲加缓存

缓存策略： 

1、使用 url + requestParam 做hashkey 建立一个列表，将这次查询结果加入列表前面中，并设置每个数据项的成活时间点livetime与有效保鲜时间点activetime。 

2、返回hashkey、livetime和nextpage。第二次查询时可以用三个参数拉取数据。如果nextpage为空表示已经没有数据。 

3、如果第二个用户过来，同样的hashkey，会读取相应列表中最后一项的数据，计算是否在其activetime时间点前，如果在，则返回hashkey、livetime、nextpage。如果没有则重复1。

转载于:https://my.oschina.net/markho/blog/498303