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