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之間。