Hard commits, soft commits and transaction logs

“Hard commits are about durability, soft commits are about visibility“

 Transaction Logs

首先介绍下solrcloud的index流程。

1）update请求发送给任意节点（NodeA）。

2）若该节点不是leader，将请求转发给leader。

3）leader将请求转发给所有副本节点（同一分片）。

后面就是执行结果的响应（response），所有副本节点反馈给leader，leader再反馈给原接收到请求的节点（NodeA）。

当所有leader都反馈给NodeA（执行update完毕），NodeA再反馈给“客户端”。在这时候，所有的更新操作被刷到tlog中。

如果JVM挂了，这些操作任然会被写入磁盘，如果操作系统挂了，就会丢掉这些操作日志。

如果JVM重启，那么solr会从tlog中进行数据恢复。

注意：

1）hard commit时产生一个新的tlog文件，如果被关闭的tlog中包含的documents超过100，则会删除最老的一个tlog文件。

e.g.

So consider if you are indexing in batches of 25 documents and hard committing after each one (not that you should commit that often, but just saying). You should have 5 tlogs at any given time. the oldest four (closed) contain 25 documents each, totaling 100 plus the current tlog file. When the current tlog is closed, the oldest tlog will be deleted, and a new one opened.

2）如果一直没有hard commit，那么这个tlog文件可能会很大（一直没有close）。当solr重启的时候可能会造成较大的性能消耗。

Soft commit

Soft commit让searcher对更新可见，但是会导致“top level caches”失效（filterCache、queryResultCache等），包括FieldValueCache失效，那么facet请求需要等待cache完成刷新。

如果频繁的soft commit会导致“top level caches”很少被命中，导致性能问题。

不过“segment level caches”并不会失效，例如function queries、sorting caches等。

Soft commit到底做了些什么？

1）tlog会持续被写入，并不会重新创建。

2）searcher对更新可见。

3）一些cache会被重新加载（top level caches）

虽然soft commit比hard commit更轻量，但是TANSTAAFL，There Ain't No Such Thing As A Free Lunch. Soft commit支持nrt，不过也需要额外的开销，这取决于你系统对nrt的忍耐度。

Hard commit

Hard commit到底做了什么？

1）创建新的tlog，如果超过100个documtns，那么就会删除老的tlog文件。

2）创建新的segment，并flush到磁盘。

3）segment合并有可能会被触发。

Hard commit还有一个选项：openSearcher。

openSearcher=true

Searchers会被重新打开，并且所有caches会失效，执行自动预热。只有这样才能对更新可见。

openSearcher=false

更新不可见。

简单的总结：

SoftCommit：更新可见，缓存失效，不会写入磁盘，追加tlog。

HardCommit：更新不可见，写入磁盘，新建tlog。

https://lucidworks.com/blog/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/