KO增量更新
在app的时候, 为了用户体验, 一般都会引入缓存来加速app的运行. 而缓存这东西用的好则是倚天剑, 用的不好, 容易带进脏数据.
这里来爆料[[在移动环境中缓存增量更新设计思想]]
通讯录
场景1 : app上没有任何缓存记录.
场景2 : app上存在缓存记录, 但是有一段时间没有使用改app, 不能确保缓存为最新.
场景3: app正在使用缓存.
在上述三个场景中, 最麻烦的就是 场景2, 因为可能会出现 server在app不使用的时间段对通讯录中的信息进行了CRUD操作 .
+10多兰( ChangeLog机制)
在增量更新中, 最基本的方式, 是采用ChangeLog机制, 大家可以回想一下SVN的版本机制, 它把对 代码仓库的每一个操作都记录下来 . 在各个不同Rev同步代码时候, 直接拿着Rev 去获得变化的版本序列, 然后merge 到本地代码即可. 举个栗子:
服务器存在以下对通讯录的ChangeLog
1) 当没有缓存手机, 去get 通讯录的时候, 那么把最新的 快照(有效的数据条目)或者整个ChangeLog拉下来就成了.
2) 如果手机中存在缓存, 如
则直接从获取T4-T7的ChangeLog记录, 然后更新缓存即可.
可能大家会发现存在“删除”状态的数据，这些数据是表示软删除的数据。关于软/硬删除，大家可以自行度娘。
+45大剑(精简ChangeLog)
上面小节中, ChangeLog可能会文件过长从而占用大量的磁盘, 如果业务中仅仅对最终结果有兴趣,那我们需要适当的清理它们.
比如说, 我们清理了 带* 的ChangeLog条目 , 如图:
在App同步缓存的时候
1） 没有缓存, 下载最新的快照
2) 存在缓存, 则需要根据 缓存最后更新时间Tc 来进行决策
A) Tc < T4: 如Tc 为T1, T2 的时候, 服务器无法进行判断在小于Tc->T4时间段发生了神马事情, 所以只能下载最新的快照
B) Tc>=T4: 则可以下载Tc->T7的ChangeLog, 来进行更新.
可能会出现两种极端的情况:
1) 如果我们手贱, 把整个ChangeLog都删掉了 ？ 蛮有想法的， 可以参考下一小节。
2) 如果把快照也删掉了, 那么去找一个 修复磁盘的专业人员试试看, 顺便构思一下辞职信的内容.
+75无尽(免除ChangeLog)
在上一小节, 我们精简了ChangeLog, 使得可以删除一部分ChangeLog, 那么是否可以去除整个ChangeLog，仅仅留下我们感兴趣的快照呢？ 当然是可以的.
比如说我们经过以下的修改过程, 获得的快照:
在app缓存更新的时候：
1） app没有缓存: download 快照
2） app 有缓存, 且条目最后更新时间为Tc.
A) Tc < T4 : 下载快照。
B) T4 <= Tc <= T7 : 获取快照中Tc->T7的条目, 更新缓存。
基本的思想就是快照为ChangeLog最后有效状态，而我们仅仅需要它。
到此, 我们已经获得+75无尽的加成了, 但是这还不能carry 全场. 我们还需要把焚烧一些被delete的数据.
先知药剂(剔除失效时间过长的数据)
如果数据库中存在N年前的删除记录， 而没有把他们删除掉， 这时候你就需要一瓶清洁剂， 把这些冗余的数据清理掉。清理指南如下:
1. 划出合适的 时间线（焚烧线） ，在这个时间之前“被标记为删除”的数据都将被焚烧掉。
2. 在app同步缓存的时候, 给定的Tc 在焚烧线或者 最旧快照时间（上一小节T4） 之前, 则下载整个快照. 否则下载Tc->最新缓存.
团战要点
1. 避免过量焚烧数据，这会使得app每次都同步最新的快照。
2. 合理的考虑整个快照和增量更新的大小对比。
3. 设计好更新的时机。
基本原理
确保时间戳之前的内容，更新时间戳之后的内容。
