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