上一章，我们添加了游戏的主界面和注册登录功能。由于距离上上篇间隔较长，可能有些内容想些的后来就忘了。同时，逻辑也不复杂，所以描述比较粗略。 　　现在随着模块的增加，整个架构也暴露出一些问题。本章我们将对整个系统进行大规模重构。 　　比如，之前为了快速开发，rms模块，我们采用了直接访问数据库的方式，对于rms模块本身来说，没有什么问题。 　　但是，在game模块中，对于频繁访问的、不经常改变的数据或接口，希望采用缓存的方式，将数据缓存起来，减少后端压力，同时加快响应速度，从而提升体验。 　　之前rms模块中尝试使用了EhCache，作为内存缓存。但现在增加了game模块，内存缓存无法在两个进程中共享。因此，我们引入redis，把缓存数据统一存到redis中。这里我们先使用spring-data-redis来进行缓存。通过在Service的方法上标记注解，来将方法返回结果进行缓存。这样一个粗粒度的缓存，目前能满足大部分需求。后面有需要时，我们再手动操作redis，进行细粒度的缓存。 　　除了缓存改造，发现一些枚举值，比如：种族、职业、阵营等，目前以静态类、枚举类的形式，在各个模块定义，这样每当我修改时，需要同时修改几个地方。因此，我添加了数据字典表，将这类数据统一配置到数据库中，同时由于不常修改，各个模块可以直接将其读到缓存中。数据字典的UML类图如下。 　　这样，我只需要一个静态类，枚举出父级配置即可，以后只会增加，一般情况下都不会修改。代码如下： DataType.java 附一、spring-data-redis 　　此缓存组件使用比较简单，安装好redis，添加好依赖和配置后。在需要缓存的方法上标记注解即可。主要有@Cacheable、@CacheEvict、@CachePut。 例一：下面的注解，代表此方法执行成功后，将返回结果缓存到redis中， key为 mapMob:#{id}，当结果为NULL时，不缓存。 @Cacheable(value = "mapMob", key = "#id", unless = "#result == null") public CommonResult find(String id) { return super.find(id); } 例二：下面的注解，代表此方法执行成功后，将缓存 dataDict: 中的键全部清除 @CacheEvict(value = "dataDict", allEntries = true) public CommonResult update(DataDict dataDict) { return super.update(dataDict); } 例三：下面的注解，代表方法执行成功后，将key为 levelExp:#{id} 的缓存更新为方法返回的结果 @CachePut(value = "levelExp", key = "#levelExp.getId()") public CommonResult update(LevelExp levelExp) { return super.update(levelExp); } 　　 一、缓存改造 　　因为是在hessian的方法上进行缓存，这里我们在hessian模块的pom.xml中添加依赖如下： pom.xml 　　这里，我们需要配置一个叫 cacheManager 的 bean。之前我们一直使用xml对各组件进行配置，此 cacheManager 也可以使用xml进行配置。但在实际使用中，我想将redis的key统一配置成 idlewow:xxx:...，研究了半天未找到xml形式的配置方法，因此这里使用Java代码进行配置。在hessian模块添加包 com.idlewow，然后新建 CacheConfig 类，如下: CacheConfig 　 这里我只简单的配置了下，缓存的有效期为1小时，当结果为NULL时不缓存，key前缀为 idlewow:。 有兴趣的话可以研究下到底能否用xml配置key前缀，注意这里用的是spring-data-redis 2.x版本，和 1.x 版本配置区别较大。 　 添加好依赖后，我们需要在服务的方法上打上标记即可。服务的实现类，在core模块下。 　　比如，我们这里以 MapMobServiceImpl 为例，此服务的方法update、delete、find执行成功后，我们均需要更新缓存。因为我们不缓存NULL值，因此add执行后，无需更新缓存。这里的方法已经在BaseServiceImpl里实现过来，但需要打注解，不能直接在父类里标记，因此各个子类重写一下方法签名，内容直接 super.find(id)，即可，也比较方便。代码如下： MapMobServiceImpl 　　OK, hessian模块的缓存已改造完毕。可以尝试调用一下，redis里应该已经可以写入数据。 　　另外：这里我还添加了一个listByMapId方法，后面game模块会调用。这里没有再统一返回CommonResult类型。因为我在实际写代码过程中，发现每次调接口都去做判断实在太繁琐了，对内调用一般无需这么麻烦。一般在跨部门、公司之间的接口对接，或者对容错要求比较高时，可以将异常全部捕获处理。因此，后面对内的即接口都直接返回需要的数据类型。 二、RMS系统对应改造 　　hessian既然已经改成了redis缓存。RMS系统需要做对应的改造。game模块中读取了缓存，如果rms模块修改了数据，却没有更新redis缓存，会造成最终的数据不一致。 　　因此，我们将rms模块改造为通过访问hessian服务来读写数据，这样调用hessian方法时就能触发缓存，不再直接访问数据库。 　　这里把EhCache、数据库相关的代码、配置、依赖都删掉。并在pom中添加对hessian的引用，并像game模块一样，配置hessian-client.xml并在applicationContext.xml中引入。 　　在代码中，我们将CrudController中的BaseManager替换成BaseService，并将其他地方做对应修改。如下图： CrudController.java 　　另外，因为添加了数据字典。rms模块需要添加对应的contoller和页面。这里不一一赘述。既然已经有了数据字典，之前写死的枚举，EnumUtil都可以废除了。直接从hessian读取数据字典配置到缓存。 　　在com.idlewow.rms.support.util包下添加DataDictUtil类，代码如下： DataDictUtil.java 　　在StartUpListener中，初始化缓存： @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { logger.info("缓存初始化。。。"); dataDictUtil.initialize(); logger.info("缓存初始化完毕。。。"); } 　　后端缓存有了，同样的，前端写死的枚举也不需要了。可以使用localStorage进行缓存。代码如下： Helper.js 　　注意，这里使用了jQuery的ajax请求，必须在引用之前引用jquery。 小结 内容有些许遗漏，下周再补充些。 　　源码下载地址：https://545c.com/file/14960372-405053633 https://www.cnblogs.com/lyosaki88/p/idlewow_12.html