app后端设计(10)--数据增量更新

    在新浪微博的app中，从别的页面进入主页，在没有网络的情况下，首页中的已经收到的微博还是能显示的，这显然是把相关的数据存储在app本地。

    使用数据的app本地存储，能减少网络的流量，同时极大提高了用户的体验（想想，很多数据都能在app本地获取，显示的速度当然快）。使用了本地存储后，需要考虑的是数据的增量更新方案。

    什么是数据的增量更新？假设，用户A的首页在数据表中是有40条数据，id1-40，app每次获取10条数据。第一次运行，app从数据表获取了id1-10条数据同时存储在本地。假设用户离开了这个页面再回到首页，这时app需要再次从数据库中获取数据，由于之前已经有10条数据（id1-10）存储在app本地了，那么现在需要从数据库中获取的10条数据就是从剩余的30条中数据获取（id11-40）后并保存在app本地。这个就是增量更新的典型例子。

    增量更新的原理是在数据库中，每条数据都必须有update_time这个值，记录数据最后更新的时间，当app从服务器获取了一次数据后（返回的数据必须按时间排序，update_time最近的在第一条），记录下第一条数据的update_time，当再次获取数据就只需要获取上个时间点到访问服务器这刻为止所更新的数据即可。

 

   因为分页机制的存在，这个算法实现起来是挺多需要注意的地方，下面我举一个简化的例子详细说明：

 

一些假设：

1. app每次请求都带4个参数

http://test/api/timeline?count=3&page=1&since=1100&max=1200

count: 每页的显示条数（默认为3）

page: 当前页码（默认为1）

since: 时间戳，若指定此参数，则返回时间戳大于等于since的结果（应该是上次获取的最新数据的update_time）

max: 时间戳，若指定此参数，则返回时间戳少于等于max的结果（应该是发送时的时间）

 

在sql的查询时，使用条件 since<=update_time<= max

 

2. api 返回的数据包含

{

   "size": 10,   //实际返回的数据量（因为分页获取的缘故，所以经常少于total值）

   "total": 284,  //应该返回的总数据量

   "page": 1,

   "count": 3,

   "max": 0, //max为获取的最后一条数据的update_time

   "since": 0

},

{ //返回的数据实体

         data:.......

}

3. app存储的本地数据中的update_time是指服务器中的这条数据的更新时间，不是指app中这条数据的更新时间。

 

现在开始讨论：

（1）当app安装完毕后还没启动，服务器的数据表中的数据为3条，app存储的本地数据为空

 

服务器的数据表的数据

id