Solr的底層是基於Lucene索引結構，Lucene是一套資訊檢索工具包，但並不包含搜尋引擎系統，它包含了索引結構、讀寫索引工具、相關性工具、排序等功能。所以，只要是相同版本的Solr和Lucene其用的索引檔案是相容的，solrconfig.xml有使用Lucene的版本資訊。如果我們直接利用Lucene來寫Solr的索引目錄，降低網路開銷，並且減去Solr除了索引以外功能做的額外開銷，從提升建索引的角度，有不錯的提升。

 如上圖所示：

1、客戶端呼叫Lucene的API直接在本地的Solr的core的目錄建索引。（Collection的一個shard的副本其實就是一個core檔案）

2、多個客戶端，每個客戶端對應一個shard副本，注意這裡是一個shard只有一個副本的情況下，如果多個副本需要注意副本之間的資料同步的問題。

       在實際的場景中，為了防止多執行緒操作同一個檔案帶來的問題，Lucene可以在其他目錄建立索引，然後通過定期合併索引檔案的方式，載入到solr的shard中。流程如下圖所示：

過程說明：

1、 客戶端程式呼叫lucene的API進行寫索引。

2、 索引寫到特定的目錄下。

3、 呼叫solr的索引合併的HTTP介面，進行索引合併。

4、 呼叫HTTP的合併結構後會將Lucene新建的索引目錄合併到Solr的索引中去。

 注意：

1、 這種合併的URL如下：http://x.x.x.x:port/solr/admin/cores?action=mergeindexes&core=collection_shard1_replica1&indexDir=/parkfs01/aus/soft/luncenetmp/0

2、 合併後的索引不是可見的，需要重新載入索引，或者重新做提交，提交時候需要開啟搜尋器使索引可見：http://x.x.x.x:port/ solr/collection/update?commit=true&openSearcher=true這裡的collection要改成具體的collection名字。在單節點時候需要重新載入整個core，這個耗時很大，單節點僅僅提交，仍然搜尋不到新新增的文件。

       有了上面的支撐，結合流程中比較耗時的操作，綜合考慮，可以按照下圖所示的架構來設計程式：

說明：

1、根據要求生成文件。

2、根據生成的文件列表生成可執行單元，可以執行單元的主要是建立IndexWriter和新增索引動作。

3、將可行物件傳送給執行緒池執行。

4、執行完畢後將需要合併的索引目錄和url傳送到合併佇列，合併佇列數量達到一定數量後，執行合併索引動作和提交索引動作。

5、索引執行緒池存在建立一定數量索引後，會關閉原來的IndexWriter，從新建立的目錄生成新的IndexWriter。

 注意：

1、因為IndexWriter是執行緒安全的，所以執行緒池可以共同操作同一個IndexWriter物件。

2、在合併索引後，不能立刻刪除目錄，呼叫SOLR的合併索引的URL返回後，後臺也有可能還在合併。

3、經過測試在一個索引文件286個位元組條件下，solr6.0版本，速率大概在4.7W和5.1W之間浮動；一個報文2K的情況下，每秒大概有3.5W到4W之間。