移动端缓存增量更新
移动端缓存增量更新
在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中被删除的数据, 所以采用软删除的方式.
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
