标签：

移动端缓存增量更新

　　在app的时候, 为了用户体验, 一般都会引入缓存来加速app的运行. 而缓存这东西用的好则是倚天剑, 用的不好, 容易带进脏数据.

这里来说说移动端缓存增量更新的设计思想. 以通讯录为例子.

通讯录

　　场景1 : app上没有任何缓存记录. 

　　场景2 : app上存在缓存记录, 但是有一段时间没有使用改app, 不能确保缓存为最新.

　　场景3:  app正在使用缓存.

　　在上述三个场景中, 最麻烦的就是场景2, 因为可能会出现server在app不使用的时间段对通讯录中的信息进行了CRUD操作.

这里我们一步一步的分析场景2的解决方案.

updateTime And isDeleted

　　为了应付场景2, 通常采用增量更新的手段, 即每条数据都加上update_time字段, 来确认哪些数据是在app不使用的时间生成的. 从而使得app再次使用的时候, app发送通讯录最近更新时间戳给server, server能返回正确的更新包给app. 以CRUD分步说明:

　　1. 对于C(新增): 如果server向数据库中通讯录添加一条数据, 且该数据的update_time为server当前时间. 这样子,app 在同步的时候, 服务器就知道什么数据是在不使用app时间段生成的.

　　2. 对于R(读取):无任何影响

　　3. 对于U(更新): server修改通讯录条目的时候, 也修改update_time为server当前时间.  这样子,app 在同步的时候, server就知道什么数据是在不使用app时间段更新的.

　　4. 对于D(删除): server如果删除(硬删除)通讯录中的条目, 则app在同步的时候, server无法确定什么数据在不使用app时间段被删除, 如果按照update_time 比较方式处理, 会出现app有脏数据(应该被删除的数据未被删除). 为了解决该问题, 这里需要再添加一个标志isDeleted， 表示该数据是否被删除. 这样子, 在服务器删除数据的时候, 就可以更新isDeleted=true, 同时该数据的update_time为server时间. 因此, 在app同步的时候, 就可以知道在不使用app的时间段, 什么数据被删除.

　　到此, 就比较好的解决了场景2的问题, 而场景1和场景3, 可以认为是场景2的特例.

　　增量更新的基本原理就是添加update_time表示, 因为时间是有序的, 所以可以找到从固定点发生变化的数据. 如果数据会被删除, 为了避免缓存没有删除server中被删除的数据, 所以采用软删除的方式.

移动端缓存增量更新

标签：

原文地址：http://www.cnblogs.com/tickobject/p/4464271.html