JFinal开发JPress的ehcache缓存方案、以及踩过ehcache的坑

2019独角兽企业重金招聘Python工程师标准>>>

      最近为了提高JPress的性能，减少数据查询的次数，JPress大量使用了ehcache缓存作为起内置缓存，同时session也是基于ehcache重新实现的支持分部署的session解决方案。

 

     因为JPress是基于JFinal快速开发框架，而JFinal又内置了ehcache的插件，使用起来及其简单。

 

        1、JFinal里配置ehcachePlugin插件。

public void configPlugin(Plugins me) {
        me.add(new EhCachePlugin());
		
	//添加其他插件
}

        2、在classPath下添加ehcache的配置文件ehcache.xml

        3、直接使用EhcacheKit操作缓存。

public void yourMethod() {
       Cachekit.put("cacheName","key","value")

}

 

        到此，一切很顺利的进行着，但随着JPress在大量的使用ehcache，ehcache的缓存数据操作与更新就变成了一个棘手的问题，更新数据库数据了，缓存若得不到及时更新，就会导致程序在运行的过程中有大量的bug、各种莫名其妙的问题。此时、缓存数据的更新，就需要一个良好更新的计划和方案。

 

         首先，是数据颗粒度的问题，我们在缓存数据的时候，可能是根据数据库的ID，对单个model（单条数据）进行缓存，这种缓存以model的ID作为key进行缓存，这种缓存的颗粒度极细。

 

       因此，我们在做数据的更新的时候非常简单，只需在model的更新和删除的时候从ehcache删除该ID即可。针对这一的问题，我们只需要重写Model的update和delete方法，删除其缓存。

 

        代码如下：

@Table(tableName = "content", primaryKey = "id")
public class Content extends BaseContent {

	private static final long serialVersionUID = 1L;

	@Override
	public boolean update() {
		removeCache(getId());//移除ehcache缓存
		return super.update();
	}

	@Override
	public boolean delete() {
		removeCache(getId());//移除ehcache缓存
		return super.delete();
	}

}

       通过这种方式，我们在通过ID来查询该数据的时候，不用担心缓存于数据库不同步的问题，因为我们在更新、删除的时候就已经把ehcache的缓存数据给清除掉了，当查询的时候发现ehcache里没有数据，自动会去数据库会获取，从而保证了ehcache的数据与数据库保持一致。

 

        但是，我们在缓存数据的时候，不只是对单个model进行缓存，在程序的各种业务场景中，大量会使用到列表的查询，因此我们在存储的时候，肯定也会多列表进行缓存。例如：

public List findByModule(final String module, final BigInteger parentId, String orderby) {
		final StringBuilder sqlBuilder = new StringBuilder("select * from content c");
		sqlBuilder.append(" sql ....");

		return DAO.getFromListCache("cacheName","key", new IDataLoader() {
			@Override
			public Object load() {
				return DAO.find(sqlBuilder.toString(), module,parentId);
			}
		});
		
	}

   

        但是，一旦缓存了列表，问题就来了？这个列表的数据什么时候会被更新呢？这个缓存到ehcache的某条数据可能会被随时更新或删除了，怎么来同步？

 

        一种粗糙的方案是：把所有缓存都缓存到同一个cacheName中，然后在model的update或delete的时候，对这个cacheName不管三七二十一直接全部清除，如下代码：

@Table(tableName = "content", primaryKey = "id")
public class Content extends BaseContent {

	private static final long serialVersionUID = 1L;

	@Override
	public boolean update() {
		removeCache(getId());//移除ehcache缓存
        removeAllListCache(); //移除所有保存列表数据的缓存
		return super.update();
	}

	@Override
	public boolean delete() {
		removeCache(getId());//移除ehcache缓存
         removeAllListCache(); //移除所有保存列表数据的缓存
		return super.delete(); 
	}

}

         

        虽然这是一种粗糙的方案，但是也是有效解决了列表数据不同步的问题；其粗糙的原因是，当我们清除数据的时候，把所有的列表都删除了，这样会导致很多没有没有该列表的数据也被清楚了...

 

        所以，更有效的解决方案应该是保留和该ID没有关系的数据，而只清除有关的数据。

 

        那问题来了，什么数据才是该ID有关的数据呢？

        1、列表有该ID的数据。

        2、列表的排序等会受到该ID影响的数据，比如谋条数据的orderby_number更新了，可能某个缓存的列表数据虽然没有该ID，但是该ID更新后，可能是orderby_number，由于缓存的列表数据是根据orderby_number来排序的，此时该数据应该出现在列表里。

        3、分页数据，比如某条数据被删除或更新了，可能分页的页码数据就会被改变。

 

         那如何才能找到该ID关联的数据呢？

        这是一个困难的问题，每个业务系统不一样，关联的数据肯定也不一样。在JPress里，每个content都有一个module字段，表示该数据所属的模型。

 

       因此，在JPress的内容分类里，JPress针对某种类型的数据，都按照一定的规则来建立这个存储的key，比如文章模型的列表在存储的时候，存储的key值大概为：module:article-xxx-xxx这样的key。

       当文章模型的数据被更新的时候，会去便利所有列表数据的key，如果发现key是以module:article开头，表示该数据是文章列表的缓存数据，应该清除。

 

       于是，就有了如下的代码：

public void removeAllListCache() {
		List