solr版本：solr6.0.0；主機：red hat； 網絡：千兆網
性能的具體要求是：
1、在一臺機器上普通硬盤的情況下，索引單個文檔大小爲200字節左右，需要達到的效率爲7WTPS。
2、具有良好的水平擴展性。
3、對數據備份和數據丟失情況，要求不嚴格。
在對索引速度進行優化之前，有必要先對建立索引的整個流程做個大致的瞭解，如下圖所示：
說明：
1、 客戶端發送HTTP的POST請求到Solr服務器，報文格式一般有xml、json、javabin（只有java才支持，二進制結構）。
2、 Web服務器將請求派發到Solr的Web應用程序（Servlet）。
3、 Solr根據請求的URI中的Collection名字在solrConfig.xml找到註冊的/update消息處理器；這是單個副本的情況下，如果多個副本的情況下，如果需要判斷此副本是否爲Leader，如果是非Leader，則需要將此文檔發送給此副本的Leader，如果是非直接路由模式，Solr則會根據文檔ID進行hash路由，路由到特定的Leader上。
4、 按照solrConfig.xml配置的請求處理鏈來處理索引，比如分詞處理器等。
5、 寫事務日誌，當發送提交後正式將數據寫入到存儲中，事務日誌可以保證在用戶未提交的情況下數據不丟失。
6、 返回寫索引的結果。
一 提交方式
solr提供了兩種提交方式：硬提交和軟提交。硬提交(hard commit)指的是在客戶端每提交一批數據都通知服務器把數據刷新到硬盤上，檢索的時候數據可以立馬可見；軟提交(soft commit)是讓服務器自己控制在一定的時間範圍之內刷新數據。很明顯，硬提交是非常損耗性能的操作，並且它還會阻塞其他數據的提交，所以我們選擇軟提交，具體配置方式如下所示：
- <autoCommit>
- <maxTime>${solr.autoCommit.maxTime:30000}</maxTime>
- <openSearcher>false</openSearcher>
- </autoCommit>
- <autoSoftCommit>
- <maxTime>${solr.autoSoftCommit.maxTime:60000}</maxTime>
- </autoSoftCommit>
在這份配置文件中，我們指定了服務器每隔60秒對數據做一次軟提交，另外推薦opensearch設置爲false，否則每次提交都會開啓一個opensearch，這個也會損耗性能。
二 關閉副本
solr一個collection會有多個分片（shard），多個shard分別位於不同的節點上，每個節點上可能會有shard的多個複製，其中一個爲leader shard，在追求極限速度的情況下，可以將副本數設置爲1，這樣減去了副本間的數據同步等資源消耗。不過這樣做帶來的弊端就是數據容災性降低，和檢索性能急劇下降。
三 取消分詞器
很顯然使用分詞器的話會對數據做進一步處理，也是會使得性能大幅度降低的，再不使用全文檢索的情況下可以不使用分詞器來提高速度。
四 增加分片
在一臺物理機上，我們可以部署多個solr實例，在每個實例上可以設置多個shard，這樣在索引數據的時候，一個collection會有多個shard在同時入數據，顯然速度是可以大幅提升的。不過shard數也不能太多，機器資源是有限的，當太多shard同時寫數據，會導致內存和IO壓力很大，效果適得其反，應該根據自己得硬件情況進行合理設置。另外，如果是採用的SSD硬盤，設置多個solrhome也會有不錯的效果。
五 劃分collection
當數據積累的越來越多的時候，哪怕多個shard，每個shard的數量也是巨量的，這個時候，不僅查詢性能急劇下降，由於lucene倒排序索引的原理建索引速度也會越來越慢。所以我們嘗試控制每個shard數據量不會太大，進行了按業務劃分索引庫，或者按天按小時建立索引庫，這樣數據分佈到多個collection中，均衡了每個索引庫的壓力。