Solr4.8.0源码分析(18)之缓存机制(一)
前文在介绍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 缓存就不会初始化。
1 if (cachingEnabled) {
2 ArrayList<SolrCache> clist = new ArrayList<>();
3 fieldValueCache = solrConfig.fieldValueCacheConfig==null ? null : solrConfig.fieldValueCacheConfig.newInstance();
4 if (fieldValueCache!=null) clist.add(fieldValueCache);
5 filterCache= solrConfig.filterCacheConfig==null ? null : solrConfig.filterCacheConfig.newInstance();
6 if (filterCache!=null) clist.add(filterCache);
7 queryResultCache = solrConfig.queryResultCacheConfig==null ? null : solrConfig.queryResultCacheConfig.newInstance();
8 if (queryResultCache!=null) clist.add(queryResultCache);
9 documentCache = solrConfig.documentCacheConfig==null ? null : solrConfig.documentCacheConfig.newInstance();
10 if (documentCache!=null) clist.add(documentCache);
11
12 if (solrConfig.userCacheConfigs == null) {
13 cacheMap = noGenericCaches;
14 } else {
15 cacheMap = new HashMap<>(solrConfig.userCacheConfigs.length);
16 for (CacheConfig userCacheConfig : solrConfig.userCacheConfigs) {
17 SolrCache cache = null;
18 if (userCacheConfig != null) cache = userCacheConfig.newInstance();
19 if (cache != null) {
20 cacheMap.put(cache.name(), cache);
21 clist.add(cache);
22 }
23 }
24 }
25
26 cacheList = clist.toArray(new SolrCache[clist.size()]);
27 } else {
28 filterCache=null;
29 queryResultCache=null;
30 documentCache=null;
31 fieldValueCache=null;
32 cacheMap = noGenericCaches;
33 cacheList= noCaches;
34 }
从上述代码中可以看出，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的查询就基本不会命中缓存。所以对实时应用需要特别注意。
1 <query>
2 <filterCache class="solr.LRUCache" size="300" initialSize="10" autowarmCount="300"/>
3 <queryResultCache class="solr.LRUCache" size="300" initialSize="10" autowarmCount="300"/>
4 <fieldValueCache class="solr.FastLRUCache" size="300" initialSize="10" autowarmCount="300" />
5 <documentCache class="solr.FastLRUCache" size="5000" initialSize="512" autowarmCount="300"/>
6 <useFilterForSortedQuery>true</useFilterForSortedQuery>//是否能使用到filtercache关键配置
7 <queryResultWindowSize>50</queryResultWindowSize>//queryresult的结果集控制
8 <enableLazyFieldLoading>false</enableLazyFieldLoading>//是否启用懒加载field
9 </query>
2.2 Cache的预热
预热，也许会很多人不了解预热的含义，在这里稍微解释下，例如一个Cache已经缓存了比较多的值，如果因为新的IndexSearcher被重新构建，那么新的Cache又会需要重新累积数据，那么会发现搜索突然会在一段时间性能急 剧下降，要等到Cache重新累计了一定数据，命中率才会慢慢恢复。所以这样的情形其实是不可接受的，那么我们可以做的事情就是将老Cache对应的key,在重新构建SolrIndexSearcher返回之前将这些已经在老Cache中Key预先从磁盘重新load Value到Cache中，这样暴露出去的SolrIndexSearcher对应的Cache就不是一个内容为空的Cache，而是已经“背地”准备好内容的Cache。
前文在getSearcher()中以及提到了预热，那么再来回顾下它的源码。
1 future = searcherExecutor.submit(new Callable() {
2 @Override
3 public Object call() throws Exception {
4 try {
5 newSearcher.warm(currSearcher);
6 } catch (Throwable e) {
7 SolrException.log(log, e);
8 if (e instanceof Error) {
9 throw (Error) e;
10 }
11 }
12 return null;
13 }
14 });
15
真正开始进行预热是在SolrIndexSearcher.warn函数中，可以看出SolrIndexSearcher会对每一个缓存类型(filterCache，documentCache等)依次进行预热。而每一种类型的Cache都会根据其cache的接口类型来调用接口类型的warn。比如Solrconfig.xml中设置了filterCache的类型为FastLRUCache，那么Solr就会调用FastLRUCache的warn。
1 for (int i=0; i<cacheList.length; i++) {
2 if (debug) log.debug("autowarming " + this + " from " + old + "\n\t" + old.cacheList[i]);
3
4
5 SolrQueryRequest req = new LocalSolrQueryRequest(core,params) {
6 @Override public SolrIndexSearcher getSearcher() { return SolrIndexSearcher.this; }
7 @Override public void close() { }
8 };
9
10 SolrQueryResponse rsp = new SolrQueryResponse();
11 SolrRequestInfo.setRequestInfo(new SolrRequestInfo(req, rsp));
12 try {
13 this.cacheList[i].warm(this, old.cacheList[i]);
14 } finally {
15 try {
16 req.close();
17 } finally {
18 SolrRequestInfo.clearRequestInfo();
19 }
20 }
21
22 if (debug) log.debug("autowarming result for " + this + "\n\t" + this.cacheList[i]);
23 }
FastLRUCache和LRUCache的区别我们暂且不讲，后文会详细介绍。我们提取出了它们共同实现warn的代码，即CacheRegenerator**.**regenerateItem()。regenerateItem的作用是对单个查询条件进行预热处理。
1 for (int i=0; i<keys.length; i++) {
2 try {
3 boolean continueRegen = regenerator.regenerateItem(searcher, this, old, keys[i], vals[i]);
4 if (!continueRegen) break;
5 }
6 catch (Exception e) {
7 SolrException.log(log,"Error during auto-warming of key:" + keys[i], e);
8 }
9 }
目前有三个CacheRegenerator，分别对应fieldValueCache，filterCache，以及queryResultCache。在SolrCore初始化的时候会分别对这三个类型的CacheRegenerator进行初始化。
1 public static void initRegenerators(SolrConfig solrConfig) {
2 if (solrConfig.fieldValueCacheConfig != null && solrConfig.fieldValueCacheConfig.getRegenerator() == null) {
3 solrConfig.fieldValueCacheConfig.setRegenerator(
4 new CacheRegenerator() {
5 @Override
6 public boolean regenerateItem(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache, Object oldKey, Object oldVal) throws IOException {
7 if (oldVal instanceof UnInvertedField) {
8 UnInvertedField.getUnInvertedField((String)oldKey, newSearcher);
9 }
10 return true;
11 }
12 }
13 );
14 }
15
16 if (solrConfig.filterCacheConfig != null && solrConfig.filterCacheConfig.getRegenerator() == null) {
17 solrConfig.filterCacheConfig.setRegenerator(
18 new CacheRegenerator() {
19 @Override
20 public boolean regenerateItem(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache, Object oldKey, Object oldVal) throws IOException {
21 newSearcher.cacheDocSet((Query)oldKey, null, false);
22 return true;
23 }
24 }
25 );
26 }
27
28 if (solrConfig.queryResultCacheConfig != null && solrConfig.queryResultCacheConfig.getRegenerator() == null) {
29 final int queryResultWindowSize = solrConfig.queryResultWindowSize;
30 solrConfig.queryResultCacheConfig.setRegenerator(
31 new CacheRegenerator() {
32 @Override
33 public boolean regenerateItem(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache, Object oldKey, Object oldVal) throws IOException {
34 QueryResultKey key = (QueryResultKey)oldKey;
35 int nDocs=1;
36 // request 1 doc and let caching round up to the next window size...
37 // unless the window size is <=1, in which case we will pick
38 // the minimum of the number of documents requested last time and
39 // a reasonable number such as 40.
40 // TODO: make more configurable later...
41
42 if (queryResultWindowSize<=1) {
43 DocList oldList = (DocList)oldVal;
44 int oldnDocs = oldList.offset() + oldList.size();
45 // 40 has factors of 2,4,5,10,20
46 nDocs = Math.min(oldnDocs,40);
47 }
48
49 int flags=NO_CHECK_QCACHE | key.nc_flags;
50 QueryCommand qc = new QueryCommand();
51 qc.setQuery(key.query)
52 .setFilterList(key.filters)
53 .setSort(key.sort)
54 .setLen(nDocs)
55 .setSupersetMaxDoc(nDocs)
56 .setFlags(flags);
57 QueryResult qr = new QueryResult();
58 newSearcher.getDocListC(qr,qc);
59 return true;
60 }
61 }
62 );
63 }
64 }
- 关于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为例。
1 // lastly, put the superset in the cache if the size is less than or equal
2 // to queryResultMaxDocsCached
3 if (key != null && superset.size() <= queryResultMaxDocsCached && !qr.isPartialResults()) {
4 queryResultCache.put(key, superset);
5 }
2.3 Cache的销毁
Cache的销毁也是通过SolrIndexSearcher的关闭一并进行，见solrIndexSearcher.close()方法：
1 @Override
2 public void close() throws IOException {
3 if (debug) {
4 if (cachingEnabled) {
5 StringBuilder sb = new StringBuilder();
6 sb.append("Closing ").append(name);
7 for (SolrCache cache : cacheList) {
8 sb.append("\n\t");
9 sb.append(cache);
10 }
11 log.debug(sb.toString());
12 } else {
13 if (debug) log.debug("Closing " + name);
14 }
15 }
16
17 core.getInfoRegistry().remove(name);
18
19 // super.close();
20 // can't use super.close() since it just calls reader.close() and that may only be called once
21 // per reader (even if incRef() was previously called).
22
23 long cpg = reader.getIndexCommit().getGeneration();
24 try {
25 if (closeReader) reader.decRef();
26 } catch (Exception e) {
27 SolrException.log(log, "Problem dec ref'ing reader", e);
28 }
29
30 if (directoryFactory.searchersReserveCommitPoints()) {
31 core.getDeletionPolicy().releaseCommitPoint(cpg);
32 }
33
34 for (SolrCache cache : cacheList) {
35 cache.close();
36 }
37
38 if (reserveDirectory) {
39 directoryFactory.release(getIndexReader().directory());
40 }
41 if (createdDirectory) {
42 directoryFactory.release(getIndexReader().directory());
43 }
44
45
46 // do this at the end so it only gets done if there are no exceptions
47 numCloses.incrementAndGet();
48 }
总结：
本节主要介绍了Cache的创建，预热，添加以及销毁，重点阐述了预热的原理。下节将介绍几种Cache的结构，使用场景，命中监控等。
版权声明：本文不是「本站」原创文章，版权归原作者所有 | 原文地址: