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. 設計好更新的時機。

基本原理

　　確保時間戳之前的內容，更新時間戳之后的內容。

KO增量更新