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. 設計好更新的時機。
基本原理
確保時間戳之前的內容,更新時間戳之后的內容。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
