Solr Cache使用介绍及分析
本文将介绍Solr查询中涉及到的Cache使用及相关的实现。Solr查询的核心类就是SolrIndexSearcher，
每个core通常在 同一时刻只由当前的SolrIndexSearcher供上层的handler使用
（当切换SolrIndexSearcher时可能会有两个同时提供服务），而Solr的各种Cache是依附于SolrIndexSearcher的，SolrIndexSearcher在则Cache 生，SolrIndexSearcher亡则Cache被清空close掉。
Solr中的应用Cache有filterCache、 queryResultCache、documentCache等，这些Cache都是SolrCache的实现类，
并且是 SolrIndexSearcher的成员变量，各自有着不同的逻辑和使命，下面分别予以介绍和分析。
1、SolrCache接口实现类
Solr提供了两种SolrCache接口实现类：solr.search.LRUCache和solr.search.FastLRUCache。
FastLRUCache是1.4版本中引入的，其速度在普遍意义上要比LRUCache更fast些。 下面是对SolrCache接口主要方法的注释：
1 public interface SolrCache{ 2 3 public Object init(Mapargs,Objectpersistence, CacheRegenerator regenerator); 4 5 public int size(); 6 7 public Object put(Objectkey,Objectvalue); 8 9 public Object get(Objectkey); 10 11 public void clear(); 12 13 void warm(SolrIndexSearcher searcher, SolrCache old)throwsIOException; 14 15 public void close(); 16 17 }
1.1、solr.search.LRUCache
LRUCache可配置参数如下：1）size：cache中可保存的最大的项数，默认是1024 2）initialSize：cache初始化时的大小，默认是1024。 3）autowarmCount： 当切换SolrIndexSearcher时，可以对新生成的SolrIndexSearcher做autowarm（预热）处理。 autowarmCount表示从旧的SolrIndexSearcher中取多少项来在新的SolrIndexSearcher中被重新生成，
如何重新生成由CacheRegenerator实现。在当前的1.4版本的Solr中，这个autowarmCount只能取预热的项数，
将来的4.0版本可以指定为已有cache项数的百分比，以便能更好的平衡autowarm的开销及效果。
如果不指定该参数，则表示不做autowarm处理。实现上，LRUCache直接使用LinkedHashMap来缓存数据，
由initialSize来限定cache的大小，淘汰策略也是使用LinkedHashMap的内置的LRU方式，
读写操作都是对map的全局锁，所以并发性效果方面稍差。1.2、solr.search.FastLRUCache
在配置方面，FastLRUCache除了需要LRUCache的参数，还可有选择性的指定下面的参数：1）minSize：当cache达到它的最大数，淘汰策略使其降到minSize大小，默认是0.9*size。 2）acceptableSize：当淘汰数据时，期望能降到minSize，但可能会做不到，则可勉为其难的降到acceptableSize，
默认是0.95*size。
3）cleanupThread：相比LRUCache是在put操作中同步进行淘汰工作，FastLRUCache可选择由独立的线程来做，
也就是配置cleanupThread的时候。当cache大小很大时，每一次的淘汰数据就可能会花费较长时间，
这对于提供查询请求的线程来说就不太合适，由独立的后台线程来做就很有必要。实现上，
FastLRUCache内部使用了ConcurrentLRUCache来缓存数据，它是个加了LRU淘汰策略的ConcurrentHashMap，
所以其并发性要好很多，这也是多数Java版Cache的极典型实现。
2、filterCache
filterCache存储了无序的lucene document id集合，该cache有3种用途：1）filterCache 存储了filter queries(“fq”参数)得到的document id集合结果。Solr中的query参数有两种，即q和fq。如果fq存在，
Solr是先查询fq（因为fq可以多个，所以多个fq查询是个取结果交集 的过程），之后将fq结果和q结果取并。
在这一过程中，filterCache就是key为单个fq（类型为Query），value为documentid集合（类型为DocSet）的cache。
对于fq为range query来说，filterCache表现出其有价值的一面。 2）filterCache 还可用于facet查询（http://wiki.apache.org/solr/SolrFacetingOverview），facet查询中各 facet的计数是通过对满足query条件的document id集合（可涉及到filterCache）的处理得到的。因为统计各facet计数可能会涉及到所有的doc id，所以filterCache的大小需要能容下索引的文档数。 3）如果solfconfig.xml中配置了<useFilterForSortedQuery/>，
那么如果查询有filter（此filter是一需要过滤的DocSet，而不是fq，我未见得它有什么用），
则使用filterCache。下面是filterCache的配置示例：
<!-- Internal cache used by SolrIndexSearcher for filters (DocSets),unordered sets of *all* documentsthat match a query.When a new searcher is opened, its caches may be prepopulatedor "autowarmed" using data from caches in the old searcher.autowarmCount is the number of items to prepopulate. For LRUCache,the prepopulated items will be the most recently accessed items.--> <filterCacheclass="solr.LRUCache"size="16384"initialSize="4096"/>
对于是否使用filterCache及如何配置filterCache大小，需要根据应用特点、统计、效果、经验等各方面来评估。
对于使用fq、facet的应用，对filterCache的调优是很有必要的。
3、queryResultCache
顾名思义，queryResultCache是对查询结果的缓存（SolrIndexSearcher中的cache缓存的都是document id set）， 这个结果就是针对查询条件的完全有序的结果。 下面是它的配置示例： <!-- queryResultCache caches results of searches - ordered lists ofdocument ids (DocList) based on a query, a sort, and the rangeof documents requested.--><queryResultCacheclass="solr.LRUCache"size="16384"initialSize="4096"/>缓存的key是个什么结构呢？就是下面的类（key的hashcode就是QueryResultKey的成员变量hc）：
1 public QueryResult Key(Query query, List<Query>filters, Sort sort,intnc_flags) 2 { 3 this.query=query; 4 this.sort=sort; 5 this.filters=filters; 6 this.nc_flags=nc_flags; 7 inth=query.hashCode(); 8 if(filters!=null)h^=filters.hashCode(); 9 sfields=(this.sort!=null)?this.sort.getSort():defaultSort; 10 for(SortField sf:sfields) 11 { // mix the bits so that sortFields are position dependent 12 // so that a,b won't hash to the same value as b,ah^=(h<<8)|(h>>>25); 13 // reversible hashif(sf.getField()!=null)h+=sf.getField().hashCode();h+=sf.getType(); 14 if(sf.getReverse())h=~h;if(sf.getLocale()!=null)h+=sf.getLocale().hashCode(); 15 if(sf.getFactory()!=null)h+=sf.getFactory().hashCode();}hc=h; 16 }
因为查询参数是有start和rows的，所以某个QueryResultKey可能命中了cache，但start和rows却不在cache的 document id set范围内。当然，document id set是越大命中的概率越大，但这也会很浪费内存，这就需要个参数：queryResultWindowSize来指定document id set的大小。Solr中默认取值为50,可配置，WIKI上的解释很深简单明了： <!-- An optimization for use with the queryResultCache. When a searchis requested, a superset of the requested number
of document idsare collected. For example, of a search for a particular queryrequests matching documents 10 through 19, and queryWindowSize is 50,then documents 0 through 50 will be collected and cached. Any furtherrequests in that range can be satisfied via the cache.--> <queryResultWindowSize>50</queryResultWindowSize> 相比filterCache来说，queryResultCache内存使用上要更少一些，但它的效果如何就很难说。 就索引数据来说，通常我们只是在索引上存储应用主键id，再从数据库等数据源获取其他需要的字段。 这使得查询过程变成，首先通过solr得到document id set，再由Solr得到应用id集合， 最后从外部数据源得到完成的查询结果。如果对查询结果正确性没有苛刻的要求，可以在Solr之外独立的缓存完整的 查询结果（定时作废），这时queryResultCache就不是很有必要，否则可以考虑使用queryResultCache。当然，如果发现在 queryResultCache生命周期内，query重合度很低，也不是很有必要开着它。
4、documentCache
又顾名思义，documentCache用来保存<doc_id,document>对的。如果使用documentCache，就尽可能开大 些，至少要大过<max_results> *<max_concurrent_queries>，否则因为cache的淘汰， 一次请求期间还需要重新获取document一次。也要注意document中存储的字段的多少，避免大量的内存消耗。 下面是documentCache的配置示例：<!-- documentCache caches Lucene Document objects (the stored fields for each document).-->
<documentCacheclass="solr.LRUCache"size="16384"initialSize="16384"/>
5、User/Generic Caches Solr支持自定义Cache，只需要实现自定义的regenerator即可，下面是配置示例：<!-- Example of a generic cache. These caches may be accessed by namethrough SolrIndexSearcher.getCache(),
cacheLookup(), and cacheInsert().The purpose is to enable easy caching of user/application level data. The regenerator argument should be specified as an implementationof solr.search.CacheRegenerator if autowarming is desired.--><!--<cache name="yourCacheNameHere"class="solr.LRUCache"size="4096" initialSize="2048"regenerator="org.foo.bar.YourRegenerator"/>-->
6、The Lucene FieldCache lucene中有相对低级别的FieldCache，Solr并不对它做管理，所以，lucene的FieldCache还是由lucene的IndexSearcher来搞。
7、autowarm
上面有提到autowarm，autowarm触发的时机有两个，一个是创建第一个Searcher时（firstSearcher），一个是创建个新
Searcher（newSearcher）来代替当前的Searcher。在Searcher提供请求服务前，Searcher中的各个Cache可以
做warm处理，处理的地方通常是SolrCache的init方法，而不同cache的warm策略也不一样。
1）filterCache：filterCache注册了下面的CacheRegenerator，就是由旧的key查询索引得到新值put到新cache中。solrConfig.filterCacheConfig.setRegenerator(newCacheRegenerator(){publicbooleanregenerateItem
(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache,ObjectoldKey,ObjectoldVal)
throwsIOException{newSearcher.cacheDocSet((Query)oldKey,null,false);returntrue;}});
2）queryResultCache：queryResultCache的autowarm不在SolrCache的init（也就是说，不是去遍历已
有的queryResultCache中的query key执行查询），而是通过SolrEventListener接口的void
newSearcher(SolrIndexSearcher newSearcher, SolrIndexSearcher
currentSearcher)方法，来执行配置中特定的query查询，达到显示的预热lucene FieldCache的效果。
queryResultCache的配置示例如下：
<listenerevent="newSearcher"class="solr.QuerySenderListener"> <arrname="queries"> <!-- seed common sort fields --> <lst> <strname="q"> anything</str><strname="sort"> name desc price desc populartiy desc</str> </lst> </arr> </listener> <listenerevent="firstSearcher"class="solr.QuerySenderListener"> <arrname="queries"> <!-- seed common sort fields --> <lst> <strname="q"> anything</str><strname="sort"> name desc, price desc, populartiy desc</str> </lst> <!-- seed common facets and filter queries --> <lst> <strname="q"> anything</str><strname="facet.field"> category</str> <strname="fq"> inStock:true</str><strname="fq"> price:[0 TO 100]</str> </lst> </arr> </listener>
3）documentCache：因为新索引的document id和索引文档的对应关系发生变化，所以documentCache没有warm的过程， 落得白茫茫一片真干净。尽管autowarm很好，也要注意autowarm带来的开销，这需要在实际中检验其warm的开销， 也要注意Searcher的切换频率，避免因为warm和切换影响Searcher提供正常的查询服务。
