原文链接：http://java.dzone.com/news/merge-policy-internals-solr?mz=33057-solr_lucene
今天我们关注一个 solr 的 cache 类型：filter cache。接下来，我会解释它是什么、怎么配置它以及如何更好的使用它。
What it is used for?
先从内部机制开始。FilterCache 存储了一些无序的文档标识号 (ID)。这些 ID 并不是我们在 schema.xml 里配置的 unique key，而是 solr 内部的一个文档标识。请记住这个。
FilterCache 的任务是保持与用户过滤的结果关联。另外，cache 可以辅助 facet 机制（在使用 TermEnum 时），在 solrconfig.xml 中的 <useFilterForSortedQuery/> 参数设为 true 时，还可以进行排序。
Definition
FilterCache 的标准定义如下：
1 | <filterCache |
有以下的配置可供选择：
- class: 实现类。建议使用 solr.FastLRUCache，它能在大量的 GET、PUT 操作下，提供更好的性能。
- size: cache 的最大值。
- initialSize: cache 的初始化值。
- autowarmCount: 从旧的 cache 到新的 cache 时，需要被复制的数量。
- minSize: 在 full restoration 的情况下，将 cache 减小后的值
- acceptableSize: 如果 minSize 没有设置，则该值会替代之
- cleanupThread: 默认 false，如果设为 true 则会使用一个分离的 topic 来清理 cache。
大部分情况下，设置 initialSize 和 autowarmCount 就已经足够了。
How to configure？
cache 的大小，需要根据基本的查询语句而定；maximum 大小应该至少等于我们使用的过滤字段的大小。举个例子说明：如果在某个时间内，你的应用程序使用了 2000 个查询参数，则 minimum 的大小应该最小设为 2000。
Efficient use
然而，光有配置是不够的，我们还需要让查询能够使用它。请看下面的例子：
1 | q=name:solr+AND+category:ksiazka+AND+section:ksiazki |
初看起来，查询语句是正确的。但是有个问题：它并没有用到 filterCache。所有的请求将会绑定到 queryResultCache 中并创建一个单独的条目。我们来作一下修改：
1 | q=name:solr&fq=category:ksiazka&fq=section:ksiazki |
有什么变化呢？在这个例子中，一个条目会写入到 queryResultCache 中；另外，还会有两个条目会写入到 filterCache 中。现在看一下下面的语句：
1 | q=name:lucene&fq=category:ksiazka&fq=section:ksiazki |
这个查询会创建一个条目到 queryResultCache 中，但是会使用 filterCache 中两个已经存在的条目。这样查询的执行时间会降低，IO 的使用也会节省。
然而，对于下面的查询：
1 | q=name:lucene+AND+category:ksiazka+AND+section:ksiazki |
solr 不能使用任何 cache 并且需要从 lucene 索引中收集所有的信息。
Last few words
就像你所看到的，配置 cache 的正确方法不是如何保证 solr 能够使用它，而是如何构建查询语句来提升性能。当考虑查询的时候，请考虑这一点。