一、es基本概述
es是基於lucene的開源分佈式查詢和分析的搜索引擎，可以通過簡單的restful api輕鬆實現搜索功能，可以進行大規模的橫向擴展，以支撐pb級的結構化和分結構化海量數據的處理。所謂的全文索引指計算機索引程序通過掃描文章中的每一個詞，對每一個詞建立一個索引，指明該詞在文章中出現的次數和位置，當用戶查詢時，檢索程序就根據事先建立的索引進行查找
二、es適用場景
1、站內搜索，主要和solr競爭
2、文檔數據庫，和Mongo搶佔市場，讀寫性能高於Mongo,同時也支持地理位置查詢
3、監控：統計，日誌類時間序的數據存儲和分析，可視化
4、提供全文搜索並高亮顯示關鍵字
三、es內置rest接口
/index/_search 搜索指定索引下的數據
/_aliases 獲取或操作索引的別名
/index/ 查看指定索引的詳細信息
/index/type/ 創建或操作類型
/index/_mapping 創建或操作mapping
/index/_setting 創建或操作設置(但分片一經創建無法更改)
/index/_open 打開被關閉的索引
/index/_close 關閉指定的索引
/index/refresh 刷新指定的索引，保證新增的索引可見，不保證數據持久化
/index/fresh 刷新索引觸發提交
四、集羣的狀態
green:健康狀態，指所有主副分片都正常分配
yellow:指所有主分片都正常分配，副本未正常分配
red：有主分片未分配
- 增加節點是否能夠提高索引的數據容量? 如果說索引的分片數目和當前es的節點數量一樣，則不能提高，因爲3個分片分佈到三個節點上，新增的節點顯然無法利用，如果分片數目大於當前的節點數量，新增節點的話，會提高索引的數據容量
- 增加副本的數目能否提高索引的讀取吞吐量？ 不能，因爲新增的副本還是分佈在3個節點上，還是利用了同樣的資源，如果要增加吞吐量，那麼就需要增加新的節點
注意：分片數的設定非常重要，需要提前就要規劃好；分片數太少，導致後續無法通過增加節點實現水平擴容；分片數過大，導致一個節點上分佈多個分片，造成資源浪費，同時也會影響查詢性能
五、故障轉移
node1所在的機器宕機導致服務器終止，此時就需要故障轉移，從而達到可用的目的
1、node2,node3發現主節點node1無法響應一段時間後會發起master選舉，選舉node2爲主節點，此時由於主分片p0下線，集羣狀態變爲red
2、node2發現主分片P0未分配，將R0提升爲主分片，此時由於所有主分片都正常分配，集羣狀態變爲yellow
3、node2發現主分片P0和P1生成新的副本，集羣狀態變爲green
六、腦裂問題
一個正常的es集羣中只有一個主節點 ，主節點負責管理整個集羣，集羣的所有節點都選擇同一個節點作爲主節點。腦裂問題的出現主要是因爲從節點在選擇主節點上出現分歧導致一個集羣出現多個主節點，從而使得集羣分裂。
可能導致腦裂的原因：
1. 網絡：由於是內網通信，網絡通信問題造成某些節點認爲master死掉;當出現網絡風暴，IO大面積阻塞、爬蟲等現象的時候， 就會造成master宕機 2. 節點負載：**由於master節點與data節點都是混合在一起的**，所以當工作節點的負載較大（確實也較大）時，導致對應的 ES實例停止響應，而這臺服務器如果正充當着master節點的身份，那麼一部分節點就會認爲這個master節點失效了，故重新 選舉新的節點，這時就出現了腦裂；同時由於data節點上ES進程佔用的內存較大，較大規模的內存回收操作也能造成ES進程 失去響應。所以，這個原因的可能性應該是最大的。
解決方案一：將master節點和data節點分離
通過配置文件中,node.master：true;node.data：false這倆個配置，將該節點只是單純的設置爲master節點，不存儲數據。業務上我們可以設置倆臺機器單純設置爲master節點，實現可用性，master選舉只在這倆臺機器上選舉，對數據不會影響，從而不會產生腦裂問題，再設置多臺機器爲data節點，將node.master：false;node.data：true
解決方案二：修改相關參數
discovery.zen.ping_timeout：3 這個配置是當master接待你如果在3秒之內沒有響應，那麼其他節點就任務這個master節
點死掉，從而進行選舉，所以可以把這個時間設置大一點，一定程度上減少誤判
discovery.zen.minimum_master_nodes：3 共3個master節點，目的是達到(n/2)+1等於2的要求，這樣掛掉一臺master後，滿足參數，其他倆個master節點都會認爲當前master節點掛掉，開始重新選舉
