solr叢集構建的基本流程介紹

先從第一臺solr伺服器說起：
1. 它首先啟動一個嵌入式的Zookeeper伺服器，作為叢集狀態資訊的管理者，
2. 將自己這個節點註冊到/node_states/目錄下
3. 同時將自己註冊到/live_nodes/目錄下
4. 建立/overseer_elect/leader，為後續Overseer節點的選舉做準備，新建一個Overseer，
5. 更新/clusterstate.json目錄下json格式的叢集狀態資訊
6. 本機從Zookeeper中更新叢集狀態資訊，維持與Zookeeper上的叢集資訊一致
7. 上傳本地配置檔案到Zookeeper中，供叢集中其他solr節點使用
8. 啟動本地的Solr伺服器，
9. Solr啟動完成後，Overseer會得知shard中有第一個節點進來，更新shard狀態資訊，並將本機所在節點設定為shard1的leader節點，並向整個叢集釋出最新的叢集狀態資訊。
10.本機從Zookeeper中再次更新叢集狀態資訊，第一臺solr伺服器啟動完畢。

然後來看第二臺solr伺服器的啟動過程：
1. 本機連線到叢集所在的Zookeeper，
2. 將自己這個節點註冊到/node_states/目錄下
3. 同時將自己註冊到/live_nodes/目錄下
4. 本機從Zookeeper中更新叢集狀態資訊，維持與Zookeeper上的叢集資訊一致
5. 從叢集中儲存的配置檔案載入Solr所需要的配置資訊
6. 啟動本地solr伺服器，
7. solr啟動完成後，將本節點註冊為叢集中的shard，並將本機設定為shard2的Leader節點，
8. 本機從Zookeeper中再次更新叢集狀態資訊，第二臺solr伺服器啟動完畢。


這個叢集現在就具備容錯性了，你可以試著宕掉一臺Solr伺服器，然後再傳送查詢請求。背後的實質是叢集的overseer會監測各個shard的leader節點，如果leader節點掛了，則會啟動自動的容錯機制，會從同一個shard中的其他replica節點集中重新選舉出一個leader節點，甚至如果overseer節點自己也掛了，同樣會自動在其他節點上啟用新的overseer節點，這樣就確保了叢集的高可用性.