KO增量更新

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. 设计好更新的时机。

基本原理

　　确保时间戳之前的内容，更新时间戳之后的内容。