編程界的小學生
一、分佈式架構
1、特點
- 開箱即用，簡單粗暴
Elasticsearch天然支持分佈式和集羣，開箱即用，零配置，零改動。
- 自動分片
一個index默認5個primary shard，那麼我們創建一個document，他給我們分配到哪個shard上了呢？搜索的時候又是怎麼知道我們搜的這個document再哪個shard上呢？這都是es內部爲我們做好的，開發者完全不用關心。
- 自動集羣發現
英文：cluster discovery。我們本機啓動兩個es實例，也就是兩個node節點，默認集羣名稱是elasticsearch，所以他會自動將這兩個node湊成一個集羣，我們什麼都不用配置，它自動發現。
- shard負載均衡
假設我們有1個index，五個primary shard，兩個node，他會自動爲我們將這5個shard分配到兩臺node上，一臺三個shard，一臺兩個shard，我們又加了三臺node，五個node湊成了一個集羣，那麼es會自動爲我們將這五個shard平分到五臺機器，每臺一個shard，這些過程都自動的，開發者啥也不用管。
二、自動集羣發現
我們先啓動一臺es實例，然後通過head插件看是如下效果
1.集羣只有一個node01節點
2.裏面包含一個test_index索引，我們測試用的，自己建的。
我們啓動第二臺（修改端口爲9201），然後再看head插件的集羣信息
1.兩個node了，node1和node2自動湊了一個集羣。我們查的node1的信息（端口9200）發現node2也在裏面了。
2.自動同步主節點的數據，主節點這裏就是node1，因爲它先啓動的。當時就它自己，所以它是老大。
可以發現ES的集羣如此簡單，它自動尋找能湊成集羣的節點，完全不用開發者關心。
三、負載均衡
1、概念
反覆提到的如果只有5個shard，但是有兩臺實例，那麼會自動爲我們在某個實例上分配三個shard，另外一臺分配兩個，全自動進行負載均衡的分配。比如又加了一個node，這時候就會爲我們在某兩臺上分配2個shard，另外一臺一個shard，將服務器請求壓力平分。不用人干預，全自動。
2、兩張圖帶走這個知識點
這時候公司發財了，要擴容一臺node出來。我們再來看效果：
3、補充
1.我只是拿3個shard舉例，實際上1個index就N個shard，而且公司不可能只有1個index，我這裏只是簡單說明原理。
2.問：3個shard，我四個node，這種情況會浪費一臺node的性能嘛？
答：不完全正確，首先，primaryshard確實只會分配到3個node上，但是我們還有replica shard呀，所以第4個node上會存replica shard進行提升吞吐量。並不會完全浪費掉。
3.Master節點用途
- 管理ES集羣中的元數據：比如說索引的增刪改操作，維護集羣的元數據，比如節點的增加和移除。
- 默認情況下，會自動選擇出一臺節點作爲master節點。Master選舉下篇文章來分析。
注意：master節點不承載所有的請求，所以不會是一個單點瓶頸。也就是說Master負責增刪改數據，查詢請求每個節點都會收到，並不是都由Master統一處理。
四、高可用
1、複習Shard
- 1個index包含多個shard
默認5個Primary Shard，1個Replica Shard（是每個PrimaryShard配1個ReplicaShard）
- 每個Shard都是一個lucene實例
每個shard都是一個最小工作單元，承載部分數據，每個shard就是一個lucune實例，完整的建立索引和處理請求的能力
- shard負載均衡
增減節點時，shard會自動在nodes中負載均衡（rebalance）
- 1個document只能存在一個PrimaryShard裏
但是可以存在於多個Replica Shard中，實現高可用、提升吞吐量。
- Replica Shard是primary shard的副本
ReplicaShard用途主要是作爲PrimaryShard的副本，幫PrimaryShard分擔請求，和數據備份。防止node宕機後數據丟失。
- Shard數量
Primary Shard的數量在創建索引的時候就固定了，Replica Shard的數量可以隨時修改。
- Primary Shard不能和自己的Replica Shard放在同一個節點上
否則節點宕機，primary shard和副本都丟失，起不到容錯的作用。
2、高可用
不想打字，一圖定勝負吧。
再囉嗦一句：ES不允許同PrimaryShard和ReplicaShard在同一個node上。比如P0和R0必須在兩個Node裏，否則還是單點故障。
2.1、兩臺node
2.2、三臺node
五、擴容
並不是es擴容是這兩種方案，而是擴容方案是通用的，只是es天然支持水平擴容。
1、垂直擴容
買更牛逼的服務器，價錢沒上限！！！而且瓶頸還會存在。比如你現在10T數據，磁盤滿了，放不下了。現在業務數據總量能到達100T，那你再買個100T的磁盤？那你真有錢，100T滿了咋辦？
2、水平擴容
業界經常採用的方案，採購越來越多的10T服務器，性能比較一般，但是很多10T服務器組織在一起，就能構成強大的存儲能力。（推薦。划算，還不會瓶頸）
3、例如
假設：3臺服務器，每臺容納1T數據，馬上數據量要增長到5T，這時候兩個方案：
（1）垂直擴容：重新購置兩臺服務器，每臺服務器的容量是2T，替換到老的兩臺服務器，那麼現在是6臺服務器的總容量就是1 * 1T + 2 * 2T = 5T
（2）水平擴容：重新購置兩臺服務器，每臺服務器的容量是1T，直接加入到集羣中去，那麼現在是5臺服務器，總容量就是5 * 1T = 5T。（業界幾乎都採取這種方式。）
4、爲什麼說這個
ES天然支持shard負載均衡和自動集羣發現機制，磁盤滿了加同等配置的機器就行了，會自動發現集羣以及自動負載均衡平分shard（數據在shard上）。
再次把上面的【三、負載均衡# 3、補充】裏的內容拿出來。
問：3個shard，我4個node，這種情況會浪費一臺node的性能嘛？
答：不完全正確，首先，primaryshard確實只會分配到3個node上，但是我們還有replica shard呀，所以第4個node上會存replica shard進行提升吞吐量。並不會完全浪費掉。
六、容錯性
我累了，這篇文章2小時了，兄die。直接圖吧
