WebGIS中以version方式實現代碼更新後前端自動讀取更新代碼的方法

文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

1. 前言

GIS代碼進行更新後，因爲用戶前端已有緩存，致使更新的功能不能被及時同步。爲避免前端請求讀取緩存，常見方法是在每個請求後面加上一個隨機生成的變量參數，這樣能夠保證每一個請求都不會跟歷史請求重複。可是，這樣處理是不合理的，咱們雖然避免了讀取緩存，可是卻會致使系統效率下降。

因此，咱們要解決的問題應該是：只有當代碼更新後，客戶前端第一次觸發的全部請求都應該不走緩存，而以後，相同請求緩存繼續有效。

2.解決思路

核心思想爲，在GIS的每次請求後面帶上一個version參數，每次更新後version參數的值均發生變化，因而該version對應的任何請求，第一次均會從新從服務端讀取最新數據，可是以後的請求因爲version再也不變化，緩存繼續有效。

因此這裏咱們實際須要解決的問題變爲了，如何可以自動化生成更新version。

3.實現方法

此方案主要針對前端version，因此咱們要解決如何可以讓該version自動賦值到前端JS代碼中，而不是每次咱們本身手動給一個version值。因爲每次前端更新後，均須要使用ant將代碼進行再次編譯，因此咱們的實現方法爲：

a.在進行ant編譯時生成時間戳變量，再將該變量直接寫入到待打包的JS代碼中。

b.前端全部JS代碼獲取時加上version變量參數。

4.補充一點：若是是數據更新了怎麼辦？

首先，咱們將數據分爲兩種，一種是咱們本身GIS業務庫中的配置數據，一種是地理服務器中的數據（包括第三方的地理服務器）。若是這兩種數據均有更新，咱們如何作到前端及時同步？

4.1GIS業務配置庫中的配置數據讀取

先拋出解決方案：一樣，全部數據類請求加上時間戳，讓數據類請求均不走前端緩存。

可是，不走前端緩存並不表明不走後端緩存，而這裏則是咱們已經或者還需進一步優化的地方：業務庫中的GIS基本配置項都會在業務服務器啓動時讀取到內存中，因此若是配置數據作了更新，傳統方案上須要業務服務器重啓才行，可是目前業務已經提供了數據重載的接口。

因此，當業務數據作了更新後，要麼重啓業務服務，要麼在構建中點擊數據重載（會加入到GIS構建中）。這樣能夠保證，全部的GIS業務配置類數據請求會進入到後臺，可是後臺中緩存的數據是最新數據，從而既保證數據最新又避免對數據庫的壓力。

4.2地理服務器中的數據更新

方案1：一樣使用隨機時間戳來確保每次請求均是最新的數據，此種方法比較簡單通用。

方案2：將version概念引入，數據庫中增長一個數據version配置，每次地理服務器有更新後對version進行修改，而後使用構建讓業務服務器重讀配置，前端請求GIS配置時得到數據version，在請求地理服務時帶上該version。

建議先以方案1來進行，這樣與4.1中的數據請求能夠同步，代碼上能夠統一處理。若是要進行方案2，則須要工程知道地理服務器什麼時候作了更新，而後再在配置中修改version，稍微增長了工程維護量。

5.總結

5.1爲何前端JS和後臺數據不用統一的version確保更新

a.若是用統一version，則該version須要使用庫中配置（或配置文件），可是JS文件的加載每每是在數據請求以前，如此沒法保證在version得到以前的JS文件爲最新文件。

b.數據的更新並不表明系統須要從新編譯，因此針對數據的version沒法和JS版本的version同步。

5.2方案總結

a.前端JS使用ANT編譯自動生成版本號。

b.數據請求加上隨機時間戳。

 

 　　　　　　　　　　　　　　　　　　　　　　　　　　-----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

                                                                      　　　　    若是您以爲本文確實幫助了您，能夠微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^