億級流量場景下，大型架構設計實現【全文檢索高級搜索---ElasticSearch篇】-- 中

一、Elasticsearch的基礎分佈式架構：

一、Elasticsearch對複雜分佈式機制的透明隱藏特性
二、Elasticsearch的垂直擴容與水平擴容
三、增減或減小節點時的數據rebalance
四、master節點
五、節點對等的分佈式架構

--------------------------------------------------------------------------------------------------------------------

一、Elasticsearch對複雜分佈式機制的透明隱藏特性

Elasticsearch是一套分佈式的系統，分佈式是爲了應對大數據量
隱藏了複雜的分佈式機制

分片機制（咱們以前隨隨便便就將一些document插入到es集羣中去了，咱們有沒有care過數據怎麼進行分片的，數據到哪一個shard中去）

cluster discovery（集羣發現機制，咱們以前在作那個集羣status從yellow轉green的實驗裏，直接啓動了第二個es進程，那個進程做爲一個node自動就發現了集羣，而且加入了進去，還接受了部分數據，replica shard）

shard負載均衡（舉例，假設如今有3個節點，總共有25個shard要分配到3個節點上去，es會自動進行均勻分配，以保持每一個節點的均衡的讀寫負載請求）

shard副本，請求路由，集羣擴容，shard重分配

--------------------------------------------------------------------------------------------------------------------

二、Elasticsearch的垂直擴容與水平擴容

垂直擴容：採購更強大的服務器，成本很是高昂，並且會有瓶頸，假設世界上最強大的服務器容量就是10T，可是當你的總數據量達到5000T的時候，你要採購多少臺最強大的服務器啊

水平擴容：業界常常採用的方案，採購愈來愈多的普通服務器，性能比較通常，可是不少普通服務器組織在一塊兒，就能構成強大的計算和存儲能力

普通服務器：1T，1萬，100萬
強大服務器：10T，50萬，500萬

擴容對應用程序的透明性

--------------------------------------------------------------------------------------------------------------------

三、增減或減小節點時的數據rebalance

保持負載均衡

--------------------------------------------------------------------------------------------------------------------

四、master節點

（1）建立或刪除索引
（2）增長或刪除節點

--------------------------------------------------------------------------------------------------------------------

五、節點平等的分佈式架構

（1）節點對等，每一個節點都能接收全部的請求
（2）自動請求路由
（3）響應收集

 ************************************************ 示例圖 ******************************************

 

 二、shard&replica機制再次梳理以及單個或者兩個node環境中建立index圖解

一、shard&replica機制再次梳理
二、圖解單node環境下建立index是什麼樣子的

------------------------------------------------------------------------------------------------

一、shard&replica機制再次梳理

（1）index包含多個shard
（2）每一個shard都是一個最小工做單元，承載部分數據，lucene實例，完整的創建索引和處理請求的能力
（3）增減節點時，shard會自動在nodes中負載均衡
（4）primary shard和replica shard，每一個document確定只存在於某一個primary shard以及其對應的replica shard中，不可能存在於多個primary shard
（5）replica shard是primary shard的副本，負責容錯，以及承擔讀請求負載
（6）primary shard的數量在建立索引的時候就固定了，replica shard的數量能夠隨時修改
（7）primary shard的默認數量是5，replica默認是1，默認有10個shard，5個primary shard，5個replica shard
（8）primary shard不能和本身的replica shard放在同一個節點上（不然節點宕機，primary shard和副本都丟失，起不到容錯的做用），可是能夠和其餘primary shard的replica shard放在同一個節點上

------------------------------------------------------------------------------------------------

二、圖解單node環境下建立index是什麼樣子的

（1）單node環境下，建立一個index，有3個primary shard，3個replica shard
（2）集羣status是yellow
（3）這個時候，只會將3個primary shard分配到僅有的一個node上去，另外3個replica shard是沒法分配的
（4）集羣能夠正常工做，可是一旦出現節點宕機，數據所有丟失，並且集羣不可用，沒法承接任何請求

PUT /test_index
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}

 

 

二、圖解2個node環境下replica shard是如何分配的

（1）replica shard分配：3個primary shard，3個replica shard，1 node
（2）primary ---> replica同步
（3）讀請求：primary/replica

三、圖解橫向擴容過程，如何超出擴容極限，以及如何提高容錯性
（1）primary&replica自動負載均衡，6個shard，3 primary，3 replica
（2）每一個node有更少的shard，IO/CPU/Memory資源給每一個shard分配更多，每一個shard性能更好
（3）擴容的極限，6個shard（3 primary，3 replica），最多擴容到6臺機器，每一個shard能夠佔用單臺服務器的全部資源，性能最好
（4）超出擴容極限，動態修改replica數量，9個shard（3primary，6 replica），擴容到9臺機器，比3臺機器時，擁有3倍的讀吞吐量
（5）3臺機器下，9個shard（3 primary，6 replica），資源更少，可是容錯性更好，最多容納2臺機器宕機，6個shard只能容納0臺機器宕機
（6）這裏的這些知識點，你綜合起來看，就是說，一方面告訴你擴容的原理，怎麼擴容，怎麼提高系統總體吞吐量；另外一方面要考慮到系統的容錯性，怎麼保證提升容錯性，讓儘量多的服務器宕機，保證數據不丟失

*********************************************************** 擴容過程圖 --------------> 自動進行負載均衡

 

*********************************************************** 容錯圖 --------------> 

**************************************************************** 糾正圖 ---->>

 

四、圖解Elasticsearch容錯機制：master選舉，replica容錯，數據恢復

（1）9 shard，3 node
（2）master node宕機，自動master選舉，red
（3）replica容錯：新master將replica提高爲primary shard，yellow
（4）重啓宕機node，master copy replica到該node，使用原有的shard並同步宕機後的修改，green

 

五、 初步解析document的核心元數據以及圖解剖析index建立反例

一、_index元數據
二、_type元數據
三、_id元數據

{
"_index": "test_index",
"_type": "test_type",
"_id": "1",
"_version": 1,
"found": true,
"_source": {
"test_content": "test test"
}
}

------------------------------------------------------------------------------------------------------------------------------------------

一、_index元數據

（1）表明一個document存放在哪一個index中
（2）相似的數據放在一個索引，非相似的數據放不一樣索引：product index（包含了全部的商品），sales index（包含了全部的商品銷售數據），inventory index（包含了全部庫存相關的數據）。若是你把好比product，sales，human resource（employee），全都放在一個大的index裏面，好比說company index，不合適的。
（3）index中包含了不少相似的document：相似是什麼意思，其實指的就是說，這些document的fields很大一部分是相同的，你說你放了3個document，每一個document的fields都徹底不同，這就不是相似了，就不太適合放到一個index裏面去了。
（4）索引名稱必須是小寫的，不能用下劃線開頭，不能包含逗號：product，website，blog

二、_type元數據

（1）表明document屬於index中的哪一個類別（type）
（2）一個索引一般會劃分爲多個type，邏輯上對index中有些許不一樣的幾類數據進行分類：由於一批相同的數據，可能有不少相同的fields，可是仍是可能會有一些輕微的不一樣，可能會有少數fields是不同的，舉個例子，就好比說，商品，可能劃分爲電子商品，生鮮商品，日化商品，等等。
（3）type名稱能夠是大寫或者小寫，可是同時不能用下劃線開頭，不能包含逗號

三、_id元數據

（1）表明document的惟一標識，與index和type一塊兒，能夠惟一標識和定位一個document
（2）咱們能夠手動指定document的id（put /index/type/id），也能夠不指定，由es自動爲咱們建立一個id

 

六、document id的手動指定與自動生成兩種方式解析

課程大綱

一、手動指定document id
二、自動生成document id

------------------------------------------------------------------------------------------------------------

一、手動指定document id

（1）根據應用狀況來講，是否知足手動指定document id的前提：

通常來講，是從某些其餘的系統中，導入一些數據到es時，會採起這種方式，就是使用系統中已有數據的惟一標識，做爲es中document的id。舉個例子，好比說，咱們如今在開發一個電商網站，作搜索功能，或者是OA系統，作員工檢索功能。這個時候，數據首先會在網站系統或者IT系統內部的數據庫中，會先有一份，此時就確定會有一個數據庫的primary key（自增加，UUID，或者是業務編號）。若是將數據導入到es中，此時就比較適合採用數據在數據庫中已有的primary key。

若是說，咱們是在作一個系統，這個系統主要的數據存儲就是es一種，也就是說，數據產生出來之後，可能就沒有id，直接就放es一個存儲，那麼這個時候，可能就不太適合說手動指定document id的形式了，由於你也不知道id應該是什麼，此時能夠採起下面要講解的讓es自動生成id的方式。

（2）put /index/type/id

PUT /test_index/test_type/2
{
"test_content": "my test"
}

二、自動生成document id

（1）post /index/type

POST /test_index/test_type
{
"test_content": "my test"
}

{
"_index": "test_index",
"_type": "test_type",
"_id": "AVp4RN0bhjxldOOnBxaE",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}

（2）自動生成的id，長度爲20個字符，URL安全，base64編碼，GUID，分佈式系統並行生成時不可能會發生衝突

 

七、document的全量替換、強制建立以及圖解lazy delete機制

一、document的全量替換
二、document的強制建立
三、document的刪除

------------------------------------------------------------------------------------------------------------------------

一、document的全量替換

（1）語法與建立文檔是同樣的，若是document id不存在，那麼就是建立；若是document id已經存在，那麼就是全量替換操做，替換document的json串內容
（2）document是不可變的，若是要修改document的內容，第一種方式就是全量替換，直接對document從新創建索引，替換裏面全部的內容
（3）es會將老的document標記爲deleted，而後新增咱們給定的一個document，當咱們建立愈來愈多的document的時候，es會在適當的時機在後臺自動刪除標記爲deleted的document

------------------------------------------------------------------------------------------------------------------------

二、document的強制建立

（1）建立文檔與全量替換的語法是同樣的，有時咱們只是想新建文檔，不想替換文檔，若是強制進行建立呢？
（2）PUT /index/type/id?op_type=create，PUT /index/type/id/_create

------------------------------------------------------------------------------------------------------------------------

三、document的刪除

（1）DELETE /index/type/id
（2）不會理解物理刪除，只會將其標記爲deleted，當數據愈來愈多的時候，在後臺自動刪除

 

八、深度圖解剖析Elasticsearch併發衝突問題

 

九、分佈式文檔系統-深度圖解剖析悲觀鎖與樂觀鎖兩種併發控制方案

 

十、圖解Elasticsearch內部如何基於_version進行樂觀鎖併發控制

 

（1）_version元數據

PUT /test_index/test_type/6
{
"test_field": "test test"
}

{
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}

第一次建立一個document的時候，它的_version內部版本號就是1；之後，每次對這個document執行修改或者刪除操做，都會對這個_version版本號自動加1；哪怕是刪除，也會對這條數據的版本號加1

{
"found": true,
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 4,
"result": "deleted",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}

咱們會發現，在刪除一個document以後，能夠從一個側面證實，它不是當即物理刪除掉的，由於它的一些版本號等信息仍是保留着的。先刪除一條document，再從新建立這條document，其實會在delete version基礎之上，再把version號加1