上篇缓存的博客我说了还有一些问题没有解决。包括，Key值的生成策略和服务器链接信息的访问。这篇博客先总结一下解决思路，不过实现上目前还没有调通。问题详解 key值生成策略 缓存是将数据库中的数据复制一份到内存中，redis有可能会将数据保存在磁盘上。那么当数据库里的数据发生改变时，缓存的数据就变成脏数据了，那么这时候我们就需要将缓存中的数据清除。 这在实现上，缓存一般是加在查询方法上的。而数据变更都是发生在添加、修改、删除的方法上的。也就是说数据变更时需要知道查询方法是以什么Key值存入的，，才能做精确的删除缓存的操作。问题说到这应该清楚了，暂且记下。 数据源信息读取 redis是一个数据库，也就是说每次缓存都需要通过数据库链接信息来产生连接信息。目前是通过Jar包实现的缓存，然后服务器的链接信息是从使用缓存的项目里读取的。这在第一篇博客里说过这个事情了。我是通过拦截器拦截到的InvocationContext得到的类，读取的配置文件路径。也就是说，服务器配置信息是在缓存被调用的时候才读取的。 问题是每次拦截都读取一次，也就是说每次都要进行一次IO操作。这在性能上就导致了一定的瓶颈。解决思路 key值生成策略 第一种思路 这个问题，可以通过一个规范来规定生成规则。这样的话，在需要清除缓存的时候就能根据规范来得到存入的key值。但是这个规范还是不能得到完整的key值，因为key值的生成即使是一个方法也需要根据不同的查询参数来生成key值。另外，查询方法得到的结果也可能是范围的，而添加、删除、修改只是针对一条记录的。简单的说，就是根据规范只能得到Key值的部分。 那么，可以通过对key值再增加一层缓存。key值生成策略：系统+类名+方法名+参数，例如基础系统查询用户的方法：BasicUserManagerQueryUserAdmin。下面看一下图解：
就是说我们根据key中相对稳定的部分，对完整的key再做一层缓存。那么在需要清除缓存的时候就先根据key中稳定的部分，查询到这个类下的所有缓存，然后将这个类的缓存结果都清除。这就保证了，key值可以共享，也保证了数据集合中的单条数据被修改不知道清除哪些缓存的问题。 第二种思路 当需要清除缓存时，就清除所有缓存。但是这样的话，缓存的性能优化的效果就大打折扣了。 综上所述，还是第一种解决思路比较合理。 数据源信息读取 这个问题还涉及到了EJB的关系。因为，目前我每次都需要读取一次配置文件，我先避免这种操作。首先，EJB是多线程的，也就是一个类是多实例的。这就是说，我在对同一个类的操作时拿到的对象不一定是同一个实例。那么，我就只能通过每次读取来保证数据源的配置信息。 这种情况就让我想起了单例模式，如果说保存数据源配置信息的这个类是单例的话。也就是这样的话，不论怎么操作都是拿到的一个实例。这样的话，我做一个标记来标识这个实例是不是已经有了数据源的配置信息。那么我就能够通过标识来决定石头读取配置文件。这样的话，问题就解决了。 这个在事项上，因为EJB的单例模式是通过注解来使用的。我对这个部分的知识还不够了解，遇到问题。所以，还没有实现。 总结：目前的思路是这样的，自己觉得逻辑上应该是行的通的。明天再调试一下，应该就可以了。等我消息！
梦想，并不奢侈，只要勇敢地迈出第一步。
