Caching 提交时防止solr缓存刷新

我的应用程序的写入吞吐量很低，我可以管理2-3分钟的更改，以反映在solr搜索结果中。
目前，我通过索引应用程序提交（在每批文档之后），并且在solr端配置了以下内容：

solr.autoSoftCommit.maxTime : -1 (disabling auto soft commit)
solr.autoCommit.maxTime : 300000 (5 mins of hard auto commit interval)
opensearcher : false

选择配置的原因来自我对以下内容的理解：

我的应用程序读起来很重，需要大量的缓存，而我又负担不起刷新缓存的费用。因此，我完全禁用了软提交

我再次禁用了opensearcher，因为如果我不这么做，它将使顶级缓存失效，这是不可取的

在生产环境中，我观察到，只要我的应用程序尝试为一个文档（或一批文档）编制索引，然后（从我的应用程序）发出commit语句，我的所有顶级缓存都会被删除。
我想也许仅仅依靠硬自动提交会有所帮助，但是根据这个

硬提交关乎持久性，软提交关乎可见性。这里有两种风格，openSearcher=true和openSearcher=false。首先，我们将讨论在这两种情况下发生的情况。如果openSearcher=true或openSearcher=false，则以下后果最为重要：

tlog被截断：新的tlog被启动。旧的TLOG将被删除 如果更新、关闭的TLOG中的文档超过100个，则删除。 当前索引段已关闭并刷新。背景片段 可以启动合并。以上情况发生在所有硬提交上。那个 离开openSearcher设置

openSearcher=true:Solr/Lucene搜索程序被重新打开，所有 缓存无效。自动预热完成等。这曾经是 您可以查看新添加文档的唯一方法

openSearcher=false:除了上面的四点之外，没有其他事情发生。搜寻 对于文档，软提交是必要的

总之，软提交将刷新缓存，opensearcher=true的自动硬提交也将刷新缓存。而opensearcher=false的自动硬提交将不允许反映我添加的更改。

如果我误解了什么，请一定要指出

下面是我的问题：

在将某些文档添加到索引中并同时提供更改时，是否无法确保顶级筛选器缓存不会被删除

如果是这样的话，那么我是否需要始终依靠缓存预热来获取缓存中的某些文档

除了热身，还有其他方法可以避免这种情况吗；如果他们想建立一个快速搜索的产品，并有一些写吞吐量以及

我已经阅读了一些文档链接和文章，但是我找不到任何合适的链接来解释在不同的场景中要使用什么设置。如果有人能解释我做错了什么，并指导我找到一个合适的解决方案，那将非常有帮助。

---

你的理解是对的

Solr缓存与索引的特定实例相关联 Searcher，索引的特定视图，在搜索过程中不会更改 那个搜索者的一生。只要那个索引搜索者还在 使用后，其缓存中的任何项都将有效并可供重用

打开新搜索者时，当前搜索者将继续 在新请求自动预热其缓存时为请求提供服务。新的 搜索者使用当前搜索者的缓存预填充自己的缓存。 当新搜索者准备就绪时，它将注册为当前搜索者 并开始处理所有新的搜索请求。老探索者 将在完成所有请求的服务后关闭

如果您需要让您的搜索者访问新添加的文档，您可以 需要打开一个新的搜索引擎。这可以通过使用 使用openSearcher提交或硬提交=true。缺点是 您的顶级缓存将失效。这就是你要的价格 为获得能见度而付费

是的，热身是最好的方式让您的缓存填充之前 打开一个新的搜索引擎。你应该确定什么是最重要的 系统中常用的查询，并让这些查询自动预热新查询 储藏室

如果您不想进行实时搜索，并且可以容忍这种情况，则应关闭软提交，并使用opensearcher=true的硬提交。硬提交的间隔取决于应用程序能够承受的延迟。如果您不在乎索引为t=t1的文档会一直显示到t=t1+x分钟。您应该每x分钟提交一次

每一种选择都有缺点。你需要找出最适合你的方法

---

没有免费午餐。

从solr用户列表中选择 您可以尝试使用更实时的分段缓存。
它应该像q={！parent=COLOR:Blue v='''}一样工作，而不是q=COLOR:Blue 确保solrconfig.xml中有以下定义此再生器应在搜索程序之间传输筛选器位集

 <query>
    <cache name="perSegFilter" 
           class="solr.LRUCache"
           size="100"
           initialSize="10"
           autowarmCount="100%"
           regenerator="solr.NoOpRegenerator"/>
  </query>

---

在提交后立即检查此缓存是有意义的

关于#1-如果索引的内容发生更改，缓存将不再有效，并且不再受信任-因此，如果用户希望看到更改（并且不使响应处于未定义状态），则必须使其无效。关于#3-

commitWithin

可能是这里最好的实现，因为它允许您说“这些文档应该在三分钟内可见”-因此您可以从多个位置进行索引，而不必担心索引会更频繁地从其他线程提交。感谢@root545的解释。这很有帮助。