一.索引提交

　　當一個文件被新增到Solr中，但沒有提交給索引之前，這個文件是無法被搜尋的。換句話說，從查詢的角度看，文件直到提交之後才是可見的。Solr有兩種型別的提交：軟提交和正常提交【也稱硬提交】。

　　1.正常提交　　

　　　　Solr正常提交是將所有未提交的文件寫入磁碟，並重新整理一個內部搜尋器元件，讓新提交的文件能夠被搜尋。搜尋器實際上可以看作索引中所有已提交文件的只讀檢視。可以這樣說，硬提交是花銷很大的操作，由於硬提交需要開啟一個新搜尋器，所以會影響到查詢效能。

　　　　當正常提交成功後，新提交的文件被安全儲存在持久儲存器上不會因為正常的維護操作或伺服器崩潰重啟而丟失。出於高可用性考慮，如果磁碟發生故障，就需要一套故障轉移方案，這一點在以後接著討論。

　　2.軟提交

　　　　軟提交支援近實時搜尋【Near Real-Time NRT】。軟提交作為近乎實時可被搜尋到的一種機制，跳過了硬提交的高消耗，例如，重新整理到持久儲存器就是花銷較大的操作。軟提交相對而言花銷較低，可以每一秒都執行一次軟提交，使得新近被索引的文件在新增到Solr之後很快被搜尋到。但要記住，在某一時刻仍然需要執行硬提交操作，以確保文件最終被寫入到持久化儲存器中。

　　綜上所述：

　　　　》硬提交讓文件可被搜尋，由於需要將其寫入到持久化儲存器中，所以花銷較大

　　　　》軟提交也可以讓文件被搜尋，不需要將其寫入到持久化儲存中

　　3.自動提交

　　　　不管是正常提交還是軟提交，都可以採用以下三種策略中的一種來自動提交文件：

　　　　　　》在指定時間內提交文件

　　　　　　》一旦達到使用者指定的未提交文件數閾值，就提交那麼未提交的文件

　　　　　　》每隔特定時間間隔提交所有文件

　　4.配置

　　　　Solr硬提交與軟提交的自動提交需要在solrconfig.xml中進行配置。　

 1     <!-- AutoCommit
 2 
 3          Perform a hard commit automatically under certain conditions.
 4          Instead of enabling autoCommit, consider using "commitWithin"
 5          when adding documents.
 6 
 7          http://wiki.apache.org/solr/UpdateXmlMessages
 8 
 9          maxDocs - Maximum number of documents to add since the last
10                    commit before automatically triggering a new commit.
11 
12          maxTime - Maximum amount of time in ms that is allowed to pass
13                    since a document was added before automatically
14                    triggering a new commit.
15          openSearcher - if false, the commit causes recent index changes
16            to be flushed to stable storage, but does not cause a new
17            searcher to be opened to make those changes visible.
18 
19          If the updateLog is enabled, then it's highly recommended to
20          have some sort of hard autoCommit to limit the log size.
21       -->
22      <autoCommit>
23        <maxTime>${solr.autoCommit.maxTime:15000}</maxTime> <!-- 上一次提交到自動提交的最長時間間隔 -->
24        <openSearcher>false</openSearcher> <!-- 提交後是否開啟一個新的搜尋器 -->
25      </autoCommit>

　　執行自動提交時通常會開啟一個新搜尋器。在預設情況下【未開啟】，某檔案自動提交，該檔案將被寫入到磁碟，但在搜尋結果中不可見。Solr之所以提供這個選項，是為了減少未提交更新的事務日誌大小，並避免在大規模索引過程中開啟太多搜尋器。

　　在solrconfig.xml中使用autoSoftCommit元素也可以自動配置軟提交。

1     <!-- softAutoCommit is like autoCommit except it causes a
2          'soft' commit which only ensures that changes are visible
3          but does not ensure that data is synced to disk.  This is
4          faster and more near-realtime friendly than a hard commit.
5       -->
6 
7      <autoSoftCommit>
8        <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime> <!-- -1表示無限大 -->
9      </autoSoftCommit>

二.事務日誌

　　Solr使用事務日誌來確保提交到索引並已接受的更新儲存在持久化儲存器中。事務日誌用來避免因提交過程中的異常情況而導致提交的文件丟失的情況。具體來說，事務日誌主要有三個作用：

　　　　》支援近實時獲取和原子更新【下面具體講解】

　　　　》解除提交過程中寫入的永續性

　　　　》通過solrcloud的分片代表支援副本的同步

　　在solrconfig.xml中的一個Solr核心的事務日誌配置如下：

 1 <!-- Enables a transaction log, used for real-time get, durability, and
 2          and solr cloud replica recovery.  The log can grow as big as
 3          uncommitted changes to the index, so use of a hard autoCommit
 4          is recommended (see below).
 5          "dir" - the target directory for transaction logs, defaults to the
 6                 solr data directory.
 7          "numVersionBuckets" - sets the number of buckets used to keep
 8                 track of max version values when checking for re-ordered
 9                 updates; increase this value to reduce the cost of
10                 synchronizing access to version buckets during high-volume
11                 indexing, this requires 8 bytes (long) * numVersionBuckets
12                 of heap space per Solr core.
13     -->
14     <updateLog>
15       <str name="dir">${solr.ulog.dir:}</str> <!-- 預設目錄是data目錄下的tlog -->
16       <int name="numVersionBuckets">${solr.ulog.numVersionBuckets:65536}</int>
17     </updateLog>

　　每次提交情況都會被記錄到事務日誌中。直到發起提交之前，事務日誌會持續增長。在提交期間會處理活動的事務日誌，之後將開啟一個新的事務日誌。一個更新執行步驟如下：

　　執行步驟解釋如下：

　　　　1.客戶端應用程式使用HTTP POST方式傳送一個更新請求，可以是JSON/XML或者Solr內部二進位制javabin格式

　　　　2.Jetty【Solr內部自帶的WEB伺服器】將此請求傳送給Solr的Web應用程式

　　　　3.Solr的請求排程器通過請求路徑中的collection名稱確定呼叫的solr核心。接下來排程器定位到/update請求處理器

　　　　4.更新請求處理器對該請求進行處理，且該請求處理器將呼叫一個可配置的更新處理器鏈，在索引時為每個文件進行額外的處理

　　　　5.ADD請求寫入到事務日誌中

　　　　6.一旦更新請求被安全地儲存到持久儲存器，就會通過響應讀寫器迴應客戶端應用。這時，客戶端應用得知更新請求成功執行，就可以繼續執行下面的請求

　　注意，事務日誌的關鍵在於權衡事務日誌的長度與硬提交的執行頻率。如果事務日誌變得很龐大，重啟就需要更長時間來處理更新，也會造成恢復過程緩慢。

&n