文章版權由作者李曉晖和部落格園共有，若轉載請于明顯處标明出處：http://www.cnblogs.com/naaoveGIS/
GIS代碼進行更新後，由于使用者前端已有緩存，導緻更新的功能不能被及時同步。為避免前端請求讀取緩存，常見方法是在每一個請求後面加上一個随機生成的變量參數，這樣可以保證每個請求都不會跟曆史請求重複。但是，這樣處理是不合理的，我們雖然避免了讀取緩存，但是卻會導緻系統效率降低。
是以，我們要解決的問題應該是：隻有當代碼更新後，客戶前端第一次觸發的所有請求都應該不走緩存，而之後，相同請求緩存繼續有效。
核心思想為，在GIS的每次請求後面帶上一個version參數，每次更新後version參數的值均發生變化，于是該version對應的任何請求，第一次均會重新從服務端讀取最新資料，但是之後的請求由于version不再變化，緩存繼續有效。
是以這裡我們實際需要解決的問題變為了，如何能夠自動化生成更新version。
此方案主要針對前端version，是以我們要解決如何能夠讓該version自動指派到前端JS代碼中，而不是每次我們自己手動給一個version值。由于每次前端更新後，均需要使用ant将代碼進行再次編譯，是以我們的實作方法為：
a.在進行ant編譯時生成時間戳變量，再将該變量直接寫入到待打包的JS代碼中。
b.前端所有JS代碼擷取時加上version變量參數。
首先，我們将資料分為兩種，一種是我們自己GIS業務庫中的配置資料，一種是地理伺服器中的資料（包括第三方的地理伺服器）。如果這兩種資料均有更新，我們如何做到前端及時同步？
先抛出解決方案：同樣，所有資料類請求加上時間戳，讓資料類請求均不走前端緩存。
但是，不走前端緩存并不代表不走後端緩存，而這裡則是我們已經或者還需進一步優化的地方：業務庫中的GIS基本配置項都會在業務伺服器啟動時讀取到記憶體中，是以如果配置資料做了更新，傳統方案上需要業務伺服器重新開機才行，但是目前業務已經提供了資料重載的接口。
是以，當業務資料做了更新後，要麼重新開機業務服務，要麼在建構中點選資料重載（會加入到GIS建構中）。這樣可以保證，所有的GIS業務配置類資料請求會進入到背景，但是背景中緩存的資料是最新資料，進而既保證資料最新又避免對資料庫的壓力。
方案1：同樣使用随機時間戳來確定每次請求均是最新的資料，此種方法比較簡單通用。
方案2：将version概念引入，資料庫中增加一個資料version配置，每次地理伺服器有更新後對version進行修改，然後使用建構讓業務伺服器重讀配置，前端請求GIS配置時獲得資料version，在請求地理服務時帶上該version。
建議先以方案1來進行，這樣與4.1中的資料請求可以同步，代碼上可以統一處理。如果要進行方案2，則需要工程知道地理伺服器何時做了更新，然後再在配置中修改version，稍微增加了工程維護量。
a.如果用統一version，則該version需要使用庫中配置（或配置檔案），但是JS檔案的加載往往是在資料請求之前，如此無法保證在version獲得之前的JS檔案為最新檔案。
b.資料的更新并不代表系統需要重新編譯，是以針對資料的version無法和JS版本的version同步。
a.前端JS使用ANT編譯自動生成版本号。
b.資料請求加上随機時間戳。
如果您覺得本文确實幫助了您，可以微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^
