文章版权由作者李晓晖和博客园共有，若转载请于明显处标明出处：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/
如果您觉得本文确实帮助了您，可以微信扫一扫，进行小额的打赏和鼓励，谢谢 ^_^
