elastic search分布式工作原理

前?

• Elasticsearch 是分布式的，但是對(duì)于我們開(kāi)發(fā)者來(lái)說(shuō)并未過(guò)多的參與其中，我們只需啟動(dòng)對(duì)應(yīng)數(shù)量的節(jié)點(diǎn)，并給它們分配相同的 cluster.name 讓它們歸屬于同?個(gè)集群，創(chuàng)建索引的時(shí)候只需指定索引主分?數(shù)和 副分?數(shù) 即可，其他的都交給了 ES 內(nèi)部??去實(shí)現(xiàn)。
• 這和數(shù)據(jù)庫(kù)的分布式和 同源的 solr 實(shí)現(xiàn)分布式都是有區(qū)別的，數(shù)據(jù)庫(kù)要做集群分布式，?如分庫(kù)分表需要我們指定路由規(guī)則和數(shù)據(jù)同步策略等，包括讀寫(xiě)分離，主從同步等，solr的分布式也需依賴(lài) zookeeper，但是 Elasticsearch 完全屏蔽了這些。
• 雖然Elasticsearch 天?就是分布式的，并且在設(shè)計(jì)時(shí)屏蔽了分布式的復(fù)雜性，但是我們還得知道它內(nèi)部的原理。

節(jié)點(diǎn)交互原理

• es和其他中間件?樣，?如mysql，redis有master-slave模式。es集群也會(huì)選舉?個(gè)節(jié)點(diǎn)做為master節(jié)點(diǎn)
• master節(jié)點(diǎn)它的職責(zé)是維護(hù)全局集群狀態(tài)，在節(jié)點(diǎn)加?或離開(kāi)集群的時(shí)候重新分配分?。
• 所有?檔級(jí)別的寫(xiě)操作不會(huì)與master節(jié)點(diǎn)通信，master節(jié)點(diǎn)并不需要涉及到?檔級(jí)別的變更和搜索等操作，es分布式不太像mysql的master-slave模式，mysql是寫(xiě)在主庫(kù)，然后再同步數(shù)據(jù)到從庫(kù)。?es?檔寫(xiě)操作是分?上?不是節(jié)點(diǎn)上，先寫(xiě)在主分?，主分?再同步給副分?，因?yàn)橹鞣?可以分布在不同的節(jié)點(diǎn)上，所以當(dāng)集群只有?個(gè)master節(jié)點(diǎn)的情況下，即使流量的增加它也不會(huì)成為瓶頸，就算它掛了，任何節(jié)點(diǎn)都有機(jī)會(huì)成為主節(jié)點(diǎn)。
• 讀寫(xiě)可以請(qǐng)求任意節(jié)點(diǎn)，節(jié)點(diǎn)再通過(guò)轉(zhuǎn)發(fā)請(qǐng)求到?的節(jié)點(diǎn)，?如?個(gè)?檔的新增，?檔通過(guò)路由算法分配到某個(gè)主分?，然后找到對(duì)應(yīng)的節(jié)點(diǎn)，將數(shù)據(jù)寫(xiě)?到主分?上，然后再同步到副分?上。

寫(xiě)入?檔

• 客戶(hù)端向node-1發(fā)送新增?檔請(qǐng)求。
• 節(jié)點(diǎn)通過(guò)?檔的路由算法確定該?檔屬于主分?-P0。因?yàn)橹鞣?-P0在node-3，所以請(qǐng)求會(huì)轉(zhuǎn)發(fā)到node-3。
• ?檔在node-3的主分?-P0上新增，新增成功后，將請(qǐng)求轉(zhuǎn)發(fā)到node-1和node-2對(duì)應(yīng)的副分?-R0上。?旦所有的副分?都報(bào)告成功，node-3向node-1報(bào)告成功，node-1向客戶(hù)端報(bào)告成功。

讀取?檔

• 客戶(hù)端向node-1發(fā)送讀取?檔請(qǐng)求。
• 在處理讀取請(qǐng)求時(shí)，node-1在每次請(qǐng)求的時(shí)候都會(huì)通過(guò)輪詢(xún)所有的副本分?來(lái)達(dá)到負(fù)載均衡。

elastic search文檔的路由原理

前?

• 當(dāng)新增?個(gè)?檔的時(shí)候，?檔會(huì)被存儲(chǔ)到?個(gè)主分?中。 Elasticsearch 如何知道?個(gè)?檔應(yīng)該存放到哪個(gè)分?中呢？當(dāng)我們創(chuàng)建?檔時(shí)，它如何決定這個(gè)?檔應(yīng)當(dāng)被存儲(chǔ)在分? 1 還是分? 2 中呢？

路由算法

• ?先這肯定不會(huì)是隨機(jī)的，否則將來(lái)要獲取?檔的時(shí)候我們就不知道從何處尋找了。實(shí)際上，這個(gè)過(guò)程是根據(jù)下?這個(gè)公式?jīng)Q定的：

shard

• routing 是?個(gè)可變值，默認(rèn)是?檔的 _id ，也可以設(shè)置成?個(gè)?定義的值。 routing通過(guò) hash 函數(shù)?成?個(gè)數(shù)字，然后這個(gè)數(shù)字再除以 number_of_primary_shards （主分?的數(shù)量）后得到 余數(shù) 。這個(gè)分布在 0 到 number_of_primary_shards-1 之間的余數(shù)，就是我們所尋求的?檔所在分?的位置。
• 這就解釋了為什么我們要在創(chuàng)建索引的時(shí)候就確定好主分?的數(shù)量 并且永遠(yuǎn)不會(huì)改變這個(gè)數(shù)量：因?yàn)槿绻麛?shù)量變化了，那么所有之前路由的值都會(huì)?效，?檔也再也找不到了。
• 新增?個(gè)?檔(指定id)

PUT /nba/_doc/1
{
 "name": "哈登",
 "team_name": "?箭",
 "position": "得分后衛(wèi)",
 "play_year": "10",
 "jerse_no": "13"
}

• 查看?檔在哪個(gè)分?上

GET /nba/_search_shards?routing=1

"nodes":{
        "V1JO7QXLSX-yeVI82WkgtA":{
            "name":"node-1",
            "ephemeral_id":"_d96PgOSTnKo6nrJVqIYpw",
            "transport_address":"192.168.1.101:9300",
            "attributes":{
                "ml.machine_memory":"8589934592",
                "xpack.installed":"true",
                "ml.max_open_jobs":"20"
            }
        },
        "z65Hwe_RR_efA4yj3n8sHQ":{
            "name":"node-3",
            "ephemeral_id":"MOE_Ne7ZRyaKRHFSWJZWpA",
            "transport_address":"192.168.1.101:9500",
            "attributes":{
                "ml.machine_memory":"8589934592",
                "ml.max_open_jobs":"20",
                "xpack.installed":"true"
            }
        }
    },
    "indices":{
        "nba":{

        }
    },
    "shards":[
        [
            {
                "state":"STARTED",
                "primary":true,
                "node":"V1JO7QXLSX-yeVI82WkgtA",
                "relocating_node":null,
                "shard":2,
                "index":"nba",
                "allocation_id":{
                    "id":"leX_k6McShyMoM1eNQJXOA"
                }
            },
            {
                "state":"STARTED",
                "primary":false,
                "node":"z65Hwe_RR_efA4yj3n8sHQ",
                "relocating_node":null,
                "shard":2,
                "index":"nba",
                "allocation_id":{
                    "id":"6sUSANMuSGKLgcIpBa4yYg"
                }
            }
        ]
    ]
}

剖析elastic search的樂(lè)觀鎖

鎖的簡(jiǎn)單分類(lèi)

• 悲觀鎖

顧名思義，就是很悲觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別?會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖，這樣別?想拿這個(gè)數(shù)據(jù)就會(huì)阻塞，直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)?邊就?到了很多這種鎖機(jī)制，?如?鎖，表鎖等，讀鎖，寫(xiě)鎖等，都是在做操作之前先上鎖。

• 樂(lè)觀鎖

顧名思義，就是很樂(lè)觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別?不會(huì)修改，所以不會(huì)上鎖，但是在更新的時(shí)候會(huì)判斷?下在此期間別?有沒(méi)有去更新這個(gè)數(shù)據(jù)，?如可以使?版本號(hào)等機(jī)制。樂(lè)觀鎖適?于多讀的應(yīng)?類(lèi)型，這樣可以提?吞吐量，因?yàn)槲覀僥lasticsearch?般業(yè)務(wù)場(chǎng)景都是寫(xiě)少讀多，所以通過(guò)樂(lè)觀鎖可以在控制并發(fā)的情況下?能有效的提?系統(tǒng)吞吐量。

版本號(hào)樂(lè)觀鎖

• Elasticsearch 中對(duì)?檔的 index ， GET 和 delete 請(qǐng)求時(shí)，都會(huì)返回?個(gè) _version，當(dāng)?檔被修改時(shí)版本號(hào)遞增。
• 所有?檔的更新或刪除 API，都可以接受 version 參數(shù)，這允許你在代碼中使?樂(lè)觀的并發(fā)控制，這?要注意的是版本號(hào)要?于舊的版本號(hào)，并且加上version_type=external。
• 獲取?檔

GET /nba/_doc/1

{
 "_index" : "nba",
 "_type" : "_doc",
 "_id" : "1",
 "_version" : 1,
 "_seq_no" : 4,
 "_primary_term" : 7,
 "found" : true,
 "_source" : {
 "name" : "哈登",
 "team_name" : "?箭",
 "position" : "得分后衛(wèi)",
 "play_year" : "10",
 "jerse_no" : "13"
 }
}

• 通過(guò)版本號(hào)新增?檔(version要?于舊的version)

POST /nba/_doc/1?versinotallow=2&version_type=external
{
 "name": "哈登",
 "team_name": "?箭",
 "position": "得分后衛(wèi)",
 "play_year": "10",
 "jerse_no": "13"
}

淺談elastic search的分詞原理

前言一

• 我們創(chuàng)建?個(gè)?檔

PUT test/_doc/1
{
 "msg":"喬丹是籃球之神"
}

• 我們通過(guò)'喬丹'這個(gè)關(guān)鍵詞來(lái)搜索這個(gè)?檔

POST /test/_search
{
 "query": {
 "match": {
 "msg": "喬丹"
 }
 }
}

• 我們發(fā)現(xiàn)能匹配?檔出來(lái)，那整?個(gè)過(guò)程的原理是怎樣的呢？

前言二

• 我們來(lái)試下使?中?分詞器

PUT test/_mapping
{
 "properties": {
 "msg_chinese":{
 "type":"text",
 "analyzer": "ik_max_word"
 }
 }
}

POST test/_doc/1
{
 "msg":"喬丹是籃球之神",
 "msg_chinese":"喬丹是籃球之神"
}

POST /test/_search
{
 "query": {
 "match": {
 "msg_chinese": "喬"
 }
 }
}

POST /test/_search
{
 "query": {
 "match": {
 "msg": "喬"
 }
 }
}

為什么同樣是輸?'喬'，為什么msg能匹配出?檔，?msg_chinese不能呢？

寫(xiě)時(shí)分詞

• 我們使?來(lái)分析這個(gè)msg這個(gè)字段是怎樣分詞的

POST test/_analyze
{
 "field": "msg",
 "text": "喬丹是籃球之神"
}

喬，丹，是，籃，球，之，神

• 再來(lái)分析這個(gè)msg_chinese這個(gè)字段是怎樣分詞的

POST test/_analyze
{
 "field": "msg_chinese",
 "text": "喬丹是籃球之神"
}

喬丹， 是， 籃球， 之神

• ?檔寫(xiě)?的時(shí)候會(huì)根據(jù)字段設(shè)置的分詞器類(lèi)型進(jìn)?分詞，如果不指定就是默認(rèn)的standard分詞器。
• 寫(xiě)時(shí)分詞器需要在mapping中指定，?且?旦指定就不能再修改，若要修改必須重建索引。

讀時(shí)分詞

• 由于讀時(shí)分詞器默認(rèn)與寫(xiě)時(shí)分詞器默認(rèn)保持?致，拿上?的例?，你搜索 msg 字段，那么讀時(shí)分詞器為 Standard ，搜索 msg_chinese 時(shí)分詞器則為 ik_max_word。這種默認(rèn)設(shè)定也是?常容易理解的，讀寫(xiě)采??致的分詞器，才能盡最?可能保證分詞的結(jié)果是可以匹配的。
• 允許讀時(shí)分詞器單獨(dú)設(shè)置

POST test/_search
{
 "query": {
 "match": {
 "msg_chinese": {
 "query": "喬丹",
 "analyzer": "standard"
 }
 }
 }
}

• ?般來(lái)講不需要特別指定讀時(shí)分詞器，如果讀的時(shí)候不單獨(dú)設(shè)置分詞器，那么讀時(shí)分詞器的驗(yàn)證?法與寫(xiě)時(shí)?致。

深入分析

• 分析器(analyzer)有三部分組成

char filter ： 字符過(guò)濾器

tokenizer ： 分詞器

token filter ：token過(guò)濾器

• char filter（字符過(guò)濾器）

字符過(guò)濾器以字符流的形式接收原始?本，并可以通過(guò)添加、刪除或更改字符來(lái)轉(zhuǎn)換該流。?個(gè)分析器可能有0個(gè)或多個(gè)字符過(guò)濾器。

tokenizer (分詞器)

?個(gè)分詞器接收?個(gè)字符流，并將其拆分成單個(gè)token （通常是單個(gè)單詞），并輸出?個(gè)token流。?如使?whitespace分詞器當(dāng)遇到空格的時(shí)候會(huì)將?本拆分成token。"eating anapple" >> [eating, and, apple]。?個(gè)分析器必須只能有?個(gè)分詞器

POST _analyze
{
 "text": "eating an apple",
 "analyzer": "whitespace"
}

token filter (token過(guò)濾器)

token過(guò)濾器接收token流，并且可能會(huì)添加、刪除或更改tokens。?如?個(gè)lowercase token fifilter可以將所有的token轉(zhuǎn)成?寫(xiě)。?個(gè)分析器可能有0個(gè)或多個(gè)token過(guò)濾器，它們按順序應(yīng)?。

standard分析器

• tokenizer

Stanard tokenizer

• token fifilters

Standard Token Filter

Lower Case Token Filter