一、叢集規劃
搭建一個叢集我們需要考慮如下幾個問題：
1. 我們需要多大規模的叢集？
2. 叢集中的節點角色如何配置設定？
3. 如何避免腦裂問題？
4. 索引應該設定多少個分片？
5. 分片應該設定幾個副本？
下面我們就來分析和回答這幾個問題
需要從以下兩個方面考慮：
1.1 目前的資料量有多大？資料增長情況如何？
1.2 你的機器配置如何？cpu、多大記憶體、多大硬碟容量？
推算的依據：
es jvm heap 最大可以設定32g 。
30g heap 大概能處理的資料量 10 t。如果記憶體很大如128g，可在一台機器上運作多個es節點執行個體。
備注：叢集規劃滿足目前資料規模+适量增長規模即可，後續可按需擴充。
兩類應用場景：
a. 用于建構業務搜尋功能子產品，且多是垂直領域的搜尋。資料量級幾千萬到數十億級别。一般2-4台機器的規模。
b. 用于大規模資料的實時olap（聯機處理分析），經典的如elk stack，資料規模可能達到千億或更多。幾十到上百節點的規模。
2.1 節點角色：
master
node.master: true 節點可以作為主節點
datanode
node.data: true 預設是資料節點。
coordinate node 協調節點
如果僅擔任協調節點，将上兩個配置設為false。
說明：
一個節點可以充當一個或多個角色，預設三個角色都有
協調節點：一個節點隻作為接收請求、轉發請求到其他節點、彙總各個節點傳回資料等功能的節點。就叫協調節點
2.2 如何配置設定：
a. 小規模叢集，不需嚴格區分。
b. 中大規模叢集（十個以上節點），應考慮單獨的角色充當。特别并發查詢量大，查詢的合并量大，可以增加獨立的協調節點。角色分開的好處是分工分開，不互影響。如不會因協調角色負載過高而影響資料節點的能力。
3.1 腦裂問題：
一個叢集中隻有一個a主節點，a主節點因為需要處理的東西太多或者網絡過于繁忙，進而導緻其他從節點ping不通a主節點，這樣其他從節點就會認為a主節點不可用了，就會重新選出一個新的主節點b。過了一會a主節點恢複正常了，這樣就出現了兩個主節點，導緻一部分資料來源于a主節點，另外一部分資料來源于b主節點，出現資料不一緻問題，這就是腦裂。
3.2 盡量避免腦裂，需要添加最小數量的主節點配置：
discovery.zen.minimum_master_nodes: (有master資格節點數/2) + 1
這個參數控制的是，選舉主節點時需要看到最少多少個具有master資格的活節點，才能進行選舉。官方的推薦值是(n/2)+1，其中n是具有master資格的節點的數量。
3.3 常用做法（中大規模叢集）：
1. master 和 datanode 角色分開，配置奇數個master，如3
2. 單點傳播發現機制，配置master資格節點：
discovery.zen.ping.multicast.enabled: false —— 關閉多點傳播發現機制，預設是關閉的
discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"] —— 配置單點傳播發現的主節點ip位址，其他從節點要加入進來，就得去詢問單點傳播發現機制裡面配置的主節點我要加入到叢集裡面了，主節點同意以後才能加入，然後主節點再通知叢集中的其他節點有新節點加入
3. 配置選舉發現數，及延長ping master的等待時長
discovery.zen.ping_timeout: 30（預設值是3秒）——其他節點ping主節點多久時間沒有響應就認為主節點不可用了
discovery.zen.minimum_master_nodes: 2 —— 選舉主節點時需要看到最少多少個具有master資格的活節點，才能進行選舉
說明：分片數指定後不可變，除非重索引。
思考：
分片對應的存儲實體是什麼？
存儲的實體是索引
分片是不是越多越好？
不是
分片多有什麼影響？
分片多浪費存儲空間、占用資源、影響性能
每個分片本質上就是一個lucene索引, 是以會消耗相應的檔案句柄, 記憶體和cpu資源。
每個搜尋請求會排程到索引的每個分片中. 如果分片分散在不同的節點倒是問題不太. 但當分片開始競争相同的硬體資源時, 性能便會逐漸下降。
es使用詞頻統計來計算相關性. 當然這些統計也會配置設定到各個分片上. 如果在大量分片上隻維護了很少的資料, 則将導緻最終的文檔相關性較差。
elasticsearch推薦的最大jvm堆空間是30~32g, 是以把你的分片最大容量限制為30gb, 然後再對分片數量做合理估算. 例如, 你認為你的資料能達到200gb, 推薦你最多配置設定7到8個分片。
在開始階段, 一個好的方案是根據你的節點數量按照1.5~3倍的原則來建立分片. 例如,如果你有3個節點, 則推薦你建立的分片數最多不超過9(3x3)個。當性能下降時，增加節點，es會平衡分片的放置。
對于基于日期的索引需求, 并且對索引資料的搜尋場景非常少. 也許這些索引量将達到成百上千, 但每個索引的資料量隻有1gb甚至更小. 對于這種類似場景, 建議隻需要為索引配置設定1個分片。如日志管理就是一個日期的索引需求，日期索引會很多，但每個索引存放的日志資料量就很少。
說明：副本數是可以随時調整的！
副本的用途是什麼？
備份資料保證高可用資料不丢失，高并發的時候參與資料查詢
針對它的用途，我們該如何設定它的副本數？
一般一個分片有1-2個副本即可保證高可用
叢集規模沒變的情況下副本過多會有什麼影響？
副本多浪費存儲空間、占用資源、影響性能
為保證高可用，副本數設定為2即可。要求叢集至少要有3個節點，來分開存放主分片、副本。
如發現并發量大時，查詢性能會下降，可增加副本數，來提升并發查詢能力。
注意：新增副本時主節點會自動協調，然後拷貝資料到新增的副本節點
192.168.152.128 、192.168.152.129、192.168.152.130
安裝教程參考我之前寫的文章的es的安裝和配置部分：
進入elasticsearch的config目錄，修改elasticsearch.yml的配置
這裡有兩個需要提醒下，第一個就是ip通路限制，第二個就是es執行個體的預設端口号9200。ip通路限制可以限定具體的ip通路伺服器，這有一定的安全過濾作用。
如果設定成0.0.0.0則是不限制任何ip通路。一般在生産的伺服器可能會限定幾台ip，通常用于管理使用。
預設的端口9200在一般情況下也有點風險，可以将預設的端口修改成另外一個，這還有一個原因就是怕開發人員誤操作，連接配接上叢集。當然，如果你的公司網絡隔離做的很好也無所謂。
這裡的9300是叢集内部通訊使用的端口，這個也可以修改掉。因為連接配接叢集的方式有兩種，通過扮演叢集node也是可以進入叢集的，是以還是安全起見，修改掉預設的端口。
說明：記得修改安裝了es的3台虛拟機（三個節點）的相同配置，要不然節點之間無法建立連接配接工作，也會報錯。
緊接着修改叢集節點ip位址，這樣可以讓叢集在規定的幾個節點之間工作。elasticsearch，預設是使用自動發現ip機制。就是在目前網段内，隻要能被自動感覺到的ip就能自動加入到叢集中。這有好處也有壞處。好處就是自動化了，當你的es叢集需要雲化的時候就會非常友善。但是也會帶來一些不穩定的情況，如，master的選舉問題、資料複制問題。
導緻master選舉的因素之一就是叢集有節點進入。當資料複制發生的時候也會影響叢集，因為要做資料平衡複制和備援。這裡面可以獨立master叢集，剔除master叢集的資料節點能力。
固定清單的ip發現有兩種配置方式，一種是互相依賴發現，一種是全量發現。各有優勢吧，我是使用的依賴發現來做的。這有個很重要的參考标準，就是你的叢集擴充速度有多快。因為這有個問題就是，當全量發現的時候，如果是初始化叢集會有很大的問題，就是master全局會很長，然後節點之間的啟動速度各不一樣。是以我采用了靠譜點的依賴發現。
你需要在192.168.152.128的elasticsearch中配置成：
讓他去發現129，130的機器，以此内推，完成剩下的129和130機器的配置。
然後你需要配置下叢集名稱，就是你目前節點所在叢集的名稱，這有助于你規劃你的叢集。叢集中的所有節點的叢集名稱必須一樣，隻有叢集名稱一樣才能組成一個邏輯叢集。
配置你目前節點的名稱
以此類推，完成另外兩個節點的配置。cluster.name的名稱必須保持一樣。然後分别設定node.name。
這裡搭建的是一個簡單的叢集，沒有做叢集節點角色的區分，是以3個節點預設的角色有主節點、資料節點、協調節點
選舉es主節點的邏輯：
選舉的大概邏輯，它會根據分片的資料的前後新鮮程度來作為選舉的一個重要邏輯。（日志、資料、時間都會作為叢集master全局的重要名額）
因為考慮到資料一緻性問題，當然是用最新的資料節點作為master，然後進行新資料的複制和重新整理其他node。
http://localhost:9200/_cat
為叢集提供安全防護、監控、告警、報告等功能的收費元件；
部分免費：https://www.elastic.co/subscriptions
6.3開始已開源，并并入了elasticsearch核心中。
官網安裝介紹：
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/installing-xpack-es.html