Elasticsearch 運(yùn)維實(shí)踐
點(diǎn)擊上方“IT那活兒”公眾號(hào)，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了?。。?/strong>
對(duì)于Elasticsearch的學(xué)習(xí)，需要清楚的明白它的每個(gè)核心概念，由淺入深的了解，才能更好的掌握這門技術(shù)。下面先簡(jiǎn)單羅列下Elasticsearch的核心概念：
Elasticsearch數(shù)據(jù)組織如下圖所示，Elasticsearch使用index和doc_type來(lái)組織數(shù)據(jù)。doc_type中的每條數(shù)據(jù)稱為一個(gè)document，是一個(gè)JSON Object，相關(guān)的schema信息通過(guò)mapping來(lái)定義。mapping不僅僅包括數(shù)據(jù)類型的定義，還有很多其他元信息的設(shè)置，它們共同決定了數(shù)據(jù)如何被存儲(chǔ)和索引。這四個(gè)概念實(shí)現(xiàn)了Elasticsearch的邏輯數(shù)據(jù)組織，假設(shè)有一批結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)需要存儲(chǔ)，我們會(huì)先對(duì)數(shù)據(jù)進(jìn)行分類，設(shè)計(jì)相應(yīng)的index與doc_type，再為每個(gè)doc_type設(shè)置相關(guān)的mapping信息。如果不指定mapping，Elasticsearch會(huì)使用默認(rèn)值，并自動(dòng)為你推導(dǎo)每個(gè)字段的類型，即支持schema free的特性。但是，這種靈活性也會(huì)帶來(lái)一些問(wèn)題，一方面會(huì)失去對(duì)數(shù)據(jù)的控制，即會(huì)越來(lái)越不清楚你的數(shù)據(jù)結(jié)構(gòu)，另一方面，自動(dòng)推導(dǎo)出來(lái)數(shù)據(jù)類型可能不是預(yù)期的，會(huì)帶來(lái)寫入和查詢問(wèn)題。所以，筆者建議，盡最大可能對(duì)schema加以約束。通常情況下，我們都會(huì)拿Elasticsearch的這些概念跟關(guān)系型數(shù)據(jù)庫(kù)Mysql來(lái)做對(duì)比以便更好的理解，比如index等價(jià)于database，doc_type等價(jià)于table，mapping等價(jià)于db schema。但是需要注意的是：對(duì)于關(guān)系型數(shù)據(jù)庫(kù)而言，table與table之間是完全獨(dú)立的，不同table的schema是完全隔離的，而Elasticsearch中的doc_type則不是。同一個(gè)index下不同doc_type中的字段在底層是合并在一起存儲(chǔ)的，意味著假設(shè)兩個(gè)doc_type中都有一個(gè)叫name的字段，那么這兩個(gè)字段的mapping必須一樣。基于這個(gè)原因，Elasticsearch官方從6.0開始淡化doc_type的概念，推薦一個(gè)index只擁有一個(gè)doc_type，并計(jì)劃在8.x完全廢棄doc_type。因此，在當(dāng)前的index設(shè)計(jì)中，最好能遵循這個(gè)規(guī)則。Elasticsearch是一個(gè)分布式系統(tǒng)，其數(shù)據(jù)會(huì)分散存儲(chǔ)到不同的節(jié)點(diǎn)上。為了實(shí)現(xiàn)這一點(diǎn)，需要將每個(gè)index中的數(shù)據(jù)劃分到不同的塊中，然后將這些數(shù)據(jù)塊分配到不同的節(jié)點(diǎn)上存儲(chǔ)。這里的數(shù)據(jù)塊，就是shard。通過(guò)"分"的思想，可以突破單機(jī)在存儲(chǔ)空間和處理性能上的限制，這是分布式系統(tǒng)的核心目的。而對(duì)于分布式存儲(chǔ)而言，還有一個(gè)重要特性是"冗余"，因?yàn)榉植际降那疤崾牵航邮芟到y(tǒng)中某個(gè)節(jié)點(diǎn)因?yàn)槟承┕收贤顺觥?/span>為了保證在故障節(jié)點(diǎn)退出后數(shù)據(jù)不丟失，同一份數(shù)據(jù)需要拷貝多份存在不同節(jié)點(diǎn)上。因此，shard從角色上劃分為primary shard和replica shard兩種，數(shù)據(jù)會(huì)首先寫入primary shard，然后同步到replica shard中。shard是Elasticsearch中最小的數(shù)據(jù)分配單位，即一個(gè)shard總是作為一個(gè)整體被分配到某個(gè)節(jié)點(diǎn)，而不會(huì)只分配其中一部分。那么，shard中的數(shù)據(jù)又是如何組織的？答案是segment。一個(gè)shard包含一組segment，segment是最小的數(shù)據(jù)單元，Elasticsearch每隔一段時(shí)間產(chǎn)生一個(gè)新的segment，里面包含了新寫入的數(shù)據(jù)。segment是immutable的，即不可改變，這樣設(shè)計(jì)的考量是：一方面，不支持修改就不用對(duì)讀寫操作加鎖，省去了相關(guān)開銷；另一方面，因?yàn)槲募?nèi)容不會(huì)修改，可以更好的利用filesystem cache進(jìn)行緩存，提高查詢性能。但是，任何設(shè)計(jì)都不是完美的，伴隨而來(lái)的問(wèn)題是：如果segment不可修改，怎么實(shí)現(xiàn)數(shù)據(jù)的更新與刪除呢？這個(gè)問(wèn)題將在文中Elasticsearch的"數(shù)據(jù)寫入"內(nèi)容中說(shuō)到。 Elasticsearch數(shù)據(jù)分布上面說(shuō)到Elasticsearch將每個(gè)index中的數(shù)據(jù)劃分到不同的shard中，然后將shard分配到不同的節(jié)點(diǎn)上，實(shí)現(xiàn)分布式存儲(chǔ)。這里面涉及到兩個(gè)概念：一個(gè)是數(shù)據(jù)到shard的映射（route），另一個(gè)是shard到節(jié)點(diǎn)的映射（shard allocate）。一方面：插入一條數(shù)據(jù)時(shí)，Elasticsearch會(huì)根據(jù)指定的key來(lái)計(jì)算應(yīng)該落到哪個(gè)shard上。默認(rèn)key是自動(dòng)分配的id，可以自定義，比如在業(yè)務(wù)中采用CompanyID作為key。因?yàn)閜rimary shard的個(gè)數(shù)是不允許改變的，所以同一個(gè)key每次算出來(lái)的shard是一樣的，從而保證了準(zhǔn)確定位。
shard_num = hash(_routing) % num_primary_shards
另一方面：master節(jié)點(diǎn)會(huì)為每個(gè)shard分配相應(yīng)的data節(jié)點(diǎn)進(jìn)行存儲(chǔ)，并維護(hù)相關(guān)元信息。通過(guò)route計(jì)算出來(lái)的shard序號(hào)，在元信息中找到對(duì)應(yīng)的存儲(chǔ)節(jié)點(diǎn)，便可完成數(shù)據(jù)分布。shard allocate的映射關(guān)系并不是完全不變的，當(dāng)檢測(cè)到數(shù)據(jù)分布不均勻、有新節(jié)點(diǎn)加入或者有節(jié)點(diǎn)掛掉等情況時(shí)就會(huì)進(jìn)行調(diào)整，稱為relocate。
一個(gè)分布式系統(tǒng)，是由多個(gè)節(jié)點(diǎn)各司其職、相互協(xié)作完成整體服務(wù)的，從架構(gòu)上可以分為有中心管理節(jié)點(diǎn)和無(wú)中心管理節(jié)點(diǎn)兩種，Elasticsearch屬于前者。中心管理節(jié)點(diǎn)負(fù)責(zé)維護(hù)整個(gè)系統(tǒng)的狀態(tài)和元信息，為了保證高可用性，通常是從一組候選節(jié)點(diǎn)中選舉出來(lái)的，而非直接指定。按照職責(zé)，Elasticsearch將節(jié)點(diǎn)分為三種：master-eligible節(jié)點(diǎn)就是中心節(jié)點(diǎn)的候選人，通過(guò)選舉算法從這些候選人中推選出大家公認(rèn)的中心節(jié)點(diǎn)。data節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)存儲(chǔ)、查詢，也是整個(gè)系統(tǒng)中負(fù)載最重的部分。ingest節(jié)點(diǎn)是針對(duì)Elasticsearch一個(gè)特定功能而設(shè)定的，Elasticsearch支持在數(shù)據(jù)寫入前對(duì)數(shù)據(jù)進(jìn)行相關(guān)的轉(zhuǎn)換、處理，而這類節(jié)點(diǎn)就是負(fù)責(zé)這樣的工作，從筆者遇到的實(shí)踐來(lái)看，使用這類節(jié)點(diǎn)的并不多。這三種角色是通過(guò)配置來(lái)設(shè)定的，可以同時(shí)設(shè)置到同一個(gè)節(jié)點(diǎn)上，即一個(gè)節(jié)點(diǎn)可以同時(shí)具備這三種功能。但是這種做法只適用于數(shù)據(jù)量小、業(yè)務(wù)較輕的場(chǎng)景，因?yàn)椴煌巧袚?dān)的功能所帶來(lái)的負(fù)載是不同的，很可能因?yàn)閿?shù)據(jù)寫入/查詢負(fù)載較重導(dǎo)致master節(jié)點(diǎn)通信受到影響，從而導(dǎo)致系統(tǒng)不穩(wěn)定。所以，推薦將不同角色分離開，某個(gè)節(jié)點(diǎn)只負(fù)責(zé)其中一個(gè)功能，通常會(huì)設(shè)置dedicated master-eligible節(jié)點(diǎn)、data/ingest節(jié)點(diǎn)。前者負(fù)載很輕，只需要分配較低配置的機(jī)器，而后者對(duì)CPU、IO、Memory要求較高，需要配置更好的機(jī)器，實(shí)踐中根據(jù)性能測(cè)試結(jié)果來(lái)調(diào)整。前面說(shuō)到，中心節(jié)點(diǎn)(master)是從一組候選人(master-eligible)中選舉出來(lái)的，那設(shè)置多少個(gè)候選人是合理的？原則是要保證任何時(shí)候系統(tǒng)只有一個(gè)確定的master節(jié)點(diǎn)?？紤]到一致性，只有被半數(shù)以上候選節(jié)點(diǎn)都認(rèn)可的節(jié)點(diǎn)才能成為master節(jié)點(diǎn)，否則就會(huì)出現(xiàn)多主的情況。只有1個(gè)候選節(jié)點(diǎn)顯然不能保證高可用；有2個(gè)時(shí)，半數(shù)以上（n/2+1）的個(gè)數(shù)也是2，任何一個(gè)出現(xiàn)故障就無(wú)法繼續(xù)工作了；有3個(gè)時(shí)，半數(shù)以上的值仍然是2，恰好可以保證master故障或網(wǎng)絡(luò)故障時(shí)系統(tǒng)可以繼續(xù)工作。因此，3個(gè)dedicated master-eligible節(jié)點(diǎn)是最小配置，也是目前業(yè)界標(biāo)配。Elasticsearch以REST API形式對(duì)外提供服務(wù)，數(shù)據(jù)寫入與查詢都會(huì)發(fā)送HTTP(S)請(qǐng)求到服務(wù)端，由負(fù)載均衡將請(qǐng)求分發(fā)到集群中的某個(gè)節(jié)點(diǎn)上（任何非dedicated master-eligible節(jié)點(diǎn)）。如下圖所示，節(jié)點(diǎn)1收到請(qǐng)求后，會(huì)根據(jù)相關(guān)的元信息將請(qǐng)求分發(fā)到shard所在的節(jié)點(diǎn)（2和3）上進(jìn)行處理，處理完成后，節(jié)點(diǎn)2和3會(huì)將結(jié)果返回給節(jié)點(diǎn)1，由節(jié)點(diǎn)1合并整理后返回給客戶端。這里的節(jié)點(diǎn)1扮演著協(xié)調(diào)者的角色，稱為coordinate節(jié)點(diǎn)，任何節(jié)點(diǎn)在收到請(qǐng)求后就開始發(fā)揮協(xié)調(diào)者的角色，直到請(qǐng)求結(jié)束。在實(shí)際使用中，可以根據(jù)需要增加一些專用的coordinate節(jié)點(diǎn)，用于性能調(diào)優(yōu)。Elasticsearch數(shù)據(jù)寫入通過(guò)上面的整理可知，Elasticsearch數(shù)據(jù)寫入的大致過(guò)程為：當(dāng)有數(shù)據(jù)寫入時(shí)，請(qǐng)求會(huì)先到達(dá)集群中的某個(gè)節(jié)點(diǎn)上，由該節(jié)點(diǎn)根據(jù)routing信息和元信息將相應(yīng)的數(shù)據(jù)分發(fā)到對(duì)應(yīng)的shard所在的節(jié)點(diǎn)上，可能是一個(gè)也可能是多個(gè)節(jié)點(diǎn)，取決于寫入的數(shù)據(jù)。這些節(jié)點(diǎn)在收到分發(fā)出來(lái)的請(qǐng)求后，會(huì)經(jīng)過(guò)一系列過(guò)程，最終將數(shù)據(jù)以segment的形式落地到磁盤上。Elasticsearch數(shù)據(jù)寫入過(guò)程包含同步與異步兩個(gè)過(guò)程，如下圖所示：同步過(guò)程：是指在請(qǐng)求返回前做的事情，即包含在一個(gè)HTTP請(qǐng)求的過(guò)程中，客戶端需要等其做完才能拿到結(jié)果。簡(jiǎn)單來(lái)看，這個(gè)過(guò)程需要完成三件事：第一，將操作記錄寫入到translog中，我們后面再來(lái)談它的作用；
第二，根據(jù)數(shù)據(jù)生成相應(yīng)的數(shù)據(jù)結(jié)構(gòu)，并寫入到in-memory buffer，注意是寫入到一個(gè)內(nèi)存buffer中，不是磁盤；
第三，將數(shù)據(jù)同步到所有replica shard中。完成這些之后，就會(huì)生成相應(yīng)的結(jié)果返回給coordinate節(jié)點(diǎn)了。
異步過(guò)程：一般來(lái)說(shuō)，寫磁盤很慢，且非常耗費(fèi)CPU與IO，在同步過(guò)程中，為了讓請(qǐng)求盡快返回，并沒(méi)有將數(shù)據(jù)直接落盤。Elasticsearch的最小數(shù)據(jù)單元是segment，而此時(shí)數(shù)據(jù)還在in-memory buffer中，因此這部分?jǐn)?shù)據(jù)是不能被查詢請(qǐng)求訪問(wèn)到的。只有當(dāng)發(fā)生refresh動(dòng)作，才會(huì)產(chǎn)生一個(gè)新的segment，將內(nèi)存buffer中的數(shù)據(jù)寫入到里面，同時(shí)清空buffer。默認(rèn)refresh的時(shí)間間隔是1秒，可以配置，需要在實(shí)時(shí)性與性能之間進(jìn)行權(quán)衡。此時(shí)雖然已經(jīng)生成了新的segment文件，但是只是停留在filesystem cache中，并沒(méi)有真正的落到磁盤中。這些動(dòng)作的目的都是為了將"寫磁盤"這件事盡可能的延后并變得低頻，但是數(shù)據(jù)一直留在內(nèi)存中始終是不安全的，很容易因?yàn)閿嚯姷仍驅(qū)е聰?shù)據(jù)丟失，因此每隔一段時(shí)間，Elasticsearch會(huì)真正做一次磁盤flush，完成數(shù)據(jù)的持久化。從寫入請(qǐng)求過(guò)來(lái)到數(shù)據(jù)最終落盤，中間很長(zhǎng)一段時(shí)間數(shù)據(jù)是停留在內(nèi)存中的，那么如果在此期間機(jī)器斷電豈不是會(huì)丟失數(shù)據(jù)？為了解決這個(gè)問(wèn)題，就要用到上面所述的translog了。在請(qǐng)求返回前，必須要將操作記錄寫入到translog中并落盤，保證機(jī)器重啟后可以恢復(fù)數(shù)據(jù)。顯然這件事本身是會(huì)消耗性能的，但這也是保證數(shù)據(jù)不丟失的一個(gè)犧牲了，必須要做的。segment是由refresh動(dòng)作產(chǎn)生的，因此隨著時(shí)間推移，會(huì)產(chǎn)生很多小segment，而每個(gè)segment都需要占用一定的資源，比如文件句柄、緩存等等，過(guò)多的segment勢(shì)必會(huì)導(dǎo)致性能下降。因此每隔一段時(shí)間，Elasticsearch會(huì)做一次segment merge，將多個(gè)小的segment合并成一個(gè)大的segment。最后再來(lái)看下前面提到的一個(gè)問(wèn)題：因?yàn)閟egment是不可改變的，如何實(shí)現(xiàn)數(shù)據(jù)更新與刪除？以刪除為例，Elasticsearch將要?jiǎng)h除的數(shù)據(jù)記錄到一個(gè)叫.del文件中，每次查詢時(shí)會(huì)將匹配到的數(shù)據(jù)跟這個(gè)文件中的數(shù)據(jù)做一次對(duì)比，去掉被刪除的數(shù)據(jù)。直到segment merge時(shí)，會(huì)將.del文件和相應(yīng)的segment文件一起加載進(jìn)行合并，這時(shí)才真正刪除了數(shù)據(jù)。
Elasticsearch存儲(chǔ)結(jié)構(gòu)在介紹Elasticsearch存儲(chǔ)結(jié)構(gòu)之前，先來(lái)看看兩種常見(jiàn)的查詢需求：一種是精確匹配，比如查找作者姓名為"Bruce"的信息；一種是全文檢索，比如從1000個(gè)文章的標(biāo)題中搜索出包含"分布式"的文章。對(duì)于第一個(gè)需求，只需要將每個(gè)名字作為一個(gè)term即可，"是"或"不是"；對(duì)于第二個(gè)，如果想知道標(biāo)題中是否包含"分布式"，就需要提前將每個(gè)標(biāo)題分解為多個(gè)term，比如"淺談分布式存儲(chǔ)系統(tǒng)"，可能會(huì)產(chǎn)生"淺談"、"分布式"、"存儲(chǔ)"、"系統(tǒng)"等多個(gè)term，具體取決于使用了哪一種分析器。不管哪種情況，最后都是產(chǎn)生一組term，問(wèn)題是用一個(gè)什么樣的存儲(chǔ)結(jié)構(gòu)可以實(shí)現(xiàn)快速檢索。這就是Elasticsearch的核心：inverted index。inverted index是一個(gè)二維結(jié)構(gòu)，如下所示，包含一組排好序的term，每個(gè)term都關(guān)聯(lián)有一些信息，這些信息指出哪些document包含了這個(gè)term。當(dāng)需要查詢包含關(guān)鍵詞"分布式"的數(shù)據(jù)時(shí)，系統(tǒng)會(huì)先從inverted index中找出對(duì)應(yīng)的term，獲取到其對(duì)應(yīng)的document id，然后就可以根據(jù)document id找出其信息了。
sample data：
1. {"author": "Bruce", "title": "淺談分布式存儲(chǔ)系統(tǒng)"}
2. {"author": "Bruce", "title": "常見(jiàn)的分布式系統(tǒng)"}
3. {"author": "David", "title": "分布式存儲(chǔ)原理"}
inverted index for field "author":
-------------------------------
term | doc id
-------------------------------
Bruce | 1, 2
David | 3
-------------------------------
inverted index for field "title":
-------------------------------
term | doc id
-------------------------------
常見(jiàn) | 3
存儲(chǔ) | 1, 3
分布式 | 1, 2, 3
淺談 | 1
系統(tǒng) | 1, 2
原理 | 3
-------------------------------
通過(guò)inverted index，就可以根據(jù)關(guān)鍵詞快速搜索出相關(guān)的document。除了這種查詢，還有一種常見(jiàn)的需求是求聚合，即關(guān)系型數(shù)據(jù)庫(kù)中的GROUP BY功能。比如查看寫"分布式"相關(guān)的文章最多的10位作者，首先根據(jù)上述方法通過(guò)inverted index找到與"分布式"相關(guān)的所有document，然后需要對(duì)這些document的作者進(jìn)行歸類并計(jì)數(shù)，最后再排序取出TOP10。在"歸類"時(shí)，我們需要知道每個(gè)document的作者名字，但是通過(guò)inverted index是無(wú)法直接查找到的，因?yàn)樗莟erm-to-doc_id形式的，而我們這里需要的是doc_id-to-term形式的數(shù)據(jù)，只有通過(guò)循環(huán)迭代才能知道某個(gè)document的作者姓名是什么，這樣做的效率無(wú)疑是很低的。
為了解決聚合的效率問(wèn)題，Elasticsearch建立了一個(gè)與invaerted index反向的數(shù)據(jù)結(jié)構(gòu)：doc values，如下所示：
-------------------------------
doc id | terms
-------------------------------
1 | Bruce
2 | Bruce
3 | David
-------------------------------
inverted index和doc values都是在數(shù)據(jù)寫入時(shí)建立的，即上述的同步過(guò)程第二步中完成的。它們都是針對(duì)per segment而言的，數(shù)據(jù)最終以文件的形式存儲(chǔ)，并且是immutable不可改變的。數(shù)據(jù)查詢時(shí)，如果每次都去讀取磁盤文件，其效率顯然是無(wú)法接受的，Elasticsearch將這些文件內(nèi)容映射到內(nèi)存中，通過(guò)充分利用文件系統(tǒng)緩存來(lái)提高查詢性能，因此在實(shí)踐中建議保留足夠的memory給系統(tǒng)。Elasticsearch重要配置說(shuō)明elasticsearch的基礎(chǔ)配置信息在elasticsearch.yml中，下面列出一些重要的配置。默認(rèn)情況下elasticsearch的集群名稱是elasticsearch，在實(shí)際應(yīng)用中應(yīng)該設(shè)置一個(gè)有意義的集群名稱：
cluster.name: elasticsearch-cluster-demo
7.2 節(jié)點(diǎn)信息
elasticsearch節(jié)點(diǎn)是elasticsearch集群中的某一個(gè)節(jié)點(diǎn)，可由基本的三個(gè)信息描述，節(jié)點(diǎn)名稱（node.name）,是否為主節(jié)點(diǎn)（node.master）,是否為數(shù)據(jù)節(jié)點(diǎn)（node.data）。默認(rèn)情況下，節(jié)點(diǎn)名稱在每次啟動(dòng)的時(shí)候會(huì)隨機(jī)生成，所以應(yīng)該為節(jié)點(diǎn)設(shè)置一個(gè)有意義的名稱，以方便排查問(wèn)題。而節(jié)點(diǎn)又分為主節(jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)、客戶端節(jié)點(diǎn)、部落節(jié)點(diǎn)，下面是一個(gè)節(jié)點(diǎn)（只為主節(jié)點(diǎn)）的配置樣例：
node.name: node-master-one
node.master: true
node.data: false
7.3 數(shù)據(jù)存儲(chǔ)路徑/日志路徑
默認(rèn)情況下，elasticsearch數(shù)據(jù)和日志的存儲(chǔ)路徑是在安裝目錄下，為了防止被誤刪掉，應(yīng)該重新設(shè)置路徑。配置樣例如下：
# Path to directory where to store the data (separate multiple locations by comma):
# es data 存儲(chǔ)路徑（多個(gè)路徑可用,隔開）
path.data: /data/elasticsearch-cluster/elasticsearch-master-one/data
#
# Path to log files:
# log存儲(chǔ)路徑
path.logs: /data/elasticsearch-cluster/elasticsearch-master-one/logs
7.4 網(wǎng)絡(luò)綁定監(jiān)聽(tīng)在搭建elasticsearch的時(shí)候，也應(yīng)該去修改其監(jiān)聽(tīng)的主機(jī)IP，至于端口可以用默認(rèn)的：
# Set the bind address to a specific IP (IPv4 or IPv6):
# 網(wǎng)路監(jiān)聽(tīng)
network.host: 0.0.0.0
http.port: 9200
transport.tcp.port: 9300
7.5 最小主節(jié)點(diǎn)數(shù)如果是搭建elasticsearch集群，那么應(yīng)該設(shè)置最小主節(jié)點(diǎn)這個(gè)設(shè)置，以便防止腦裂現(xiàn)象：多個(gè)主節(jié)點(diǎn)同時(shí)存在與一個(gè)集群（一個(gè)集群只允許有一個(gè)主節(jié)點(diǎn)）。集群的主節(jié)點(diǎn)是集群的最高統(tǒng)治者，控制著索引的創(chuàng)建和分片的移動(dòng)策略等；如果一個(gè)集群出現(xiàn)多個(gè)主節(jié)點(diǎn)，那么就好比一個(gè)團(tuán)隊(duì)出現(xiàn)兩個(gè)leader一樣，原本的一個(gè)整體被劃分，對(duì)于elasticsearch集群來(lái)講就是原本的分片（數(shù)據(jù)）被分開，這樣數(shù)據(jù)就可能出現(xiàn)不完整性。集群的主節(jié)點(diǎn)是靠所有有資格競(jìng)選主節(jié)點(diǎn)的節(jié)點(diǎn)（即節(jié)點(diǎn)信息設(shè)置node.master為true）投票選舉出來(lái)的，所以現(xiàn)在獲得的投票數(shù)量應(yīng)該大于總票數(shù)半。所以在elasticsearch中，是設(shè)定當(dāng)候選的master節(jié)點(diǎn)達(dá)到設(shè)定的法定個(gè)數(shù)的時(shí)候才進(jìn)行主節(jié)點(diǎn)選舉：法定個(gè)數(shù) = master-eligible nodes / 2 + 1
# Prevent the "split brain" by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):
# 最小主節(jié)點(diǎn)個(gè)數(shù)
discovery.zen.minimum_master_nodes: 2
因?yàn)閑lasticsearch節(jié)點(diǎn)是可以動(dòng)態(tài)刪除和添加的，所以這個(gè)設(shè)置是可以通過(guò)API動(dòng)態(tài)設(shè)置的。elasticsearch集群在啟動(dòng)的時(shí)候，會(huì)做數(shù)據(jù)平衡操作。比如，一個(gè)10個(gè)節(jié)點(diǎn)5/1分片策略（5個(gè)分片，5個(gè)副本分片）的集群，平衡下來(lái)是每個(gè)節(jié)點(diǎn)一個(gè)分片，如果集群在重啟的時(shí)候，有5個(gè)節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)原因一段時(shí)間內(nèi)未啟動(dòng)成功，可能會(huì)出現(xiàn)一種情況：?jiǎn)?dòng)的5個(gè)節(jié)點(diǎn)中有3個(gè)主分片，2個(gè)副分片。這時(shí)候就會(huì)出現(xiàn)主分片數(shù)據(jù)不完整和不均勻分布，此時(shí)集群會(huì)自動(dòng)做數(shù)據(jù)的平衡操作。若一段時(shí)間后，另外的5個(gè)節(jié)點(diǎn)重新上線了，發(fā)現(xiàn)本身的數(shù)據(jù)在集群中已存在，則又會(huì)做平衡操作。這樣，兩次數(shù)據(jù)平衡移動(dòng)操作，會(huì)占用磁盤和帶寬，若數(shù)據(jù)量大則影響可想而知。所以可以做如下控制，來(lái)保障集群重啟時(shí)數(shù)據(jù)恢復(fù)花費(fèi)時(shí)間盡可能短：1）設(shè)置集群可提供服務(wù)的條件：最小上線節(jié)點(diǎn)數(shù)。
gateway.recover_after_nodes: 8
2）設(shè)置集群數(shù)據(jù)恢復(fù)條件：等待多少分鐘，或這有多少個(gè)節(jié)點(diǎn)上線（具體取決與條件的先達(dá)性）。
gateway.expected_nodes: 10
gateway.recover_after_time: 5m
7.7 集群節(jié)點(diǎn)發(fā)現(xiàn)使用單播方式，為節(jié)點(diǎn)提供其應(yīng)該去嘗試連接的節(jié)點(diǎn)列表，連接成功，得到集群的狀態(tài)信息，便加入集群。節(jié)點(diǎn)列表中可以不是全部節(jié)點(diǎn)，只要能保障能進(jìn)入集群即可（可以選用部分候選主節(jié)點(diǎn)）。
# Pass an initial list of hosts to perform discovery when new node is started:
# The default list of hosts is ["XXX.X.0.1", "[::1]"]
# 候選主節(jié)點(diǎn)ip:port
discovery.zen.ping.unicast.hosts: ["XXX.X.0.1:9300"]
elasticsearch集群在運(yùn)行的時(shí)候，當(dāng)有節(jié)點(diǎn)加入或離開的時(shí)候，會(huì)進(jìn)行分片均衡操作，這個(gè)過(guò)程有些像集群重啟時(shí)的數(shù)據(jù)恢復(fù)過(guò)程，可能會(huì)導(dǎo)致出現(xiàn)多次分片在均衡的過(guò)程，所以需要設(shè)置延遲分片分配，以盡量避免該情形出現(xiàn)。
# 延遲5min
delayed_timeout: 5m
該設(shè)置同樣可以通過(guò)API的形式動(dòng)態(tài)設(shè)置。
內(nèi)存交換會(huì)影響性能，elasticsearch官方推薦允許JVM鎖住內(nèi)存，禁止出現(xiàn)內(nèi)存交換的情況：
1）Elasticsearch JVM內(nèi)存elasticsearch默認(rèn)的安裝內(nèi)存是1g，這個(gè)可以根據(jù)需要來(lái)設(shè)置，在elasticsearch的config目錄中的jvm.options中：
# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space
-Xms1g
-Xmx1g
當(dāng)然，這個(gè)內(nèi)存不是隨便設(shè)置的，推薦的是最大值和最小值一樣，以避免堆內(nèi)存改變時(shí)浪費(fèi)系統(tǒng)資源。其次是即便硬件資源足購(gòu)大，也不要分配超過(guò)32G（具體原因可參考Elasticsearch權(quán)威指南：不要超過(guò)32GB），可以多給底層lucenen多分點(diǎn)。elasticsearch在節(jié)點(diǎn)在通信時(shí)會(huì)產(chǎn)生大量套接字，以及elasticsearch底層的lucene使用了大量文件，所以需要足夠的文件描述符，而linux中一般都是做有限制的，所以應(yīng)該修改為大一點(diǎn)的值?？梢孕薷奈募?etc/security/limits.conf，添加如下配置,配置值設(shè)為需要的值即可：
#
#四個(gè)元素的意義在該文件中均有詳細(xì)描述
elasticsearch soft nofile 65536
elasticsearch hard nofile 65536
elasticsearch對(duì)文件混合使用了NioFs（非阻塞文件系統(tǒng)）和 MMapFs （ 內(nèi)存映射文件系統(tǒng)），所以要保障有足夠的虛擬內(nèi)存用于映射。可以直接修改/etc/sysctl.conf文件添加如下配置，配置值設(shè)為需要的值。下面內(nèi)容添加到sysctl.conf文件中后，執(zhí)行"sysctl -p"命令使配置生效即可。
這兩項(xiàng)如果在啟動(dòng)elasticsearch之前不進(jìn)行設(shè)置的話，在啟動(dòng)elasticsearch的時(shí)候也可能會(huì)直接報(bào)相關(guān)的error以致無(wú)法啟動(dòng)成功。這兩個(gè)配置，es官方強(qiáng)烈建議不要做修改，具體原因可參考：Elasticsearch權(quán)威指南：不要觸碰這些配置隨著業(yè)務(wù)的增長(zhǎng)與發(fā)展，不同的Elasticsearch集群承擔(dān)著多厚多樣的功能需求。尤其是當(dāng)集群規(guī)模增長(zhǎng)、業(yè)務(wù)龐大時(shí)，需要耗費(fèi)大量的精力運(yùn)維集群。最壞的情況，Elasticsearch集群崩潰，無(wú)法正常承擔(dān)各項(xiàng)業(yè)務(wù)。導(dǎo)致ES集群崩潰的大多數(shù)原因是master節(jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)的宕機(jī)。下面總結(jié)節(jié)點(diǎn)：8.1 節(jié)點(diǎn)負(fù)載過(guò)高，導(dǎo)致節(jié)點(diǎn)失聯(lián)以Elasticsearch集群的數(shù)據(jù)節(jié)點(diǎn)與master節(jié)點(diǎn)為例，當(dāng)有任何一個(gè)節(jié)點(diǎn)負(fù)載過(guò)高，都可能導(dǎo)致單節(jié)點(diǎn)宕機(jī)從而挑戰(zhàn)集群的可用性。master節(jié)點(diǎn)負(fù)載高會(huì)嚴(yán)重影響到集群穩(wěn)定性，可能發(fā)生master漂移，節(jié)點(diǎn)上下線，分片丟失，負(fù)載增高，甚至阻塞讀寫等。應(yīng)對(duì)措施：可以確認(rèn)下是否有大量頻繁的修改，創(chuàng)建，刪除索引操作，并盡量避免這種行為?？梢钥紤]使用更高配置的節(jié)點(diǎn)用增加系統(tǒng)高穩(wěn)定性。因此，我們需要檢測(cè)過(guò)去一段時(shí)間內(nèi)Elasticsearch節(jié)點(diǎn)負(fù)載情況（腳本方式等），提前獲知并拯救集群于崩潰邊緣。8.2 索引副本丟失，數(shù)據(jù)可靠性受損索引的副本一方面是保證數(shù)據(jù)的可靠性，保證在數(shù)據(jù)丟失的狀態(tài)下依舊可以恢復(fù)如初；一方面副本數(shù)的增加可提高查詢的性能。在存儲(chǔ)空間占用過(guò)滿時(shí)，極有可能導(dǎo)致索引副本丟失。因此檢查副本的存在狀態(tài)，可幫助提高數(shù)據(jù)的可靠性。在Elasticsearch集群重啟的過(guò)程中，只有在副本數(shù)量完整時(shí)才能保證服務(wù)的持續(xù)進(jìn)行。應(yīng)對(duì)措施：監(jiān)控Elasticsearch集群基本顏色狀態(tài)，檢查shard分片是否丟失。顏色不正常的索引會(huì)影響數(shù)據(jù)讀寫。索引副本丟失（YELLOW）會(huì)影響到數(shù)據(jù)的可靠性和讀寫性能；索引主分片丟失（RED）會(huì)導(dǎo)致數(shù)據(jù)丟失。所以要極度重視和關(guān)注Elasticsearch集群顏色狀態(tài)的監(jiān)控，遇到異常，及時(shí)處理！8.3 數(shù)據(jù)寫入失敗，集群壓力過(guò)大在寫操作進(jìn)行的過(guò)程中，可能會(huì)因Elasticsearch集群壓力，導(dǎo)致讀寫任務(wù)堆積過(guò)多。如果在此情況下繼續(xù)增加寫入，則可能會(huì)引起集群的崩潰。檢查集群寫數(shù)據(jù)是否有堆積，如果寫入存在堆積，則會(huì)造成RulkReject異常，可能會(huì)導(dǎo)致數(shù)據(jù)丟失，且會(huì)造成系統(tǒng)資源消耗嚴(yán)重。應(yīng)對(duì)措施：通過(guò)調(diào)用線程池查看實(shí)際成功、失敗任務(wù)情況，使用分批寫入的方式解決寫入堆積困境，給集群減壓?？梢酝ㄟ^(guò)ES_API查看隊(duì)列情況，GET _cat/thread_pool/bulk?v，建議增加更多的數(shù)據(jù)解讀或降低bulk寫入頻率和大小。 如何在固定配置的情況下更大程度發(fā)揮集群可用性能，是我們最關(guān)心的問(wèn)題。從Elasticsearch內(nèi)部邏輯與架構(gòu)，數(shù)據(jù)節(jié)點(diǎn)是任務(wù)載體與執(zhí)行依托，shard是索引與搜索的主要承擔(dān)者，副本是提升性能的重要抓手，分批寫入與防止稀疏是必備方式。如何提升集群性能，下面從數(shù)據(jù)節(jié)點(diǎn)負(fù)載、shard合理性兩方面簡(jiǎn)單做下說(shuō)明。9.1 數(shù)據(jù)節(jié)點(diǎn)抓偏離，防止單節(jié)點(diǎn)瓶頸在各數(shù)據(jù)節(jié)點(diǎn)負(fù)載均衡的條件下，性能會(huì)趨向于最優(yōu)的實(shí)踐。如果發(fā)生單節(jié)點(diǎn)負(fù)載過(guò)高，與其他節(jié)點(diǎn)產(chǎn)生較大差異，則高負(fù)載節(jié)點(diǎn)可能成為"拖油瓶"，拉低整體集群數(shù)據(jù)節(jié)點(diǎn)任務(wù)執(zhí)行，甚至存在脫離集群的風(fēng)險(xiǎn)。監(jiān)控Elasticsearch集群當(dāng)天的節(jié)點(diǎn)負(fù)載偏差是否過(guò)大，節(jié)點(diǎn)間負(fù)載不一致會(huì)使得某個(gè)節(jié)點(diǎn)成為系統(tǒng)瓶頸，影響集群穩(wěn)定性。應(yīng)嘗試調(diào)整shard分片數(shù)或數(shù)據(jù)節(jié)點(diǎn)數(shù)，盡可能保證兩者均衡。9.2 shard、segment合理性評(píng)估，升性能調(diào)負(fù)載不同的Elasticsearch集群應(yīng)用場(chǎng)景對(duì)性能承載著不同的需求。索引的載體就是shard，搜索結(jié)果的返回也是多個(gè)shard共同的返回結(jié)果。Shard數(shù)與節(jié)點(diǎn)間的負(fù)載均衡、查詢性能和存儲(chǔ)空間利用均有著非常重要的關(guān)系。shard數(shù)和大小不合理會(huì)極大的影響索引讀寫性能，shatd過(guò)少會(huì)影響索引讀寫性能，shard過(guò)多會(huì)占用較多系統(tǒng)資源。通過(guò)讀取索引shard、節(jié)點(diǎn)shard，檢查判斷是否因索引segment過(guò)多導(dǎo)致碎片化，引發(fā)離線數(shù)據(jù)寫入過(guò)慢，從而在適當(dāng)?shù)臅r(shí)間執(zhí)行段合并操作，即調(diào)整部分索引的shard數(shù)，提升離線數(shù)據(jù)的寫入速度，均衡負(fù)責(zé)，提升性能，節(jié)省空間。
本文來(lái)源：IT那活兒（上海新炬王翦團(tuán)隊(duì)）
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/129509.html
