本章將和大家分享ES的數據同步方案和ES集群相關知識。廢話不多說，下麵我們直接進入主題。 一、ES數據同步 1、數據同步問題 Elasticsearch中的酒店數據來自於mysql資料庫，因此mysql數據發生改變時，Elasticsearch也必須跟著改變，這個就是Elasticsearch與my ...
本章將和大家分享ES的數據同步方案和ES集群相關知識。廢話不多說，下麵我們直接進入主題。
一、ES數據同步
1、數據同步問題
Elasticsearch中的酒店數據來自於mysql資料庫，因此mysql數據發生改變時，Elasticsearch也必須跟著改變，這個就是Elasticsearch與mysql之間的數據同步。
在微服務中，負責酒店管理（操作mysql ）的業務與負責酒店搜索（操作Elasticsearch ）的業務可能在兩個不同的微服務上，數據同步該如何實現呢？
2、數據同步方案一：同步調用
3、數據同步方案二：非同步通知
4、數據同步方案三：監聽binlog
5、數據同步三種方案對比總結
方案一：同步調用
- 優點：實現簡單，粗暴
- 缺點：業務耦合度高
方案二：非同步通知
- 優點：低耦合，實現難度一般
- 缺點：依賴mq的可靠性
方案三：監聽binlog
- 優點：完全解除服務間耦合
- 缺點：開啟binlog增加資料庫負擔、實現複雜度高
二、ES集群
1、ES集群結構
單機的Elasticsearch做數據存儲，必然面臨兩個問題：海量數據存儲問題、單點故障問題。
- 海量數據存儲問題：將索引庫從邏輯上拆分為N個分片（shard），存儲到多個節點。
- 單點故障問題：將分片數據在不同節點備份（replica ）。
| 單點 | 集群 |
|
|
|
2、搭建ES集群
每個索引庫的分片數量、副本數量都是在創建索引庫時指定的，並且分片數量一旦設置以後無法修改。語法如下：
PUT /itcast { "settings": { "number_of_shards": 3, // 分片數量 "number_of_replicas": 1 // 副本數量 }, "mappings": { "properties": { // mapping映射定義 ... } } }
具體的ES搭建此處先不做介紹。
3、ES集群的節點角色
Elasticsearch中集群節點有不同的職責劃分：
| 節點類型 | 配置參數 | 預設值 | 節點職責 |
| master eligible | node.master | true | 備選主節點：主節點可以管理和記錄集群狀態、決定分片在哪個節點、處理創建和刪除索引庫的請求。 |
| data | node.data | true | 數據節點：存儲數據、搜索、聚合、CRUD |
| ingest | node.ingest | true | 數據存儲之前的預處理 |
| coordinating | 上面3個參數都為false則為coordinating節點 | 無 | 協調節點：路由請求到其它節點，合併其它節點處理的結果，返回給用戶 |
4、ES集群的分散式查詢
Elasticsearch中的每個節點角色都有自己不同的職責，因此建議集群部署時，每個節點都有獨立的角色。
5、ES集群的腦裂
預設情況下，每個節點都是master eligible節點，因此一旦master節點宕機，其它候選節點會選舉一個成為主節點。當主節點與其他節點網路故障時，可能發生腦裂問題。
為了避免腦裂，需要要求選票超過 ( eligible節點數量 + 1 ）/ 2 才能當選為主，因此eligible節點數量最好是奇數。對應配置項是discovery.zen.minimum_master_nodes，在es7.0以後，已經成為預設配置，因此一般不會發生腦裂問題。
主從結構腦裂問題示意圖：
| 1、正常時只有一個主節點 | 2、網路阻塞 |
|
|
 |
| 3、另外兩個候選節點node2和node3重新選舉主節點 | 4、網路恢復，此時就出現了兩個主節點，這就是腦裂問題 |
|
|
|
6、小結1
1）master eligible節點的作用是什麼？
- 參與集群選主
- 主節點可以管理集群狀態、管理分片信息、處理創建和刪除索引庫的請求
2）data節點的作用是什麼？
- 數據的CRUD
3）coordinator節點的作用是什麼？
- 路由請求到其它節點
- 合併查詢到的結果，返回給用戶
7、ES集群的分散式存儲
當新增文檔時，應該保存到不同分片，保證數據均衡，那麼coordinating node如何確定數據該存儲到哪個分片呢？
Elasticsearch會通過hash演算法來計算文檔應該存儲到哪個分片：
shard = hash(_routing) % number_of_shards
說明：
- _routing預設是文檔的id
- 演算法與分片數量有關，因此索引庫一旦創建，分片數量不能修改！
新增文檔流程：
8、ES集群的分散式查詢
Elasticsearch的查詢分成兩個階段：
- scatter phase：分散階段，coordinating node會把請求分發到每一個分片。
- gather phase：聚集階段，coordinating node彙總data node的搜索結果，並處理為最終結果集返回給用戶。
9、小結2
1）分散式新增如何確定分片？
- coordinating node根據id做hash運算，得到結果對shard數量取餘，餘數就是對應的分片。
2）分散式查詢的兩個階段
- 分散階段：coordinating node將查詢請求分發給不同分片
- 收集階段：將查詢結果彙總到coordinating node，整理並返回給用戶
10、ES集群的故障轉移
集群的master節點會監控集群中的節點狀態，如果發現有節點宕機，會立即將宕機節點的分片數據遷移到其它節點，確保數據安全，這個叫做故障轉移。
故障轉移示意圖：
| 1、正常狀態 | 2、主節點宕機 |
|
|
 |
| 3、重新選舉主節點 |
|
|
| 4.1、數據遷移 | 4.2、數據遷移 |
|
|
|
故障轉移：
- master宕機後，EligibleMaster選舉為新的主節點。
- master節點監控分片、節點狀態，將故障節點上的分片轉移到正常節點，確保數據安全。
至此本文就全部介紹完了，如果覺得對您有所啟發請記得點個贊哦！！！
