目錄

• 1 Elasticsearch安裝
  • 1.1 版本介紹
  • 1.2 單機
    • 1.2.1 下載
    • 1.2.2 安裝配置
      • 1.2.2.1 Elasticsearch
      • 1.2.2.2 IK分詞器
    • 1.2.3 報錯
  • 1.3 叢集（Cluster）
    • 1.3.1 叢集健康狀態
    • 1.3.2 發現機制
    • 1.3.3 節點的角色
    • 1.3.4 腦裂現象
      • 1.3.3.1 發生原因
      • 1.3.4.2 避免腦裂

1 Elasticsearch安裝

1.1 版本介紹

在決定使用 Elasticsearch 的時候首先要考慮的是版本問題，Elasticsearch （排除 0.x 和 1.x）目前有如下常用的穩定的主版本：2.x，5.x，6.x，7.x（current）

。
可能會發現沒有 3.x 和 4.x，ES 從 2.4.6 直接跳到了 5.0.0。其實是為了 ELK（ElasticSearch，Logstash，Kibana）技術棧的版本統一，免的給使用者帶來混亂。
在 Elasticsearch 是 2.x （2.x 的最後一版 2.4.6 的釋出時間是 July 25, 2017） 的情況下，Kibana 已經是 4.x（Kibana 4.6.5 的釋出時間是 July 25, 2017）。那麼在 Kibana 的下一主版本肯定是 5.x 了，所以 Elasticsearch 直接將自己的主版本釋出為 5.0.0 了。
統一之後，我們選版本就不會猶豫困惑了，我們選定 Elasticsearch 的版本後再選擇相同版本的 Kibana 就行了，不用擔憂版本不相容的問題。
Elasticsearch 是使用 Java 構建，所以除了注意 ELK 技術的版本統一，我們在選擇 Elasticsearch 的版本的時候還需要注意 JDK 的版本。
因為每個大版本所依賴的 JDK 版本也不同，目前 7.2 版本已經可以支援 JDK11

1.2 單機

1.2.1 下載

官網下載：https://www.elastic.co/cn/downloads/elasticsearch#ga-release
下載linux版本有兩個選擇：

• x86_64：就是我們常用的桌上型電腦的體系架構，是基於馮諾依曼體系架構的。x86_64 Linux
  可以理解為在普通桌上型電腦上安裝的Linux作業系統。
• AArch64：是一種ARMv8架構，也是一種計算機的體系架構。AArch64 Linux可以理解為在ARMv8架構的計算機上安裝的Linux作業系統。

使用Linux命令arch檢視核心版本

[root@root ~]# arch
x86_64

如果用到了中文分詞還需要下載ik分詞器：https://github.com/medcl/elasticsearch-analysis-ik，如果不能訪問github，就用國內的這個gitee也可以：https://gitee.com/mirrors/elasticsearch-analysis-ik/tree/master/
注意：IK分詞器外掛的版本要和ElasticSearch的版本一致
下載解壓之後放到elasticsearch/pluging目錄下面新建一個名字為ik的資料夾即可使用

1.2.2 安裝配置

1.2.2.1 Elasticsearch

下載和解壓 Elasticsearch，無需安裝解壓後即可用，解壓後目錄如上圖：

• bin：二進位制系統指令目錄，包含啟動命令和安裝外掛命令等。
• config：配置檔案目錄。
• data：資料儲存目錄。
• lib：依賴包目錄。
• logs：日誌檔案目錄。
• modules：模組庫，例如 x-pack 的模組。
• plugins：外掛目錄。

修改配置檔案，在config下邊的配置檔案：elasticserach.yml
將裡邊的network,host放開 然後將ip修改為0.0.0.0，http.port放開

network.host: 0.0.0.0
http.port: 9200

安裝目錄下執行 bin/elasticsearch 來啟動 ES。
預設在 9200 埠執行，請求 curl http://localhost:9200/ 或者瀏覽器輸入 http://localhost:9200，得到一個 JSON 物件，其中包含當前節點、叢集、版本等資訊。

{  
  "name" : "U7fp3O9",  
  "cluster_name" : "elasticsearch",  
  "cluster_uuid" : "-Rj8jGQvRIelGd9ckicUOA",  
  "version" : {  
    "number" : "6.8.1",  
    "build_flavor" : "default",  
    "build_type" : "zip",  
    "build_hash" : "1fad4e1",  
    "build_date" : "2019-06-18T13:16:52.517138Z",  
    "build_snapshot" : false,  
    "lucene_version" : "7.7.0",  
    "minimum_wire_compatibility_version" : "5.6.0",  
    "minimum_index_compatibility_version" : "5.0.0"  
  },  
  "tagline" : "You Know, for Search"  
}

1.2.2.2 IK分詞器

IKAnalyzer.cfg.xml檔案ES 目錄/plugins/ik/config/IKAnalyzer.cfg.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
        <comment>IK Analyzer 擴充套件配置</comment>
        <!--使用者可以在這裡配置自己的擴充套件字典 -->
        <entry key="ext_dict"></entry>
         <!--使用者可以在這裡配置自己的擴充套件停止詞字典-->
        <entry key="ext_stopwords"></entry>
        <!--使用者可以在這裡配置遠端擴充套件字典 -->
        <!-- <entry key="remote_ext_dict">words_location</entry> -->
        <!--使用者可以在這裡配置遠端擴充套件停止詞字典-->
        <!-- <entry key="remote_ext_stopwords">words_location</entry> -->
</properties>

擴充套件字典中的詞會被篩選出來，擴充套件停止詞中的詞會被過濾掉

1.2.3 報錯

• 報錯一：can not run elasticsearch as root
  es因為安全問題拒絕使用root使用者啟動
  解決方法:

  1. 新增使用者組:es，使用者:es,she，設定密碼
  2. 新增目錄擁有許可權
     groupadd es
     useradd es -g es -p password # -g 指定組 -p 密碼
     chown es:es -R elasticsearch-7.10.0/ # -R 處理指定目錄以及其子目錄下的所有檔案
  3. 切換到es使用者，啟動
     su es
     ./elasticsearch
     ./elasticsearch -d #後臺方式啟動

• 報錯二：ignoring JAVA_HOME="XXXXX"； using bundled JDK JDK版本不對
elasticsearch支援JDK1.8的，僅僅是7.17.3及其之前的版本。如果下的最新版本，最低JDK得17及其以上。
  win7建議下載7.6.1的版本，7.17.3需要win8和最低node.js 12.0.0版本

• 報錯三：ik分詞器，報錯plugin-descriptor.properties
  分析：由於是java開發的分詞器，這裡很明顯是maven專案的目錄結構。所以要執行打包命令，生成對應的釋出的包
  在ES中存放中文分詞器的ik目錄下執行mvn clean install命令，完成後在你target目錄下的release中會有以下包，這些才是我們所需要的，用這些去替換ik中的檔案。
  

• 報錯四：對ik分詞器專案打包時，提示類檔案具有錯誤的版本 61.0, 應為 52.0
  原因
  SpringBoot使用了3.0或者3.0以上，因為Spring官方釋出從Spring6以及SprinBoot3.0開始最低支援JDK17，所以僅需將SpringBoot版本降低為3.0以下即可

1.3 叢集（Cluster）

ES的叢集搭建很簡單，不需要依賴第三方協調管理元件，自身內部就實現了叢集的管理功能。
ES 叢集由一個或多個 Elasticsearch 節點組成，每個節點配置相同的 cluster.name 即可加入叢集，預設值為elasticsearch。
確保不同的環境中使用不同的叢集名稱，否則最終會導致節點加入錯誤的叢集。
一個Elasticsearch服務啟動例項就是一個節點（Node）。節點通過 node.name 來設定節點名稱，如果不設定則在啟動時給節點分配一個隨機通用唯一識別符號作為名稱。

1.3.1 叢集健康狀態

要檢查群集執行狀況，我們可以在 Kibana 控制檯中執行以下命令 GET /_cluster/health，得到如下資訊：

{  
  "cluster_name" : "wujiajian",  
  "status" : "yellow",  
  "timed_out" : false,  
  "number_of_nodes" : 1,  
  "number_of_data_nodes" : 1,  
  "active_primary_shards" : 9,  
  "active_shards" : 9,  
  "relocating_shards" : 0,  
  "initializing_shards" : 0,  
  "unassigned_shards" : 5,  
  "delayed_unassigned_shards" : 0,  
  "number_of_pending_tasks" : 0,  
  "number_of_in_flight_fetch" : 0,  
  "task_max_waiting_in_queue_millis" : 0,  
  "active_shards_percent_as_number" : 64.28571428571429  
} 

叢集狀態通過 綠，黃，紅 來標識：

• 綠色：叢集健康完好，一切功能齊全正常，所有分片和副本都可以正常工作。
• 黃色：預警狀態，所有主分片功能正常，但至少有一個副本是不能正常工作的。此時叢集是可以正常工作的，但是高可用性在某種程度上會受影響。
• 紅色：叢集不可正常使用。某個或某些分片及其副本異常不可用，這時叢集的查詢操作還能執行，但是返回的結果會不準確。對於分配到這個分片的寫入請求將會報錯，最終會導致資料的丟失。
  當叢集狀態為紅色時，它將會繼續從可用的分片提供搜尋請求服務，但是你需要儘快修復那些未分配的分片

1.3.2 發現機制

那麼有一個問題，ES 內部是如何通過一個相同的設定 cluster.name 就能將不同的節點連線到同一個叢集的？答案是 Zen Discovery。
Zen Discovery 是 Elasticsearch 的內建預設發現模組（發現模組的職責是發現叢集中的節點以及選舉 Master 節點）。
它提供單播和基於檔案的發現，並且可以擴充套件為通過外掛支援雲環境和其他形式的發現。

Zen Discovery 與其他模組整合，例如，節點之間的所有通訊都使用 Transport 模組完成。節點使用發現機制通過 Ping 的方式查詢其他節點。

Elasticsearch 預設被配置為使用單播發現，以防止節點無意中加入叢集。只有在同一臺機器上執行的節點才會自動組成叢集。如果叢集的節點執行在不同的機器上，使用單播，可以為 Elasticsearch 提供一些它應該去嘗試連線的節點列表。
當一個節點聯絡到單播列表中的成員時，它就會得到整個叢集所有節點的狀態，然後它會聯絡 Master 節點，並加入叢集。
這意味著單播列表不需要包含叢集中的所有節點， 它只是需要足夠的節點，當一個新節點聯絡上其中一個並且說上話就可以了。

如果使用 Master 候選節點作為單播列表，只要列出三個就可以了。這個配置在 elasticsearch.yml 檔案中：

discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]  

節點啟動後先 Ping ，如果 discovery.zen.ping.unicast.hosts 有設定，則 Ping 設定中的 Host ，否則嘗試 ping localhost 的幾個埠。
Elasticsearch 支援同一個主機啟動多個節點，Ping 的 Response 會包含該節點的基本資訊以及該節點認為的 Master 節點。
選舉開始，先從各節點認為的 Master 中選，規則很簡單，按照 ID 的字典序排序，取第一個。如果各節點都沒有認為的 Master ，則從所有節點中選擇，規則同上。這裡有個限制條件就是 discovery.zen.minimum_master_nodes ，如果節點數達不到最小值的限制，則迴圈上述過程，直到節點數足夠可以開始選舉。

最後選舉結果是肯定能選舉出一個 Master ，如果只有一個 Local 節點那就選出的是自己。
如果當前節點是 Master ，則開始等待節點數達到 discovery.zen.minimum_master_nodes，然後提供服務。
如果當前節點不是 Master ，則嘗試加入 Master 。Elasticsearch 將以上服務發現以及選主的流程叫做 Zen Discovery 。

由於它支援任意數目的叢集（ 1- N ），所以不能像 Zookeeper 那樣限制節點必須是奇數，也就無法用投票的機制來選主，而是通過一個規則。
只要所有的節點都遵循同樣的規則，得到的資訊都是對等的，選出來的主節點肯定是一致的。

但分散式系統的問題就出在資訊不對等的情況，這時候很容易出現腦裂（Split-Brain）的問題。大多數解決方案就是設定一個 Quorum 值，要求可用節點必須大於 Quorum（一般是超過半數節點），才能對外提供服務。
而 Elasticsearch 中，這個 Quorum 的配置就是 discovery.zen.minimum_master_nodes

1.3.3 節點的角色

每個節點既可以是候選主節點也可以是資料節點，通過在配置檔案 ../config/elasticsearch.yml 中設定即可，預設都為 true。

node.master: true  //是否候選主節點  
node.data: true    //是否資料節點  

資料節點負責資料的儲存和相關的操作，例如對資料進行增、刪、改、查和聚合等操作，所以資料節點（Data 節點）對機器配置要求比較高，對 CPU、記憶體和 I/O 的消耗很大。

通常隨著叢集的擴大，需要增加更多的資料節點來提高效能和可用性。
候選主節點可以被選舉為主節點（Master 節點），叢集中只有候選主節點才有選舉權和被選舉權，其他節點不參與選舉的工作。

主節點負責建立索引、刪除索引、跟蹤哪些節點是群集的一部分，並決定哪些分片分配給相關的節點、追蹤叢集中節點的狀態等，穩定的主節點對叢集的健康是非常重要的。

一個節點既可以是候選主節點也可以是資料節點，但是由於資料節點對 CPU、記憶體核 I/O 消耗都很大。所以如果某個節點既是資料節點又是主節點，那麼可能會對主節點產生影響從而對整個叢集的狀態產生影響。

因此為了提高叢集的健康性，我們應該對 Elasticsearch 叢集中的節點做好角色上的劃分和隔離。可以使用幾個配置較低的機器群作為候選主節點群。

主節點和其他節點之間通過 Ping 的方式互檢查，主節點負責 Ping 所有其他節點，判斷是否有節點已經掛掉。其他節點也通過 Ping 的方式判斷主節點是否處於可用狀態。

雖然對節點做了角色區分，但是使用者的請求可以發往任何一個節點，並由該節點負責分發請求、收集結果等操作，而不需要主節點轉發。
這種節點可稱之為協調節點，協調節點是不需要指定和配置的，叢集中的任何節點都可以充當協調節點的角色。

1.3.4 腦裂現象

1.3.3.1 發生原因

如果由於網路或其他原因導致叢集中同時選舉出多個 Master 節點，使得資料更新時出現不一致，這種現象稱之為腦裂，即叢集中不同的節點對於 Master 的選擇出現了分歧，出現了多個 Master 競爭。

腦裂問題可能有以下幾個原因造成：

• 網路問題： 叢集間的網路延遲導致一些節點訪問不到 Master，認為 Master 掛掉了從而選舉出新的 Master，並對 Master 上的分片和副本標紅，分配新的主分片。
• 節點負載： 主節點的角色既為 Master 又為 Data，訪問量較大時可能會導致 ES 停止響應（假死狀態）造成大面積延遲，此時其他節點得不到主節點的響應認為主節點掛掉了，會重新選取主節點。
• 記憶體回收： 主節點的角色既為 Master 又為 Data，當 Data 節點上的 ES 程序佔用的記憶體較大，引發 JVM 的大規模記憶體回收，造成 ES 程序失去響應。

1.3.4.2 避免腦裂

為了避免腦裂現象的發生，我們可以從原因著手通過以下幾個方面來做出優化措施：

• 適當調大響應時間，減少誤判。 通過引數 discovery.zen.ping_timeout 設定節點狀態的響應時間，預設為 3s，可以適當調大。
  如果 Master 在該響應時間的範圍內沒有做出響應應答，判斷該節點已經掛掉了。調大引數（如 6s，discovery.zen.ping_timeout:6），可適當減少誤判。
• 選舉觸發。 我們需要在候選叢集中的節點的配置檔案中設定引數 discovery.zen.minimum_master_nodes 的值。這個引數表示在選舉主節點時需要參與選舉的候選主節點的節點數，預設值是 1，官方建議取值master候選節點數量/2+1
  這樣做既能防止腦裂現象的發生，也能最大限度地提升叢集的高可用性，因為只要不少於 discovery.zen.minimum_master_nodes 個候選節點存活，選舉工作就能正常進行。當小於這個值的時候，無法觸發選舉行為，叢集無法使用，不會造成分片混亂的情況。
• 角色分離。 即是上面我們提到的候選主節點和資料節點進行角色分離，這樣可以減輕主節點的負擔，防止主節點的假死狀態發生，減少對主節點“已死”的誤判。