轉自： https://mp.weixin.qq.com/s/wmSTyIGCVhItVNPHcH7nsA

一、整體架構

為什麽采用ES作為搜索引擎呢？在做任何事情的時候，不要一上來就急著了解怎麽做這件事情，而是去想想這件事情為什麽值得去做。

這個是比較通用的數據的流程，一般會通過Kafka分離產生數據的應用程序和後面的平臺，通過ETL落到不同的地方，按照優先級和冷熱程度采取不同的存儲方式。一般來說，冷數據存放到HDFS，如果溫數據、或者熱數據會采用Database以及Cache，目前分布式Cache還沒有明顯的強者出現，這將會成為未來的一個競爭點。

一旦數據落地，我們會做兩方面的應用，第一個方面的應用是傳統BI，比如會產生各種各樣的報表，報表的受眾是更高的決策層和管理層，他們看了之後，會有相應的業務調整和更高層面的規劃或轉變。這個使用路徑比較傳統的，在數據倉庫時代就已經存在了。現在有一種新興的場景就是利用大數據進行快速決策，數據不是餵給人的，數據分析結果由程序來消費，其實是再次的反饋到數據源頭即應用程序中，讓他們基於快速分析後的結果，調整已有策略，這樣就形成了一個數據使用的循環。

這樣我們從它的輸入到輸出會形成一種閉環，而且這個閉環全部是機器參與的，這也是為什麽去研究這種大規模的，或者快速決策的原因所在。如果數據最終還會給人本身來看的話，就沒有必要更新那麽快，因為一秒鐘刷新一次或者10秒鐘刷新一次對人是沒有意義的，因為我們腦子不可能一直轉那麽快，基於數據一直的做調整也是不現實的，但是對機器來講，就完全沒有問題。

二、集群規劃

這是大體上的一個規劃，當然，從左到右有一個結點，這個節點本身不存在數據的，你可以簡單地認為它只是負責查詢的入口。第二層用來承載具體的數據，然後這些數據的搜索本身會發生在這裏。最後一層是MASTER的節點，主要是管理元數據，元數據包含有集群中的機器信息，以及寫入到我的數據節點上的這些索引設置信息、索引Schema都是由Master管理

三、集群配置

下面要講的設置就非常具體了，從三個層面來講：第一個有關Linux的系統配置，第二是集群層面的參數設置，最後會涉及到存儲到集群上的索引設置。

1、OS參數設置

像OS這個參數設置，首先提到的是內存相關的參數，由於ES采用Mapping機制，將文件映射到內存，在系統級別有一些相關的參數要設置。另一個就是文件數，假設我們所有都設置到最大65535。這個設置之後還需要在下面加入加入login這個文件，這裏講得非常具體，可以說是一個教程。

這裏我只是做了一個示例，在Ext4文件系統中，每一次訪問一個文件或者目錄時，其實OS級別會記錄訪問時間，如果只是在海量文件的情況，上述的記錄信息就會對IO有影響。有一篇文章提到，關閉文件訪問時間信息之後，系統IO性能可以提升20%—30%。我們知道Linux裏面文件信息，不是直接改一次之後就寫入到磁盤，它會先有一個文件的緩存，文件的緩存什麽情況下會被寫入到disk裏面？有兩個相應的系統參數可以設置的，一個是vm.dirty_background_ratio，一個是vm.dirty_ratio，一旦緩存占據內存超過百分比（默認值是20%）之後，內核就停止其它方面的操作，而只做文件的緩存吐到disk的操作，這時效果有點像Java裏進行垃圾回收一樣，對外界停止響應。 vm.dirty_ratio就是當它緩存量達到20%時，它就其它的什麽都不幹了，只做數據同步到disk一件。內存不夠時，會使用swap空間， 內存很大的話，可以不用創建swap空間。默認值是60，但是我們把它設置為零的話，是跟swap off效果一樣。但為了避免內核出現OOM， 只是將其設置為1。

2、ElasticSearch參數設置

剛才兩個講的都是系統級別的設置，一個是內存，另一個是系統級別的IO，下面講的是針對ES—JVM的設置。

這裏建議，不管物理內存有多大，分配給Elasticsearch的只設成32G，同時後面如果出現OOM，進程直接退出。為什麽說要把它改成這個呢？因為我們在使用一個集群時看到，有時因為聚合操作的原因，會導致某一臺機器上的JAVA進程出現OOM，但是這個JVM進程還在，並沒有退出，退出的話可以通過monit捕捉到，也可以進行重啟。如果沒有退出，而是一直掛在那的話，就不能提供正常的服務。 此外加上這個參數的話，需要升級一下JDK版本，JDK要求1.8.0_92, 從這個版本開始支持ExitOnOutOfMemoryError參數。 另外一種辦法就是如果我們內存不能升級JDK、存在種種現實約束的話，可以在這個時候用另一種方式來實現，在JVM啟動參數中加入：-XX:OnOutOfMemoryError="kill -9 %p"。

這裏就是講輸入到ElasticSearch裏面每個集群的一些參數，一些相對比較主要的一些參數。這裏的參數配了一幅圖，這幅圖最想表明的意思是說，我的參數的配置要使得我從整個集群的角度上來看，它每一臺機器上的shard數目基本是相當的。這裏有一點，參數設置能保證shard數目是基本相當的，但並不是保證每一個shard的大小相等，這兩者還是有差異的。決定每個集群上shard相等的參數是由這個balance決定，它默認一個是0.5，把它往下調的話，就不可以傾斜；往上調的話對傾斜的容忍度相對比較高。ElasticSearch是一個高可靠的系統，集群的一個節點掛掉了，另一個節點是可以繼續的。掛掉的節點是進行恢復，為了避免恢復工作對集群造成太多影響，主要是避免大的I/O消耗，需要進行參數設置。比如集群中同時在進行恢復的索引可以是多少個，還有就是一個node上能允許shard在做恢復。 這兩個參數是cluster_concurrent_rebalance和node_concurrent_recoveries。

如果要縮容、對某一臺機器進行維護、將其從集群中拉出來該怎麽辦？這個時候可以設定exclude名單，名單可以通過ip地址或主機名來指定。一旦設置的exlude名單，該名單上節點中的索引數據被拉到別的機器上面，數據被拉完之後，就可以被這個集群拉出去的機器進行維護，避免維護帶來的數據丟失

3、索引參數設置

這是具體到一個索引參數的設置。在講具體參數之前，我們可以先講一下ElasticSearch索引參數的設置、輸入以及中間發生的過程。當真正的數據請求到達ElasticSearch節點之後，它一方面會寫入到內存中，另外一部分會寫入到TransactionLog，寫入到內存並不意味著可以被搜索，要通過Refresh操作，才可以被搜索到。Refresh之後，數據可以被搜索到，此刻數據還在內存中，如果很不巧的話，在這個時候斷電，或者出現其它故障不可用了，那麽等到這臺機器再恢復時，我剛才寫的內容就丟失掉了， 因為並沒有被持久化到磁盤。 為了持久化這個內容，需要進行一次FLUSH操作， flush的內容會被寫到一個segment中。 可想而知，隨著時間的推移，系統會產生大量的segments，這些segment需要把它合並成一個大的。不合並成一個大的會怎樣呢？不合並成一個大的，就是說每一個segment都會吃掉一些文件句柄，文件句柄數是有限的。另一個帶來的就是查詢性能下降，因為查詢的時候，要對所有segments進行訪問，效率就比較低了。

有了剛才講的三步之後，再來看下面的參數就比較容易好理解了。 Refresh_interval 過多久可以讓你查詢到，時間越短就可以被越快地檢索到，但是意味著我相應的I/O也上去了，在有大批量數據導入時，這個數值會適當的調大。在我們目前部署的集群中，高峰時候每秒寫入量，有十幾萬。 為了應對這種場景，將refresh_interval設置為100多秒或者90秒以上。Number_of_shards索引分片的數目，這個數目可以設置得大一些，還有每一個分片的副本，在大批量導入時，由於副本數目是可以動態調整的，副本數也可以先設置為零，等數據全部導入後，再設置為非0值。 副本數可以動態調整，但是分片數目是無法動態調整的，也就是說，除非重建另外一個索引，不然原先設置的是啥樣就只能啥樣。 這個FLUSH也可以調大，需要的時候可以設置得大一些。下面就是做segments合並的線程數，如果是spin disk的話，就使用默認值1，如果是SSD的話，可以把它調大一些。 講到SSD代碼的話， 為了進一步優化性能，可以將系統的i/o scheduler設置為noop 。

這裏是針對每個Index的Schema設置，假設事先並不能確定索引，大部分我們可以采用動態的template，上述的動態模板表示的是，如果字符串小於10915， 就采用keyword來存儲。下面一欄對應特別特別大的字段，如果我們只是存儲這個字段的內容，不對這個字段做搜索也不做任何分詞，可以將類型設置為object，enabled設置為false，即便包含嵌套信息也不會被解析。

前面講的是一些設置方面的內容，下面講如何放開這個ElasticSearch的使用。想法跟大的原則一樣，盡量避免開發人員直接調用Elasticsearch的API來操作ElasticSearch，因為這樣產生的問題不容易控制，畢竟每個人對ElasticSearch的熟悉程度不一樣。 建議先統一入口，在包裹之後的API對ES進行操作。 利用BigQuery API對寫入到Elasticserch的數據進行查詢，開發人員直接寫SQL語句。如果SQL語句本身有問題的話，在Elasticsearch-SQL一側就可以將其擋掉。

四、集群監控

1、監控內容

維護一個集群的話，肯定離不開對集群的監控，監控的內容，大體上來說分成OS層面還有ES索引層面的內容 ，OS層面就是內存、CPU，索引層面就是分片還有它的Field Data以及其它占用的內存數。索引的話就是每個索引數設置得合理，這些分片數設置得合理與否，分片是否在每個集群裏比較均勻地分布；針對每一個索引的話，它的查詢量是不是過大，如果過大的話，那麽整個集群也會有問題。ElasticSearch並不是一個能夠很好地支持高並發查詢的系統。每一個索引中包含的字段數不能過多。

2、監控工具

監控工具是eyeones，是我們自己寫的一個工具， Elasticsearch 5.x中提供的x-pack基本版與elasticsearch 1.x中提供的marvel相比，精簡掉了好多有用的信息，這是我們為什麽自己寫一個監控面板的原因。

從這裏你可以看到這是針對節點的負載情況，然後它的內存使用情況，還有就是我這上面所承載的索引數目、每個節點上的查詢數、分片落了多少。

這是一個針對索引內容更加明細的量化指標，上面是索引的情況，點擊任意一個具體的索引，都會有相關內容。

Elasticsearch 學習之攜程機票ElasticSearch集群運維馴服記(強烈推薦)