前文在介绍commit的时候具体介绍了getSearcher()的实现,并提到了Solr的预热warn。那么本文开始将详细来学习下Solr的缓存机制。

1. 简介

Solr目前支持4中cache类型,每种缓存对应一种查询类型。

  • filterCache
  • documentCache
  • fieldvalueCache
  • queryresultCache

Solr提供了两种SolrCache接口实现类:

  • solr.search.LRUCache
  • solr.search.FastLRUCache。

FastLRUCache是1.4版本中引入的,其速度在普遍意义上要比LRUCache更fast些。

本文开始将详细介绍以上的内容,而本文的重要内容是Cache的生命周期,即

2. Cache生命周期

所有的Cache的生命周期由SolrIndexSearcher来管理,如果Cache对应的SolrIndexSearcher被重新构建都代表正在运行的Cache对象失效。

2.1 Cache初始化

前文 Solr4.8.0源码分析(17)之SolrCloud索引深入(4) 中讲到了,增量数据更新后提交DirectUpdateHandler2.commit(CommitUpdateCommand cmd)过程时候getSearcher()会获取到SolrIndexSearcher,如果设置forceNew=true ,就会重新打开一个SolrIndexSearcher,这个时候Solr就会进行warn。SolrIndexSearcher的有关cache的初始化代码如下, 可以看出cachingEnabled是个很关键的配置,如果该值为false 缓存就不会初始化。

if (cachingEnabled) {
      ArrayList<SolrCache> clist = new ArrayList<>();
      fieldValueCache = solrConfig.fieldValueCacheConfig==null ? null : solrConfig.fieldValueCacheConfig.newInstance();
      if (fieldValueCache!=null) clist.add(fieldValueCache);
      filterCache= solrConfig.filterCacheConfig==null ? null : solrConfig.filterCacheConfig.newInstance();
      if (filterCache!=null) clist.add(filterCache);
      queryResultCache = solrConfig.queryResultCacheConfig==null ? null : solrConfig.queryResultCacheConfig.newInstance();
      if (queryResultCache!=null) clist.add(queryResultCache);
      documentCache = solrConfig.documentCacheConfig==null ? null : solrConfig.documentCacheConfig.newInstance();
      if (documentCache!=null) clist.add(documentCache);

      if (solrConfig.userCacheConfigs == null) {
        cacheMap = noGenericCaches;
      } else {
        cacheMap = new HashMap<>(solrConfig.userCacheConfigs.length);
        for (CacheConfig userCacheConfig : solrConfig.userCacheConfigs) {
          SolrCache cache = null;
          if (userCacheConfig != null) cache = userCacheConfig.newInstance();
          if (cache != null) {
            cacheMap.put(cache.name(), cache);
            clist.add(cache);
          }
        }
      }

      cacheList = clist.toArray(new SolrCache[clist.size()]);
    } else {
      filterCache=null;
      queryResultCache=null;
      documentCache=null;
      fieldValueCache=null;
      cacheMap = noGenericCaches;
      cacheList= noCaches;
    }

从上述代码中可以看出,Solr的缓存接口主要有两种,LRUCache和FastLRUCache,这可以在SolrConfig.xml上进行配置。

其中size为缓存设置大小,initalSize初始化大小,autowarmCount 是最为关键的参数代表每次构建新的SolrIndexSearcher的时候需要后台线程预热加载到新Cache中多少个结果集。autowarmCount不但支持具体的参数比如300,也支持按百分比设置,比如autowarmCount="300"。如果autowarmCount为0则表示不进行预热。

那是不是这个预热数目越大就越好呢,其实还是要根据实际情况而定。如果你的应用为实时应用,很多实时应用的实现都会在很短的时间内去得到重新打开的 内存索引indexReader,而Solr默认实现就会重新打开一个新的SolrIndexSearcher,那么如果Cache需要预热的数目越多,那么打开新的SolrIndexSearcher就会越慢,这样对实时性就会大打折扣。但是如果设置很小。每次都打开新的SolrIndexSearcher都是空Cache,基本上那些fq和facet的查询就基本不会命中缓存。所以对实时应用需要特别注意。

<query>
<filterCache      class="solr.LRUCache"     size="300"      initialSize="10"      autowarmCount="300"/>
<queryResultCache class="solr.LRUCache"     size="300"      initialSize="10"      autowarmCount="300"/>
<fieldValueCache  class="solr.FastLRUCache"     size="300"      initialSize="10"       autowarmCount="300" />
<documentCache    class="solr.FastLRUCache"     size="5000"      initialSize="512"      autowarmCount="300"/>
<useFilterForSortedQuery>true</useFilterForSortedQuery>//是否能使用到filtercache关键配置
<queryResultWindowSize>50</queryResultWindowSize>//queryresult的结果集控制
<enableLazyFieldLoading>false</enableLazyFieldLoading>//是否启用懒加载field
</query>

2.2 Cache的预热

预热,也许会很多人不了解预热的含义,在这里稍微解释下,例如一个Cache已经缓存了比较多的值,如果因为新的IndexSearcher被重新构建,那么新的Cache又会需要重新累积数据,那么会发现搜索突然会在一段时间性能急 剧下降,要等到Cache重新累计了一定数据,命中率才会慢慢恢复。所以这样的情形其实是不可接受的,那么我们可以做的事情就是将老Cache对应的key,在重新构建SolrIndexSearcher返回之前将这些已经在老Cache中Key预先从磁盘重新load Value到Cache中,这样暴露出去的SolrIndexSearcher对应的Cache就不是一个内容为空的Cache,而是已经“背地”准备好内容的Cache。

前文在getSearcher()中以及提到了预热,那么再来回顾下它的源码。

future = searcherExecutor.submit(new Callable() {
  @Override
  public Object call() throws Exception {
    try {
      newSearcher.warm(currSearcher);
    } catch (Throwable e) {
      SolrException.log(log, e);
      if (e instanceof Error) {
        throw (Error) e;
      }
    }
    return null;
  }
});

真正开始进行预热是在SolrIndexSearcher.warn函数中,可以看出SolrIndexSearcher会对每一个缓存类型(filterCache,documentCache等)依次进行预热。而每一种类型的Cache都会根据其cache的接口类型来调用接口类型的warn。比如Solrconfig.xml中设置了filterCache的类型为FastLRUCache,那么Solr就会调用FastLRUCache的warn。

for (int i=0; i<cacheList.length; i++) {
  if (debug) log.debug("autowarming " + this + " from " + old + "\n\t" + old.cacheList[i]);


  SolrQueryRequest req = new LocalSolrQueryRequest(core,params) {
    @Override public SolrIndexSearcher getSearcher() { return SolrIndexSearcher.this; }
    @Override public void close() { }
  };

  SolrQueryResponse rsp = new SolrQueryResponse();
  SolrRequestInfo.setRequestInfo(new SolrRequestInfo(req, rsp));
  try {
    this.cacheList[i].warm(this, old.cacheList[i]);
  } finally {
    try {
      req.close();
    } finally {
      SolrRequestInfo.clearRequestInfo();
    }
  }

  if (debug) log.debug("autowarming result for " + this + "\n\t" + this.cacheList[i]);
}

FastLRUCache和LRUCache的区别我们暂且不讲,后文会详细介绍。我们提取出了它们共同实现warn的代码,即CacheRegenerator**.**regenerateItem()。regenerateItem的作用是对单个查询条件进行预热处理。

for (int i=0; i<keys.length; i++) {
  try {
    boolean continueRegen = regenerator.regenerateItem(searcher, this, old, keys[i], vals[i]);
    if (!continueRegen) break;
  }
  catch (Exception e) {
    SolrException.log(log,"Error during auto-warming of key:" + keys[i], e);
  }
}

目前有三个CacheRegenerator,分别对应fieldValueCache,filterCache,以及queryResultCache。在SolrCore初始化的时候会分别对这三个类型的CacheRegenerator进行初始化。

public static void initRegenerators(SolrConfig solrConfig) {
if (solrConfig.fieldValueCacheConfig != null && solrConfig.fieldValueCacheConfig.getRegenerator() == null) {
  solrConfig.fieldValueCacheConfig.setRegenerator(
          new CacheRegenerator() {
            @Override
            public boolean regenerateItem(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache, Object oldKey, Object oldVal) throws IOException {
              if (oldVal instanceof UnInvertedField) {
                UnInvertedField.getUnInvertedField((String)oldKey, newSearcher);
              }
              return true;
            }
          }
  );
}

if (solrConfig.filterCacheConfig != null && solrConfig.filterCacheConfig.getRegenerator() == null) {
  solrConfig.filterCacheConfig.setRegenerator(
          new CacheRegenerator() {
            @Override
            public boolean regenerateItem(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache, Object oldKey, Object oldVal) throws IOException {
              newSearcher.cacheDocSet((Query)oldKey, null, false);
              return true;
            }
          }
  );
}

if (solrConfig.queryResultCacheConfig != null && solrConfig.queryResultCacheConfig.getRegenerator() == null) {
final int queryResultWindowSize = solrConfig.queryResultWindowSize;
solrConfig.queryResultCacheConfig.setRegenerator(
  new CacheRegenerator() {
    @Override
    public boolean regenerateItem(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache, Object oldKey, Object oldVal) throws IOException {
      QueryResultKey key = (QueryResultKey)oldKey;
      int nDocs=1;
      // request 1 doc and let caching round up to the next window size...
      // unless the window size is <=1, in which case we will pick
      // the minimum of the number of documents requested last time and
      // a reasonable number such as 40.
      // TODO: make more configurable later...

      if (queryResultWindowSize<=1) {
        DocList oldList = (DocList)oldVal;
        int oldnDocs = oldList.offset() + oldList.size();
        // 40 has factors of 2,4,5,10,20
        nDocs = Math.min(oldnDocs,40);
      }

      int flags=NO_CHECK_QCACHE | key.nc_flags;
      QueryCommand qc = new QueryCommand();
      qc.setQuery(key.query)
        .setFilterList(key.filters)
        .setSort(key.sort)
        .setLen(nDocs)
        .setSupersetMaxDoc(nDocs)
        .setFlags(flags);
      QueryResult qr = new QueryResult();
      newSearcher.getDocListC(qr,qc);
      return true;
    }
  }
);
}
}
  • 关于fieldValueCache的预热将会在facet查询部分再介绍,本节将介绍filterCache和queryResultCache的regenerateItem。
  • filterCache 在预热的时候会根据oldkey即根据缓存中的查询条件再去查询一次,并吧查询结果放入缓存。
  • queryResultCache 在SolrConfig.xml上有queryResultWindowSize,即每次查询是以该值为单位来返回查询结果个数。比如queryResultWindowSize为50,那么返回的结果就是50的倍数。在预热的时候,queryResultCache会再次用chache的查询条件查询一次,并返回queryResultWindowSize的结果放入缓存。
  • documentCache 存放的是<id,document>键值对,在预热的时候将会被遗弃。也即该缓存在进行commit的时候就会清零。

从上述的代码中可以看出,预热的本质就是将旧的Searcher中的query在进行commit时重新查询一遍,并将结果放入新的Searcher中。因此如果这个query的个数越多,预热的时间越久,所以autowarnCount这个参数很重要,它控制了旧的Searcher进行预热的query数量,如果该值为0就不会进行预热。如果autowarnCount较大,预热时间就会持续太久,将大大影响索引的性能,如果autowarnCount较少,虽然预热时间会持续较短,但是一开始缓存的命中将很低,影响查询性能。

2.3 Cache的添加

每查询一次,Solr都会把查询条件和查询结果进行缓存,以queryResultCache为例。

// lastly, put the superset in the cache if the size is less than or equal
// to queryResultMaxDocsCached
if (key != null && superset.size() <= queryResultMaxDocsCached && !qr.isPartialResults()) {
  queryResultCache.put(key, superset);
}

2.3 Cache的销毁

Cache的销毁也是通过SolrIndexSearcher的关闭一并进行,见solrIndexSearcher.close()方法:

@Override
public void close() throws IOException {
if (debug) {
 if (cachingEnabled) {
   StringBuilder sb = new StringBuilder();
   sb.append("Closing ").append(name);
   for (SolrCache cache : cacheList) {
     sb.append("\n\t");
     sb.append(cache);
   }
   log.debug(sb.toString());
 } else {
   if (debug) log.debug("Closing " + name);
 }
}

core.getInfoRegistry().remove(name);

// super.close();
// can't use super.close() since it just calls reader.close() and that may only be called once
// per reader (even if incRef() was previously called).

long cpg = reader.getIndexCommit().getGeneration();
try {
 if (closeReader) reader.decRef();
} catch (Exception e) {
 SolrException.log(log, "Problem dec ref'ing reader", e);
}

if (directoryFactory.searchersReserveCommitPoints()) {
 core.getDeletionPolicy().releaseCommitPoint(cpg);
}

for (SolrCache cache : cacheList) {
 cache.close();
}

if (reserveDirectory) {
 directoryFactory.release(getIndexReader().directory());
}
if (createdDirectory) {
 directoryFactory.release(getIndexReader().directory());
}


// do this at the end so it only gets done if there are no exceptions
numCloses.incrementAndGet();
}

总结:

本节主要介绍了Cache的创建,预热,添加以及销毁,重点阐述了预热的原理。下节将介绍几种Cache的结构,使用场景,命中监控等。