4 - 基于ELK的ElasticSearch 7.8.x技術整理 - 高級篇（ 續 ） - 更新完畢

0、前言

• 變更原由：昨晚更新博客之后，告知更新了，但是第一次出現有人看不到這篇博客，有人有看得到，我也不知道我設定了什么地方^_，所以我把原博客刪了，重新發布

另外：

• 這里面一些理論和前面的知識點掛鉤的，所以：建議看一下另外3篇知識內容
• 基礎篇：https://www.cnblogs.com/xiegongzi/p/15684307.html
• java操作篇：https://www.cnblogs.com/xiegongzi/p/15690534.html
• 高級篇1：https://www.cnblogs.com/xiegongzi/p/15757337.html

4.12、檔案搜索

4.12.1、不可變的倒排索引

• 以前的全文檢索是將整個檔案集合弄成一個倒排索引，然后存入磁盤中，當要建立新的索引時，只要新的索引準備就緒之后，舊的索引就會被替換掉，這樣最近的檔案資料變化就可以被檢索到

• 而索引一旦被存入到磁盤就是不可變的（ 永遠都不可以修改 ），而這樣做有如下的好處：

  • 1、只要索引被讀入到記憶體中了，由于其不變性，所以就會一直留在記憶體中（ 只要空間足夠 ），從而當我們做“讀操作”時，請求就會進入記憶體中去，而不會去磁盤中，這樣就減小開銷，提高效率了
  • 2、索引放到記憶體中之后，是可以進行壓縮的，這樣做之后，也就可以節約空間了
  • 3、放到記憶體中后，是不需要鎖的，如果自己的索引是長期不用更新的，那么就不用怕多行程同時修改它的情況了

• 當然：這種不可變的倒排索引有好處，那就肯定有壞處了“

  • 不可變，不可修改嘛，這就是最大的壞處，當要重定一個索引能夠被檢索時，就需要重新把整個索引構建一下，這樣的話，就會導致索引的資料量很大（ 資料量大小有限制了 ），同時要更新索引，那么這頻率就會降低了（ 這就好比是什么呢？關系型中的表，一張大表檢索資料、更新資料效率高不高？肯定不高，所以延伸出了：可變索引 ）

4.12.2、可變的倒排索引

又想保留不可變性，又想能夠實作倒排索引的更新，咋辦？

• 就搞出了補充索引，所謂的補充索引：有點類似于日志這個玩意兒，就是重建一個索引，然后用來記錄最近指定一段時間內的索引中檔案資料的更新，這樣更新的索引資料就記錄在補充索引中了，然后檢索資料時，直接找補充索引即可，這樣檢索時不再重寫整個倒排索引了，這有點類似于關系型中的拆表，大表拆小表嘛，但是啊：每一份補充索引都是一份單獨的索引啊，這又和分片很像，可是：查詢時是對這些補充索引進行輪詢，然后再對結果進行合并，從而得到最終的結果，這和前面說過的讀流程中說明的協調節點掛上鉤了

這里還需要了解一個配套的按段搜索，玩過 Lucene 的可能聽過，按段，每段也就可以理解為：補充索引，它的流程其實也很簡單：

• 1、新檔案被收集到記憶體索引快取

• 2、不時地提交快取

  • 2.1、一個新的段，一個追加的倒排索引，被寫入磁盤
  • 2.2、一個新的包含新段名字的提交點被寫入磁盤
  • 2.3、磁盤進行同步，所有在檔案系統快取中等待的寫入都重繪到磁盤，以確保它們被寫入物理檔案

• 3、新的段被開啟，讓它包含的檔案可見，以被搜索

• 4、記憶體快取被清空，等待接收新的檔案

• 一樣的，段在查詢的時候，也是輪詢的啊，然后把查詢結果合并從而得到的最終結果

• 另外就是涉及到洗掉的事情，段本身也是不可變的， 既不能把檔案從舊的段中移除，也不能修改舊的段來進行檔案的更新，而洗掉是因為：是段在每個提交點時有一個.del檔案，這個檔案就是一個洗掉的標志檔案，要洗掉哪些資料，就對該資料做了一個標記，從而下一次查詢的時候就過濾掉被標記的這些段，從而就無法查到了，這叫邏輯洗掉（ 當然：這就會導致倒排索引越積越多，再查詢時，輪詢來查資料也會影響效率 ），所以也有物理洗掉，它是把段進行合并，這樣就舍棄掉被洗掉標記的段了，從而最后重繪到磁盤中去的就是最新的資料（ 就是去掉洗掉之后的 ，別忘了前面整的段的流程啊，不是白寫的 ）

4.13、近實時搜索、檔案重繪、檔案刷寫、檔案合并

• ES的最大好處就是實時資料全文檢索，但是：ES這個玩意兒并不是真的實時的，而是近實時 / 準實時，原因就是：ES的資料搜索是分段搜索，最新的資料在最新的段中（ 每一個段又是一個倒排索引 ），只有最新的段重繪到磁盤中之后，ES才可以進行資料檢索，這樣的話，磁盤的IO性能就會極大的影響ES的查詢效率，而ES的目的就是為了：快速的、準確的獲取到我們想要的資料，因此：降低資料查詢處理的延遲就very 重要了，而ES對這方面做了什么操作？
  • 就是搞的一主多副的方式（ 一個主分片，多個副本分片 ），這雖然就是一句話概括了，但是：里面的門道卻不是那么簡單的

首先來看一下主副操作

• 但是：這種去找尋節點的程序想都想得到會造成延時，而延時 = 主分片延時 + 主分片拷貝資料給副本的延時

• 而且并不是這樣就算完了，前面提到了N多次的分段、重繪到磁盤還沒上堂呢，所以接著看
  

• 但是：在flush到磁盤中的時候，萬一斷電了呢？或者其他原因導致出問題了，那最后資料不就沒有flush到磁盤嗎，因此：其實還有一步操作，把資料保存到另外一個檔案中去
  

• 資料放到磁盤中之后，translog中的資料就會清空

• 同時更新到磁盤之后，用戶就可以進行搜索資料了

• 注意：這里要區分一下，資料庫中是先更新到log中，然后再更新到記憶體中，而ES是反著的，是先更新到Segment（ 可以直接認為是記憶體，因它本身就在記憶體中 ），再更新到log中

• 可是啊，還是有問題，flush刷寫到磁盤是很耗性能的，假如：不斷進行更新呢？這樣不斷進行IO操作，性能好嗎？也不行，因此：繼續改造（ 在Java的JDBC中我說過的 ———— 沒有什么是加一層解決不了的，一層不夠，那就再來一層 ）

• 加入了快取之后，這快取里面的資料是可以直接用來搜索的，這樣就不用等到flush到磁盤之后，才可以搜索了，這大大的提高了性能，而flush到磁盤，只要時間到了，讓它自個兒慢慢flush就可以了（ 作業系統快取中的資料斷電不會丟失啊，只會在下一次啟動的時候，繼續執行而已 ），上面這個流程也叫：持久化 / 持久化變更

• 寫入和打開一個新段的輕量的程序叫做refresh，默認情況下每個分片會每秒自動重繪一次，這就是為什么我們說 ES是近實時搜索：檔案的變化并不是立即對搜索可見，但會在一秒之內變為可見

  • 重繪是1s以內完成的，這是有時間間隙的，因此會造成：搜索一個檔案時，可能并沒有搜索到，因此：解決辦法就是使用refresh API重繪一下即可
  • 但是這樣也伴隨一個問題：雖然這種從記憶體重繪到快取中看起來不錯，但是還是有性能開銷的，并不是所有的情況都需要refresh的，假如：是在索引日志檔案呢？去refresh干嘛，浪費性能而已，所以此時：你要的是查詢速度，而不是近實時搜索，因此：可以通過一個配置來進行改動，從而降低每個索引的重繪頻率

	http://ip:port/index_name/_settings		# 請求方式：put

	# 請求體內容
	{
		"settings": {
			"refresh_interval": "60s"
		}
	}

• refresh_interval可以在既存索引上進行動態更新，在生產環境中，當你正在建立一個大的新索引時，可以先關閉自動重繪，待開始使用該索引時，再把它們調回來（ 雖然有點麻煩，但是按照ES這個玩意兒來說，確實需要這么做比較好 ）

	# 關閉自動重繪
	http://ip:port/users/_settings		# 請求方式：put

	# 請求體內容
	{ 
		"refresh_interval": -1 
	}

	# 每一秒重繪
	http://ip:port/users/_settings		# 請求方式：put
	# 請求體內容
	{ 
		"refresh_interval": "1s" 
	}

• 另外：不斷進行更新就會導致很多的段出現（ 在記憶體刷寫到磁盤哪里，會造成很多的磁盤檔案 ），因此：在哪里利用了檔案合并的功能（ 也就是段的能力，合并檔案，從而讓刷寫到磁盤中的檔案變成一份 ）
• 經過上面的思路了解之后，要是面試官問你資料庫的優化可以怎么弄？除了常見的，這個分段的思想、分片的思想就可以套上去了，當然再結合Redis的優化方式來回答，更beautiful，順帶還可以扯到Redis和ES來（ 面試造飛機，上班擰螺絲嘛，或者就是一部署完就在辦公室坐著摳腳 ），這就變成你牽著面試官的鼻子走，而不是他問什么，你去跟著它的思路回答，主動權在自己手上不香嗎，面試官面試一個人是有時間限制的，當然：要是不想扯到ES中來，直接根據情況大表拆小表也行

4.14、檔案分析

• 試想：我們在瀏覽器中，輸入一條資訊，如：搜索“博客園紫邪情”，為什么連“博客園也搜索出來了？我要的不是這個結果澀”
  

• 這就是全文檢索，就是ES干的事情（ 過濾資料、檢索嘛 ），但是：它做了哪些操作呢？

在ES中有一個檔案分析的程序，檔案分析的程序也很簡單：

• 將文本拆成適合于倒排索引的獨立的詞條，然后把這些詞條統一變為一個標準格式，從而使文本具有“可搜索性”

• 而這個檔案分析的程序在ES是由一個叫做“分析器 analyzer”的東西來做的，這個分析器里面做了三個步驟

  • 1、字符過濾器：就是用來處理一些字符的嘛，像什么將 & 變為 and 啊、去掉HTML元素啊之類的，它是文本字串在經過分詞之前的一個步驟，文本字串是按文本順序經過每個字串過濾器從而處理字串的

  • 2、分詞器：見名知意，就是用來分詞的，也就是將字串拆分成詞條（ 字 / 詞組 ），這一步和Java中String的split()一樣的，通過指定的要求，把內容進行拆分，如：空格、標點符號

  • 3、Token過濾器：這個玩意兒的作用就是 詞條經過每個Token過濾器，從而對資料再次進行篩選，如：字母大寫變小寫、去掉一些不重要的詞條內容、添加一些詞條（ 如：同義詞 ）

• 上述的內容不理解沒事，待會兒會用IK中文分詞器來演示，從而能夠更直觀的看到效果

在ES中，有提供好的內置分析器、我們也可以自定義、當然還有就是前面說的IK分詞器也可以做到（ 而重點需要了解的就是IK中文分詞器 ，寫到這里了，就突然想到一個事兒，牢騷一下：

• 就是有人私聊，說我博客廢話太多了，有些不需要的東西寫出來干什么？他只想快速上手，其他不相關的濾過比較好，所以我在想：不把事情的前因后果了解到，就直接開干好嗎？反正現在的我不把東西整明白，學東西都總感覺缺點什么，從而導致學的東西不是我想要的，這樣讓我學起來很不爽，雖然理論確實整起來煩得很，我曾經開始接觸Java的時候也是這么想的，就想著步子邁大一點，只管技術怎么用就行，理論哪些廢話我不想聽，可是后來步子邁大了，扯到了胯，后面研究另外一些深一點的東西時，我總覺得少了一些東西，邊研究邊百度，但是知識點是散的，那不是我想要的知識體系，這種更不爽（ 我個人偏向于：自己腦海有知識體系才好，但那時候學是散的，自己一邊整一邊摸索的 ），你敢相信我當初才用ES時，快速上手到什么地步？就了解了一些基礎理論、在linux中用docker-conpose.yml撰寫了ES和kibana的安裝方式（ ES和Kibana都在一個yml檔案中，就是我第三篇ES —— 高級篇博客中玩linux單機ES時說的那個yml安裝方式 ）、還有就是Java API各種常用的查詢方式，然后就沒了，結果后面自己吃了大虧，后面我是把Java重學了一遍，所以別相信什么所謂的“鍵盤不稀爛、代碼不停干”，只擼代碼，會處理人際關系那有個鳥用，理論是筑起高樓的地基，好了言歸正傳吧！！！

在演示在前，先玩kibana吧，原本打算放在后面的，但是越早熟悉越好嘛，所以先把kibana說明了

4.14.1、kibana

• 準備作業：去Elastic官網下載kibana，官網地址如下：

  • https://www.elastic.co/cn/downloads/?elektra=home&storm=hero
  • 這網站進去會很慢，進入之后就可以在首頁看到一個kibana了，但是需要注意：kibana的版本必須和ES的版本一致，在Java篇中已經說明過了，個人建議：把Windows版和linux版都下載了，玩的時候用Windows版的，linux版后續自己可能會用到

• 下載好了kibana之后，解壓到自己想要的目錄（ 注：解壓會有點久，因為是用Vue寫的，里面有模塊module 要是解壓快的話，可能還下錯了 ），然后點擊bin/kibana.bat即可啟動kibana
  

• 啟動之后就是上圖中的樣子，然后訪問圖中的地址即可，第一次進去會有一個選擇頁面，try / explore，選擇explore就可以了，進去之后就是如下界面
  

• 這是英文版，要是沒玩過大資料的話，那么里面的一些專業名詞根據英文來看根本不知道，所以：漢化吧，kibana本身就提供得有漢化的功能，只需要改動一個配置即可 —— 就是一個i18n配置而已

  • 進入config/kibana.yml，滑到最底部
    

  • 加上上面的資訊，然后重啟kibana就可以了（ 但是：個人建議，先漢化一段時間，等熟悉哪些名詞了，然后再轉成英文 ，總之最后建議用英文，一是增加英文詞匯量，二是熟悉英文專業詞 ，反正目前搞編程任何東西用英文比用漢語有優勢，因為好多東西都是歪果仁的 ）
    

  • 漢化成功

kibana遵循的是rest風格（ get、put、delete、post..... ），具體用法接下來玩分析器和后面都會慢慢熟悉

4.14.2、內置分析器

4.14.2.1、標準分析器 standard

• 這是根據Unicode定義的單詞邊界來劃分文本，將字母轉成小寫，去掉大部分的標點符號，從而得到的各種語言的最常用文本選擇，另外：這是ES的默認分析器，接下來演示一下

• 啟動ES（ 這是用的單機，即重新解壓啟動的那種，另外方式也可以玩，但沒演示 ）和kibana，打開控制臺
  

• 撰寫指令
  

	GET _analyze
	{
	  "analyzer": "standard", # analyzer 分析器  standard 標準分析器
	  "text": "my name is ZiXieQing" # text 文本標識   my name is ZiXieQing 自定義的文本內容
	}


	 # 回應內容
	{
	  "tokens" : [
		{
		  "token" : "my",		# 分詞之后的詞條
		  "start_offset" : 0,
		  "end_offset" : 2,		# start和end叫偏移量
		  "type" : "<ALPHANUM>",
		  "position" : 0	# 當前詞條在整個文本中所處的位置
		},
		{
		  "token" : "name",
		  "start_offset" : 3,
		  "end_offset" : 7,
		  "type" : "<ALPHANUM>",
		  "position" : 1
		},
		{
		  "token" : "is",
		  "start_offset" : 8,
		  "end_offset" : 10,
		  "type" : "<ALPHANUM>",
		  "position" : 2
		},
		{
		  "token" : "zixieqing",
		  "start_offset" : 11,
		  "end_offset" : 20,
		  "type" : "<ALPHANUM>",
		  "position" : 3
		}
	  ]
	}

• 從上圖可以看出：所謂標準分析器是將文本通過標點符號來分詞的（ 空格、逗號... ，不信可以自行利用這些標點測驗一下，觀察右邊分詞的結果 ），同時大寫轉小寫
  

4.14.2.2、簡單分析器 simple

• 簡單分析器是“按非字母的字符分詞，例如：數字、標點符號、特殊字符等，會去掉非字母的詞，大寫字母統一轉換成小寫”
  

4.14.2.3、空格分析器 whitespace

• 是簡單按照空格進行分詞，相當于按照空格split了一下，大寫字母不會轉換成小寫
  

4.14.2.4、去詞分析器 stop

• 會去掉無意義的詞（ 此無意義是指語氣助詞等修飾性詞，補語文：語氣詞是疑問語氣、祈使語氣、感嘆語氣、肯定語氣和停頓語氣 ），例如：the、a、an 、this等，大寫字母統一轉換成小寫
  

4.14.2.5、不拆分分析器 keyword

• 就是將整個文本當作一個詞
  

4.14.3、IK中文分詞器

• 來個實驗
  

• 它把我的名字進行拆分了，這不是我想要的，我想要的“紫邪情”應該是一個完整的詞，同樣道理：想要特定的詞匯，如：ID號、用戶名....，這些不應該拆分，而ES內置分析器并不能做到，所以需要IK中文分詞器（ 專門用來處理中文的 ）

• 1、下載IK分詞器

  • https://github.com/medcl/elasticsearch-analysis-ik/releases/tag/v7.8.0
  • 注意：版本對應關系，還是和ES版本對應，https://github.com/medcl/elasticsearch-analysis-ik 這個鏈接進去之后有詳細的版本對應
    
  • 要是感覺github下載慢的話，我把阿里云盤更新了一遍，那里面放出來的包有7.8.0的版本，這里面也有一些其他的東西，有興趣的下載即可，另外：在這里面有一個chrome-plugin包，這里面有一些chrome的插件，其中有一個fast-github，即：github下載加速器，可以集成到瀏覽器中，以后下載github的東西就不限速了，云盤鏈接是：https://www.aliyundrive.com/s/oVC6WWthpUb
    

• fast-github集成到goole之后如下：
  

• 這樣以后下載github的東西時，就有一個加速下載了，點擊即可快速下載，如：
  

• 2、把IK解壓到ES/plugins中去，如我的：
  

• 3、重啟ES即可（ kibana開著的話，也要關了重啟 ），注意觀察：重啟時會有一個IK加載程序
  

• 經過如上的操作之后，IK中文分詞器就配置成功了，接下來就來體驗一下（ 啟動ES和kibana ），主要是為了了解IK中的另外兩種分詞方式：ik_max_word和ik_smart

• ik_max_word是細粒度的分詞，就是：窮盡詞匯的各種組成
  

• ik_smart是粗粒度的分詞
  

• 回到前面的問題，“紫邪情”是名字，我不想讓它分詞，怎么做？上面哪些分詞都是在一個“詞典”中，所以我們自己搞一個詞典即可

• 1、創建一個.dic檔案 dic就是dictionary詞典的簡寫
  

• 2、在創建的dic檔案中添加不分詞的詞組，保存
  

• 3、把自定義的詞典放到ik中去，保存
  

• 4、重啟ES和kibana

• 5、測驗
  

• 可見，現在就把“紫邪情”組成詞組不拆分了，前面玩的kibana漢化是怎么做的？和這個的原理差不多

4.14.4、自定義分析器

• 這里還有一個自定義分析器的知識點，這個不了解也罷，有興趣的自行百度百科了解一下

4.14.5、多玩幾次kibana

• 在第一篇高級篇中我便說過：kibana重要，只是經過前面這些介紹了使用之后，并不算熟悉，因此：多玩幾次吧

• 另外：就是前面說的kibana遵循rest風格，在ES中是怎么玩的？總結下來其實就下面這些，要上手簡單得很，但理論卻是一直弄到現在
  

• 現在用kibana來演示幾個，其他的內容在在postman中怎么弄，換一下即可（ 其實不建議用postman測驗，但是：前面用的一直是postman，專業的人做專業的事，kibana才是我們后端玩的 ）

• 1、創建索引
  

• 2、查看索引
  

• 3、洗掉索引
  

• 4、創建檔案（ 自定義id ）
  

• 5、查看檔案（ 通過id查詢 ）
  

• 6、修改檔案（ 區域修改 ）
  

  • 驗證一下：
    

• 7、建欄位型別
  

• 其他的也是差不多的玩法，在基礎篇中怎么玩，稍微變一下就是kibana的玩法了

4.15、檔案控制（ 了解即可 ）

• 所謂的檔案控制就是：不斷更新的情況，試想：多行程不斷去更新檔案，會造成什么情況？會把其他人更新過的檔案進行覆寫更新了，而ES是怎么解決這個問題的？

• 就是弄了一個鎖來實作的，和Redis一樣，也是用的樂觀鎖來實作的，這個其實沒什么好說的，只需要看一下就知道了
  

• 上圖中的三個欄位就和鎖掛鉤的，version，版本號嘛，每次更新都會有一個版本號，這樣就解決了多行程修改從而造成的檔案沖突了（ 必須等到一個行程更新完了，另一個行程才可以更新，才可以拿到版本號嘛 ），當然：需要注意舊版本的ES在請求中加上version即可，但是新版本的ES需要使用 "if_seq_no=value" & "if_primary_term" =value來達到version的效果( 這兩個欄位一樣的放在請求路徑中即可 )

4.16、ES的優化

• ES的所有索引和檔案資料都是存盤在本地的磁盤中的，所以：磁盤能處理的吞吐量越大，節點就越穩定

• 要修改的話，是在config/elasticsearch.yml中改動
  

4.16.1、硬體方面

• 1、選用固態硬碟（ 即：SSD ），它比機械硬碟好是因為：機械硬碟是通過旋轉馬達的驅動來進行的，所以這就會造成發熱、磨損，就會影響ES的效率，而SSD是使用芯片式的閃存來存盤資料的，性能比機械硬碟好得多

• 2、使用RAID 0 （ 獨立磁盤冗余陣列 ），它是把連續的資料分散到多個磁盤上存取，這樣，系統有資料請求就可以被多個磁盤并行的執行，每個磁盤執行屬于它自己的那部分資料請求，這種資料上的并行操作可以充分利用總線的帶寬，顯著提高磁盤整體存取性（ 不了解總線和帶寬的，真的有必要去學一下：計算機組成原理，這個知識在計算機組成原理的資料總線那里有 ， 當然：面向百度簡單了解一下也行 ）
  

• 3、由上面的RAID 0可以聯想到另外一個解決方式：使用多塊硬碟，也就可以達到同樣的效果了（ 有錢就行 ），是通過path data目錄配置把資料條分配到這些磁盤上面

• 4、不要把ES掛載到遠程上去存盤

4.16.2、分片策略

• 分片和副本不是亂分配的！分片處在不同節點還可以（ 前提是節點中存的資料多 ），這樣就類似于關系型中分表，確實可以算做是優化，但是：如果一個節點中有多個分片了，那么就會造成分片之間的資源競爭，也就會導致性能降低

所以分片和副本遵循下面的原則就可以了

• 1、每個分片占用的磁盤容量不得超過ES的JVM的堆空間設定（ 一般最大為32G ），假如：索引容量為1024G，那么節點數量為：1024 / 32 = 32左右

• 2、分片數不超過節點數的3倍，就是為了預防一個節點上有多個分片的情況，萬一當前節點死了，那么就算做了副本，也很容易導致集群丟失資料

• 3、節點數 <= 主節點數 * （ 副本數 + 1 ）

• 4、推遲分片分配

  • 有可能一個節點宕掉了，但是后面它又恢復了，而這個節點原有資料是還在的，所以：推遲分片分配，從而減少ES的開銷，具體做法如下：

PUT /_all/_settings
{
	"settings": {
		"index.unassigned.node_left.delayed_timeout": "5m"
	}
}

• 可以全域修改，也可以在建索引時修改

4.16.3、帶路由查詢

• 前面說過：路由計算公式 shard = hash( routing ) % number_of_primary_shards

• 而routing默認值就是檔案id，所以查詢時把檔案id帶上，如：前面玩kibana做的操作
  

• 不帶路由就會把分片和副本都查出來，然后進行輪詢，這效率想都想得到會慢一點嘛

4.16.4、記憶體優化

• 修改es的config/jvm.options
  

• 把上面的數字改了，Xms 表示堆的初始大小， Xmx 表示可分配的最大記憶體，ES默認是1G，這個數字在現實中是遠遠不夠了，改它的目的是：為了能夠在 Java 垃圾回識訓制清理完堆記憶體后不需要重新分隔計算堆記憶體的大小而浪費資源，可以減輕伸縮堆大小帶來的壓力，但是也需要注意：改這兩個數值，需要確保 Xmx 和 Xms 的大小是相同的，另外就是：這兩個數值別超過32G啊，前面已經講過了

4.17、附上一些配置說明

4.18、SpringBoot集成ES

• ES官方學習檔案中有，鏈接是：https://www.elastic.co/guide/index.html
  

• 然后點擊other version，選擇對應的版本，如：我的是7.8
  

• 這里面樣都有，點擊：getting started看一下
  

• 選擇maven
  

<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-high-level-client</artifactId>
    <version>7.8.0</version>
</dependency>

• 建議：有時間去研究一下官網

• java操作篇鏈接：https://www.cnblogs.com/xiegongzi/p/15690534.html

4.19、說一些另外的理論吧

4.19.1、ES的master主節點選舉流程

• 1、首先選主是由ZenDiscovery來完成的（ 它做了兩件事：一個是Ping程序 ———— 發現節點嘛 、二是Unicast程序 ———— 控制哪些節點需要Ping通 ）

• 2、對所有可以成為master的節點（ 檔案中設定的node.master: true ）根據nodeId字典排序，每次“選舉節點（ 即：參與投票選舉主節點的那個節點 ）”都把自己知道的節點排一次序，就是把排好序的第一個節點（ 第0位 ）認為是主節點（ 投一票 ）

• 3、當某個節點的投票數達到一個值時（ （ 可以成為master節點數n / 2 ） + 1 ），而該節點也投自己，那么這個節點就是master節點，否則重新開始，直到選出master

• 另外注意：master節點的職責主要包括集群、節點和索引的管理，不負責檔案級別的管理；data節點可以關閉http功能

4.19.2、ES的集群腦裂問題

導致的原因：

• 網路問題：集群間的網路延遲導致一些節點訪問不到master, 認為master 掛掉了從而選舉出新的master,并對master上的分片和副本標紅，分配新的主分片
• 節點負載：主節點的角色既為master又為data,訪問量較大時可能會導致ES停止回應造成大面積延遲，此時其他節點得不到主節點的回應認為主節點掛掉了，會重新選取主節點
• 記憶體回收：data 節點上的ES行程占用的記憶體較大，引發JVM的大規模記憶體回收，造成ES行程失去回應

腦裂問題解決方案：

• 減少誤判：discovery.zen ping_ timeout 節點狀態的回應時間，默認為3s，可以適當調大，如果master在該回應時間的范圍內沒有做出回應應答，判斷該節點已經掛掉了，調大引數（ 如6s，discovery.zen.ping_timeout:6 ），可適當減少誤判

• 選舉觸發：discovery.zen.minimum. master nodes:1，該參數是用于控制選舉行為發生的最小集群主節點數量，當備選主節點的個數大于等于該引數的值，且備選主節點中有該引數個節點認為主節點掛了，進行選舉，官方建議為(n / 2) +1, n為主節點個數（即有資格成為主節點的節點個數）

• 角色分離：即master節點與data節點分離，限制角色

  • 主節點配置為：node master: true，node data: false
  • 從節點置為：node master: false，node data: true

4.20、最后的最后

• 1、讓我弄知識點的哪些人，可能會讓你們失望了，原本我的打算是后續集合SpringBoot+Redis+ES做一個小Demo，但是：最近沒時間弄了，我需要去做另外一件重要的事情，因此：你們想鞏固ES知識的，去網上找ES實操專案吧

• 2、你們這些人，看完了我博客的全系列ES知識、把實操專案弄了之后，記得再搜一下：ES面試題

  • 我在阿里云盤中上傳了一些面試題，Java全系列的，那里面也有資料獲取地的公眾號二維碼，今后要最新的面試題就去哪里找吧，但是有些問題答案沒有，所以需要自己總結一些東西，而且有些回答有問題，所以需要自己甄別一下，面試題答案不是死的，要靈活用，主要關注的是面試的問題是什么？同時：我個人認為，那上面的面試題確實算弄到點上的
  • 云盤鏈接：https://www.aliyundrive.com/s/V6pPCAFZWnD

標籤：其他

上一篇：德哥PostgreSQL學習資料匯總

下一篇：[20220106]ora-00600 kokasgi1.txt