離線包增量更新方案
下面這張簡圖，介紹了我們是如何設計離線包增量更新方案的：
現在以乙個新的業務模組上線為例，說明下整個流程：
建立業務模組
發布業務模組
在離線包發布系統，選擇業務**倉庫分支，然後build，發布。
離線包安裝
其中2個系統的功能簡單介紹下，其中離線包管理系統主要負責以下功能：
離線包元資料資訊管理
元資料報括唯一包名、適用的平台、優先順序、負責人、以及業務頻道描述。
離線包的啟停用控制
而離線包發布系統包含以下功能：
拉取選擇倉庫分支的**，然後build
發布build完成的包
修改資料庫中該離線包版本，修改離線包管理系統中最新包的版本。
灰度發布、回滾、停用支援
灰度切分流量下發離線包，發現有問題及時回滾，可以隨時停止發布，避免影響更多使用者。
發布資料查詢與監控
發布效果監控，可以檢視公升級百分比，也支援特定使用者的對某個發布的結果查詢。
工程實踐中的問題和解決方案
上面介紹了離線包增量更新方案，但在實際工程實踐中還是會遇到了諸多問題，接下來逐個分析。
包依賴管理
因此我們設計了一套簡單的依賴管理規則，來解決這個問題：
使用數字標識離線包的優先順序，數字越小，優先順序越高;
實際使用過程中，我們只定義了2個優先順序0和100。0為框架類，公共業務類的離線包，100為業務功能的離線包。業務依賴框架正常，極少有業務之間的強依賴，偶爾有的時候，業務之間協調好發布順序即可。
動態差分
看起來很完美的方案，並且業內大多做離線包的差分都是採取這種成熟的方案。但是實際效果並不完美，我們發現偶爾會出現300多kb大小的離線包在差分之後，生成的包有100多kb。
經過反覆測試，我們發現zip檔案解壓之後比較裡面的變化檔案，生成diff檔案，然後將diff檔案生成乙個zip包，比直接bsdiff計算2個zip包生成的diff，會小很多。基於這個測試，我們對bspatch做了一些改進：
上圖可以看到，生成patch包的時候，只zip進去變更過和新增的檔案，同時，對每個變化過的檔案，生成了乙個hash檔案，這樣可以確保客戶端將diff檔案patch到原始檔案之後，能驗證檔案是否完整， 這一點非常重要，因為bspatch執行的時候，不會因為檔案內容合併不正確而返回patch失敗。
主要由以下機制進行保障：
重試機制
簽名校驗
定時輪循
離線包的使用、安裝和載入
進入a業務，如果發現有合併成功的離線包檔案abak，先使用該檔案覆蓋awork, 覆蓋成功之後，載入頁面時候，需要清空快取，reload頁面，載入失敗回滾a_work目錄。
發布控制
灰度發布：離線包發布直接到達使用者終端，為了確認發布的功能對使用者帶來的影響線，需要先觀察一部分使用者行為和資料。這樣發布系統就需提供灰度發布功能。我們採用的預設設定規則是10分鐘10%，30分鐘50% 1小時後達到100%。
發布回滾：發布的包如果有問題，可以回滾到先前版本的包。
停止發布：發布的包如果沒有生效，也沒有***，為了盡可能的減少影響，可以直接停止這個包的發布。
端到端監控
小結
Hive增量更新方案
hive增量更新方案 方案一 總結出來業界可行方案 1 hive原始表提前規劃好以時間分割槽，初始化裝載源庫記錄為base table 最新資料 2 每個相關表都會有乙個timestamp列，對每一行操作做了修改，都會重置這列timestamp為當前時間戳 3 新增資料通過sqoop 支援當天抽取 ...
ES Ik遠端詞典增量更新方案
2 從es ik原始碼可以看到，傳送httphead請求的時候，會攜帶es外掛程式之前儲存的資源最新更新時間 last modified 通過if modified since請求頭攜帶 和最新的資源標識etags 通過if none match請求頭攜帶 服務端接收到這兩個引數後，和服務端狀態進行...
微信熱更新方案實踐
簡單的講 增量更新 tinker imitator 位址 電腦 mac 編譯工具 as intellj gradle 版本 com.android.tools.build gradle 2.1.2 android 版本 6.0 mac 端命令 brew install bsdifflinux 端命令...