貸前系統(tǒng)ElasticSearch實踐總結(jié)

貸前系統(tǒng)負(fù)責(zé)從進(jìn)件到放款前所有業(yè)務(wù)流程的實現(xiàn)，其中涉及一些數(shù)據(jù)量較大、條件多樣且復(fù)雜的綜合查詢，引入ElasticSearch主要是為了提高查詢效率，并希望基于ElasticSearch快速實現(xiàn)一個簡易的數(shù)據(jù)倉庫，提供一些OLAP相關(guān)功能。本文將介紹貸前系統(tǒng)ElasticSearch的實踐經(jīng)驗。

一、索引

描述：為快速定位數(shù)據(jù)而設(shè)計的某種數(shù)據(jù)結(jié)構(gòu)。

索引好比是一本書前面的目錄，能加快數(shù)據(jù)庫的查詢速度。了解索引的構(gòu)造及使用，對理解ES的工作模式有非常大的幫助。

常用索引：

• 位圖索引

• 哈希索引

• BTREE索引

• 倒排索引

1.1 位圖索引（BitMap）

位圖索引適用于字段值為可枚舉的有限個數(shù)值的情況。

位圖索引使用二進(jìn)制的數(shù)字串（bitMap）標(biāo)識數(shù)據(jù)是否存在，1標(biāo)識當(dāng)前位置（序號）存在數(shù)據(jù)，0則表示當(dāng)前位置沒有數(shù)據(jù)。

下圖1 為用戶表，存儲了性別和婚姻狀況兩個字段；

圖2中分別為性別和婚姻狀態(tài)建立了兩個位圖索引。

例如：性別->男 對應(yīng)索引為：101110011，表示第1、3、4、5、8、9個用戶為男性。其他屬性以此類推。

使用位圖索引查詢：

• 男性 并且已婚 的記錄 = 101110011 & 11010010 = 100100010，即第1、4、8個用戶為已婚男性。

• 女性 或者未婚的記錄 = 010001100 | 001010100 = 011011100, 即第2、3、5、6、7個用戶為女性或者未婚。

1.2 哈希索引

顧名思義，是指使用某種哈希函數(shù)實現(xiàn)key->value 映射的索引結(jié)構(gòu)。

哈希索引適用于等值檢索，通過一次哈希計算即可定位數(shù)據(jù)的位置。

下圖3 展示了哈希索引的結(jié)構(gòu)，與JAVA中HashMap的實現(xiàn)類似，是用沖突表的方式解決哈希沖突的。

1.3 BTREE索引

BTREE索引是關(guān)系型數(shù)據(jù)庫最常用的索引結(jié)構(gòu)，方便了數(shù)據(jù)的查詢操作。

BTREE: 有序平衡N階樹, 每個節(jié)點有N個鍵值和N+1個指針, 指向N+1個子節(jié)點。

一棵BTREE的簡單結(jié)構(gòu)如下圖4所示，為一棵2層的3叉樹，有7條數(shù)據(jù)：

以Mysql最常用的InnoDB引擎為例，描述下BTREE索引的應(yīng)用。

Innodb下的表都是以索引組織表形式存儲的，也就是整個數(shù)據(jù)表的存儲都是B+tree結(jié)構(gòu)的，如圖5所示。

主鍵索引為圖5的左半部分（如果沒有顯式定義自主主鍵，就用不為空的唯一索引來做聚簇索引，如果也沒有唯一索引，則innodb內(nèi)部會自動生成6字節(jié)的隱藏主鍵來做聚簇索引），葉子節(jié)點存儲了完整的數(shù)據(jù)行信息（以主鍵 + row_data形式存儲）。

二級索引也是以B+tree的形式進(jìn)行存儲，圖5右半部分，與主鍵不同的是二級索引的葉子節(jié)點存儲的不是行數(shù)據(jù)，而是索引鍵值和對應(yīng)的主鍵值，由此可以推斷出，二級索引查詢多了一步查找數(shù)據(jù)主鍵的過程。

維護(hù)一顆有序平衡N叉樹，比較復(fù)雜的就是當(dāng)插入節(jié)點時節(jié)點位置的調(diào)整，尤其是插入的節(jié)點是隨機(jī)無序的情況；而插入有序的節(jié)點，節(jié)點的調(diào)整只發(fā)生了整個樹的局部，影響范圍較小，效率較高。

可以參考紅黑樹的節(jié)點的插入算法：

https://en.wikipedia.org/wiki/Red%E2%80%93black_tree

因此如果innodb表有自增主鍵，則數(shù)據(jù)寫入是有序?qū)懭氲?，效率會很高；如果innodb表沒有自增的主鍵，插入隨機(jī)的主鍵值，將導(dǎo)致B+tree的大量的變動操作，效率較低。這也是為什么會建議innodb表要有無業(yè)務(wù)意義的自增主鍵，可以大大提高數(shù)據(jù)插入效率。

注：

• Mysql Innodb使用自增主鍵的插入效率高。

• 使用類似Snowflake的ID生成算法，生成的ID是趨勢遞增的，插入效率也比較高。

1.4 倒排索引（反向索引）

倒排索引也叫反向索引，可以相對于正向索引進(jìn)行比較理解。

正向索引反映了一篇文檔與文檔中關(guān)鍵詞之間的對應(yīng)關(guān)系；給定文檔標(biāo)識，可以獲取當(dāng)前文檔的關(guān)鍵詞、詞頻以及該詞在文檔中出現(xiàn)的位置信息，如圖6 所示，左側(cè)是文檔，右側(cè)是索引。

反向索引則是指某關(guān)鍵詞和該詞所在的文檔之間的對應(yīng)關(guān)系；給定了關(guān)鍵詞標(biāo)識，可以獲取關(guān)鍵詞所在的所有文檔列表，同時包含詞頻、位置等信息，如圖7所示。

反向索引（倒排索引）的單詞的集合和文檔的集合就組成了如圖8所示的”單詞-文檔矩陣“，打鉤的單元格表示存在該單詞和文檔的映射關(guān)系。

倒排索引的存儲結(jié)構(gòu)可以參考圖9。其中詞典是存放的內(nèi)存里的，詞典就是整個文檔集合中解析出的所有單詞的列表集合；每個單詞又指向了其對應(yīng)的倒排列表，倒排列表的集合組成了倒排文件，倒排文件存放在磁盤上，其中的倒排列表內(nèi)記錄了對應(yīng)單詞在文檔中信息，即前面提到的詞頻、位置等信息。

下面以一個具體的例子來描述下，如何從一個文檔集合中生成倒排索引。

如圖10，共存在5個文檔，第一列為文檔編號，第二列為文檔的文本內(nèi)容。

將上述文檔集合進(jìn)行分詞解析，其中發(fā)現(xiàn)的10個單詞為：[谷歌，地圖，之父，跳槽，F(xiàn)acebook，×××，創(chuàng)始人，拉斯，離開，與]，以第一個單詞”谷歌“為例：首先為其賦予一個唯一標(biāo)識 ”單詞ID“， 值為1，統(tǒng)計出文檔頻率為5，即5個文檔都有出現(xiàn)，除了在第3個文檔中出現(xiàn)2次外，其余文檔都出現(xiàn)一次，于是就有了圖11所示的倒排索引。

1.4.1 單詞詞典查詢優(yōu)化

對于一個規(guī)模很大的文檔集合來說，可能包含幾十萬甚至上百萬的不同單詞，能否快速定位某個單詞，這直接影響搜索時的響應(yīng)速度，其中的優(yōu)化方案就是為單詞詞典建立索引，有以下幾種方案可供參考：

• 詞典Hash索引

Hash索引簡單直接，查詢某個單詞，通過計算哈希函數(shù)，如果哈希表命中則表示存在該數(shù)據(jù)，否則直接返回空就可以；適合于完全匹配，等值查詢。如圖12，相同hash值的單詞會放在一個沖突表中。

• 詞典BTREE索引

類似于Innodb的二級索引，將單詞按照一定的規(guī)則排序，生成一個BTree索引，數(shù)據(jù)節(jié)點為指向倒排索引的指針。

• 二分查找

同樣將單詞按照一定的規(guī)則排序，建立一個有序單詞數(shù)組，在查找時使用二分查找法；二分查找法可以映射為一個有序平衡二叉樹，如圖14這樣的結(jié)構(gòu)。

• FST（Finite State Transducers ）實現(xiàn)

FST為一種有限狀態(tài)轉(zhuǎn)移機(jī)，F(xiàn)ST有兩個優(yōu)點：1）空間占用小。通過對詞典中單詞前綴和后綴的重復(fù)利用，壓縮了存儲空間；2）查詢速度快。O(len(str))的查詢時間復(fù)雜度。

以插入“cat”、 “deep”、 “do”、 “dog” 、“dogs”這5個單詞為例構(gòu)建FST（注：必須已排序）。

如圖15 最終我們得到了如上一個有向無環(huán)圖。利用該結(jié)構(gòu)可以很方便的進(jìn)行查詢，如給定一個詞 “dog”，我們可以通過上述結(jié)構(gòu)很方便的查詢存不存在，甚至我們在構(gòu)建過程中可以將單詞與某一數(shù)字、單詞進(jìn)行關(guān)聯(lián)，從而實現(xiàn)key-value的映射。

當(dāng)然還有其他的優(yōu)化方式，如使用Skip List、Trie、Double Array Trie等結(jié)構(gòu)進(jìn)行優(yōu)化，不再一一贅述。

二、ElasticSearch使用心得

下面結(jié)合貸前系統(tǒng)具體的使用案例，介紹ES的一些心得總結(jié)。

2.1 概況

目前使用的ES版本：5.6

官網(wǎng)地址：https://www.elastic.co/products/elasticsearch

ES一句話介紹：The Heart of the Elastic Stack（摘自官網(wǎng)）

ES的一些關(guān)鍵信息：

• 2010年2月首次發(fā)布

• Elasticsearch Store, Search, and Analyze

• 豐富的Restful接口

2.2 基本概念

• 索引（index）

ES的索引，也就是Index，和前面提到的索引并不是一個概念，這里是指所有文檔的集合，可以類比為RDB中的一個數(shù)據(jù)庫。

• 文檔（document）

即寫入ES的一條記錄，一般是JSON形式的。

• 映射（Mapping）

文檔數(shù)據(jù)結(jié)構(gòu)的元數(shù)據(jù)描述，一般是JSON schema形式，可動態(tài)生成或提前預(yù)定義。

• 類型（type）

由于理解和使用上的錯誤，type已不推薦使用，目前我們使用的ES中一個索引只建立了一個默認(rèn)type。

• 節(jié)點

一個ES的服務(wù)實例，稱為一個服務(wù)節(jié)點。為了實現(xiàn)數(shù)據(jù)的安全可靠，并且提高數(shù)據(jù)的查詢性能，ES一般采用集群模式進(jìn)行部署。

• 集群

多個ES節(jié)點相互通信，共同分擔(dān)數(shù)據(jù)的存儲及查詢，這樣就構(gòu)成了一個集群。

• 分片

分片主要是為解決大量數(shù)據(jù)的存儲，將數(shù)據(jù)分割為若干部分，分片一般是均勻分布在各ES節(jié)點上的。需要注意：分片數(shù)量無法修改。

• 副本

分片數(shù)據(jù)的一份完全的復(fù)制，一般一個分片會有一個副本，副本可以提供數(shù)據(jù)查詢，集群環(huán)境下可以提高查詢性能。

2.3 安裝部署

• JDK版本： JDK1.8

• 安裝過程比較簡單，可參考官網(wǎng)：下載安裝包 -> 解壓 -> 運(yùn)行

• 安裝過程遇到的坑:

ES啟動占用的系統(tǒng)資源比較多，需要調(diào)整諸如文件句柄數(shù)、線程數(shù)、內(nèi)存等系統(tǒng)參數(shù)，可參考下面的文檔。

http://www.cnblogs.com/sloveling/p/elasticsearch.html

2.4 實例講解

下面以一些具體的操作介紹ES的使用：

2.4.1 初始化索引

初始化索引，主要是在ES中新建一個索引并初始化一些參數(shù)，包括索引名、文檔映射（Mapping）、索引別名、分片數(shù)（默認(rèn)：5）、副本數(shù)（默認(rèn)：1）等，其中分片數(shù)和副本數(shù)在數(shù)據(jù)量不大的情況下直接使用默認(rèn)值即可，無需配置。

下面舉兩個初始化索引的方式，一個使用基于Dynamic Template（動態(tài)模板） 的Dynamic Mapping（動態(tài)映射），一個使用顯式預(yù)定義映射。

1） 動態(tài)模板 (Dynamic Template)

<p ><span >curl -X PUT http://ip:9200/loan_idx -H 'content-type: application/json' <br>    -d '{"mappings":{ "order_info":{ "dynamic_date_formats":["yyyy-MM-dd HH:mm:ss||yyyy-MM-dd],<br> "dynamic_templates":[<br> {"orderId2":{<br> "match_mapping_type":"string",<br> "match_pattern":"regex",<br> "match":"^orderId$",<br> "mapping":{<br> "type":"long"<br> }<br> }<br> },<br> {"strings_as_keywords":{<br> "match_mapping_type":"string",<br> "mapping":{<br> "type":"keyword",<br> "norms":false<br> }<br> }<br> }<br> ]<br> }<br>},<br>"aliases":{<br> "loan_alias":{}<br>}}'<br></span></p>

上面的JSON串就是我們用到的動態(tài)模板，其中定義了日期格式：dynamic_date_formats 字段；定義了規(guī)則orderId2：凡是遇到orderId這個字段，則將其轉(zhuǎn)換為long型；定義了規(guī)則strings_as_keywords：凡是遇到string類型的字段都映射為keyword類型，norms屬性為false；關(guān)于keyword類型和norms關(guān)鍵字，將在下面的數(shù)據(jù)類型小節(jié)介紹。

2）預(yù)定義映射

預(yù)定義映射和上面的區(qū)別就是預(yù)先把所有已知的字段類型描述寫到mapping里，下圖截取了一部分作為示例：

圖16中JSON結(jié)構(gòu)的上半部分與動態(tài)模板相同，紅框中內(nèi)容內(nèi)容為預(yù)先定義的屬性：apply.applyInfo.appSubmissionTime, apply.applyInfo.applyId, apply.applyInfo.applyInputSource等字段，type表明了該字段的類型，映射定義完成后，再插入的數(shù)據(jù)必須符合字段定義，否則ES將返回異常。

2.4.2 常用數(shù)據(jù)類型

常用的數(shù)據(jù)類型有text, keyword, date, long, double, boolean, ip

實際使用中，將字符串類型定義為keyword而不是text，主要原因是text類型的數(shù)據(jù)會被當(dāng)做文本進(jìn)行語法分析，做一些分詞、過濾等操作，而keyword類型則是當(dāng)做一個完整數(shù)據(jù)存儲起來，省去了多余的操作，提高索引性能。

配合keyword使用的還有一個關(guān)鍵詞norm，置為false表示當(dāng)前字段不參與評分；所謂評分是指根據(jù)單詞的TF/IDF或其他一些規(guī)則，對查詢出的結(jié)果賦予一個分值，供展示搜索結(jié)果時進(jìn)行排序， 而一般的業(yè)務(wù)場景并不需要這樣的排序操作（都有明確的排序字段），從而進(jìn)一步優(yōu)化查詢效率。

2.4.3 索引名無法修改

初始化一個索引，都要在URL中明確指定一個索引名，一旦指定則無法修改，所以一般建立索引都要指定一個默認(rèn)的別名(alias):

<p ><span >"aliases":{ "loan_alias":{ }<br> }<br></span></p>

別名和索引名是多對多的關(guān)系，也就是一個索引可以有多個別名，一個別名也可以映射多個索引；在一對一這種模式下，所有用到索引名的地方都可以用別名進(jìn)行替換；別名的好處就是可以隨時的變動，非常靈活。

2.4.4 Mapping中已存在的字段無法更新

如果一個字段已經(jīng)初始化完畢（動態(tài)映射通過插入數(shù)據(jù)，預(yù)定義通過設(shè)置字段類型），那就確定了該字段的類型，插入不兼容的數(shù)據(jù)則會報錯，比如定義了一個long類型字段，如果寫入一個非數(shù)字類型的數(shù)據(jù)，ES則會返回數(shù)據(jù)類型錯誤的提示。

這種情況下可能就需要重建索引，上面講到的別名就派上了用場；一般分3步完成：

• 新建一個索引將格式錯誤的字段指定為正確格式;
• 2）使用ES的Reindex API將數(shù)據(jù)從舊索引遷移到新索引;
• 3）使用Aliases API將舊索引的別名添加到新索引上，刪除舊索引和別名的關(guān)聯(lián)。

上述步驟適合于離線遷移，如果要實現(xiàn)不停機(jī)實時遷移步驟會稍微復(fù)雜些。

2.4.5 API

基本的操作就是增刪改查，可以參考ES的官方文檔：

https://www.elastic.co/guide/en/elasticsearch/reference/current/docs.html

一些比較復(fù)雜的操作需要用到ES Script，一般使用類Groovy的painless script，這種腳本支持一些常用的JAVA API（ES安裝使用的是JDK8，所以支持一些JDK8的API），還支持Joda time等。

舉個比較復(fù)雜的更新的例子，說明painless script如何使用：

需求描述

appSubmissionTime表示進(jìn)件時間，lenssonStartDate表示開課時間，expectLoanDate表示放款時間。要求2018年9月10日的進(jìn)件，如果進(jìn)件時間 與 開課時間的日期差小于2天，則將放款時間設(shè)置為進(jìn)件時間。

Painless Script如下:

<p ><span >POST loan_idx/_update_by_query<br>    { "script":{ "source":"long getDayDiff(def dateStr1, def dateStr2){ <br>    LocalDateTime date1= toLocalDate(dateStr1); LocalDateTime date2= toLocalDate(dateStr2); ChronoUnit.DAYS.between(date1, date2);<br>  }<br>  LocalDateTime toLocalDate(def dateStr)<br>   { <br>    DateTimeFormatter formatter = DateTimeFormatter.ofPattern(\"yyyy-MM-dd HH:mm:ss\"); LocalDateTime.parse(dateStr, formatter);<br>     }<br>  if(getDayDiff(ctx._source.appSubmissionTime, ctx._source.lenssonStartDate) < 2)<br>  { <br>    ctx._source.expectLoanDate=ctx._source.appSubmissionTime<br>   }", "lang":"painless"<br> }<br> , "query":<br> { "bool":{ "filter":[<br> { "bool":{ "must":[<br> { "range":{ <br> "appSubmissionTime":<br> {<br>  "from":"2018-09-10 00:00:00", "to":"2018-09-10 23:59:59", "include_lower":true, "include_upper":true<br> }<br> }<br> }<br> ]<br> }<br> }<br> ]<br> }<br> }<br>}<br></span></p>

解釋：整個文本分兩部分，下半部分query關(guān)鍵字表示一個按范圍時間查詢（2018年9月10號），上半部分script表示對匹配到的記錄進(jìn)行的操作，是一段類Groovy代碼（有Java基礎(chǔ)很容易讀懂），格式化后如下， 其中定義了兩個方法getDayDiff()和toLocalDate()，if語句里包含了具體的操作：

<p ><span >long getDayDiff(def dateStr1, def dateStr2){<br> LocalDateTime date1= toLocalDate(dateStr1);<br> LocalDateTime date2= toLocalDate(dateStr2);<br> ChronoUnit.DAYS.between(date1, date2);<br>}<br>LocalDateTime toLocalDate(def dateStr){<br> DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");<br> LocalDateTime.parse(dateStr, formatter);<br>}if(getDayDiff(ctx._source.appSubmissionTime, ctx._source.lenssonStartDate) < 2){<br> ctx._source.expectLoanDate=ctx._source.appSubmissionTime<br>}<br></span></p>

然后提交該P(yáng)OST請求，完成數(shù)據(jù)修改。

2.4.6 查詢數(shù)據(jù)

這里重點推薦一個ES的插件ES-SQL:

https://github.com/NLPchina/elasticsearch-sql/wiki/Basic-Queries-And-Conditions

這個插件提供了比較豐富的SQL查詢語法，讓我們可以使用熟悉的SQL語句進(jìn)行數(shù)據(jù)查詢。其中，有幾個需要注意的點：

• ES-SQL使用Http GET方式發(fā)送情況，所以SQL的長度是受限制的(4kb)，可以通過以下參數(shù)進(jìn)行修改：http.max_initial_line_length: "8k"

• 計算總和、平均值這些數(shù)字操作，如果字段被設(shè)置為非數(shù)值類型，直接使用ESQL會報錯，可改用painless腳本。

• 使用Select as語法查詢出的結(jié)果和一般的查詢結(jié)果，數(shù)據(jù)的位置結(jié)構(gòu)是不同的，需要單獨(dú)處理。

• NRT（Near Real Time）：準(zhǔn)實時

向ES中插入一條記錄，然后再查詢出來，一般都能查出最新的記錄，ES給人的感覺就是一個實時的搜索引擎，這也是我們所期望的，然而實際情況卻并非總是如此，這跟ES的寫入機(jī)制有關(guān)，做個簡單介紹：

• Lucene 索引段 -> ES 索引

寫入ES的數(shù)據(jù)，首先是寫入到Lucene索引段中的，然后才寫入ES的索引中，在寫入ES索引前查到的都是舊數(shù)據(jù)。

• commit：原子寫操作

索引段中的數(shù)據(jù)會以原子寫的方式寫入到ES索引中，所以提交到ES的一條記錄，能夠保證完全寫入成功，而不用擔(dān)心只寫入了一部分，而另一部分寫入失敗。

• refresh：刷新操作，可以保證最新的提交被搜索到

索引段提交后還有最后一個步驟：refresh，這步完成后才能保證新索引的數(shù)據(jù)能被搜索到。

出于性能考慮，Lucene推遲了耗時的刷新，因此它不會在每次新增一個文檔的時候刷新，默認(rèn)每秒刷新一次。這種刷新已經(jīng)非常頻繁了，然而有很多應(yīng)用卻需要更快的刷新頻率。如果碰到這種狀況，要么使用其他技術(shù)，要么審視需求是否合理。

不過，ES給我們提供了方便的實時查詢接口，使用該接口查詢出的數(shù)據(jù)總是最新的，調(diào)用方式描述如下：

GET http://IP:PORT/index\_name/type\_name/id

上述接口使用了HTTP GET方法，基于數(shù)據(jù)主鍵（id）進(jìn)行查詢，這種查詢方式會同時查找ES索引和Lucene索引段中的數(shù)據(jù)，并進(jìn)行合并，所以最終結(jié)果總是最新的。但有個副作用：每次執(zhí)行完這個操作，ES就會強(qiáng)制執(zhí)行refresh操作，導(dǎo)致一次IO，如果使用頻繁，對ES性能也會有影響。

2.4.7 數(shù)組處理

數(shù)組的處理比較特殊，拿出來單獨(dú)講一下。

1）表示方式就是普通的JSON數(shù)組格式，如：

[1, 2, 3]、 [“a”, “b”]、 [ { "first" : "John", "last" : "Smith" },{"first" : "Alice", "last" : "White"} ]

2）需要注意ES中并不存在數(shù)組類型，最終會被轉(zhuǎn)換為object，keyword等類型。

3）普通數(shù)組對象查詢的問題。

普通數(shù)組對象的存儲，會把數(shù)據(jù)打平后將字段單獨(dú)存儲，如：

<p ><span >{ "user":[<br> { "first":"John", "last":"Smith"<br> },<br> { "first":"Alice", "last":"White"<br> }<br> ]<br>}<br></span></p>

會轉(zhuǎn)化為下面的文本

<p ><span >{ "user.first":[ "John", "Alice"<br> ], "user.last":[ "Smith", "White"<br> ]<br>}<br></span></p>

將原來文本之間的關(guān)聯(lián)打破了，圖17展示了這條數(shù)據(jù)從進(jìn)入索引到查詢出來的簡略過程：

• 組裝數(shù)據(jù)，一個JSONArray結(jié)構(gòu)的文本。

• 寫入ES后，默認(rèn)類型置為object。

• 查詢user.first為Alice并且user.last為Smith的文檔（實際并不存在同時滿足這兩個條件的）。

• 返回了和預(yù)期不符的結(jié)果。

4）嵌套（Nested）數(shù)組對象查詢

嵌套數(shù)組對象可以解決上面查詢不符的問題，ES的解決方案就是為數(shù)組中的每個對象單獨(dú)建立一個文檔，獨(dú)立于原始文檔。如圖18所示，將數(shù)據(jù)聲明為nested后，再進(jìn)行相同的查詢，返回的是空，因為確實不存在user.first為Alice并且user.last為Smith的文檔。

5）一般對數(shù)組的修改是全量的，如果需要單獨(dú)修改某個字段，需要借助painless script，參考：https://www.elastic.co/guide/en/elasticsearch/reference/5.6/docs-update.html

2.5 安全

數(shù)據(jù)安全是至關(guān)重要的環(huán)節(jié)，主要通過以下三點提供數(shù)據(jù)的訪問安全控制：

• XPACK

XPACK提供了Security插件，可以提供基于用戶名密碼的訪問控制，可以提供一個月的免費(fèi)試用期，過后收取一定的費(fèi)用換取一個license。

• IP白名單

是指在ES服務(wù)器開啟防火墻，配置只有內(nèi)網(wǎng)中若干服務(wù)器可以直接連接本服務(wù)。

• 代理

一般不允許業(yè)務(wù)系統(tǒng)直連ES服務(wù)進(jìn)行查詢，需要對ES接口做一層包裝，這個工作就需要代理去完成；并且代理服務(wù)器可以做一些安全認(rèn)證工作，即使不適用XPACK也可以實現(xiàn)安全控制。

2.6 網(wǎng)絡(luò)

ElasticSearch服務(wù)器默認(rèn)需要開通9200、9300 這兩個端口。

下面主要介紹一個和網(wǎng)絡(luò)相關(guān)的錯誤，如果大家遇到類似的錯誤，可以做個借鑒。

• 引出異常前，先介紹一個網(wǎng)絡(luò)相關(guān)的關(guān)鍵詞，keepalive ：

• Http keep-alive和Tcp keepalive。

HTTP1.1中默認(rèn)啟用"Connection: Keep-Alive"，表示這個HTTP連接可以復(fù)用，下次的HTTP請求就可以直接使用當(dāng)前連接，從而提高性能，一般HTTP連接池實現(xiàn)都用到keep-alive；

TCP的keepalive的作用和HTTP中的不同，TPC中主要用來實現(xiàn)連接?；?，相關(guān)配置主要是net.ipv4.tcp_keepalive_time這個參數(shù)，表示如果經(jīng)過多長時間（默認(rèn)2小時）一個TCP連接沒有交換數(shù)據(jù)，就發(fā)送一個心跳包，探測下當(dāng)前鏈接是否有效，正常情況下會收到對方的ack包，表示這個連接可用。

下面介紹具體異常信息，描述如下：

兩臺業(yè)務(wù)服務(wù)器，用restClient（基于HTTPClient，實現(xiàn)了長連接）連接的ES集群（集群有三臺機(jī)器），與ES服務(wù)器分別部署在不同的網(wǎng)段，有個異常會有規(guī)律的出現(xiàn)：

每天9點左右會發(fā)生異常Connection reset by peer. 而且是連續(xù)有三個Connection reset by peer

<p ><span >Caused by: java.io.IOException: Connection reset by peer <br> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) <br> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) <br> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) <br> at sun.nio.ch.IOUtil.read(IOUtil.java:197)<br></span></p>

為了解決這個問題，我們嘗試了多種方案，查官方文檔、比對代碼、抓包。。。經(jīng)過若干天的努力，最終發(fā)現(xiàn)這個異常是和上面提到keepalive關(guān)鍵詞相關(guān)（多虧運(yùn)維組的同事幫忙）。

實際線上環(huán)境，業(yè)務(wù)服務(wù)器和ES集群之間有一道防火墻，而防火墻策略定義空閑連接超時時間為例如為1小時，與上面提到的linux服務(wù)器默認(rèn)的例如為2小時不一致。由于我們當(dāng)前系統(tǒng)晚上訪問量較少，導(dǎo)致某些連接超過2小時沒有使用，在其中1小時后防火墻自動就終止了當(dāng)前連接，到了2小時后服務(wù)器嘗試發(fā)送心跳?；钸B接，直接被防火墻攔截，若干次嘗試后服務(wù)端發(fā)送RST中斷了鏈接，而此時的客戶端并不知情；當(dāng)?shù)诙煸缟鲜褂眠@個失效的鏈接請求時，服務(wù)端直接返回RST，客戶端報錯Connection reset by peer，嘗試了集群中的三臺服務(wù)器都返回同樣錯誤，所以連續(xù)報了3個相同的異常。解決方案也比較簡單，修改服務(wù)端keepalive超時配置，小于防火墻的1小時即可。

作者：綜合信貸雷鵬

來源：宜信技術(shù)學(xué)院