1、什么是文檔？
文檔由索引（_index）,類型（_type）,唯一標識(_id) 組成，我們為 _index(索引) 分配相關邏輯地址分片，該索引下的數據會根據索引以及類型計算哈希來分配數據存儲的分片，文檔內容為Json格式的文檔體，注意文檔中的字段名稱不能包含英文的句號，實際處理過程中這里最好不要包含符號，索引名稱要用小寫
規則：
值得注意的是：
我們要在創建索引的時候就確定好主分片的數量 並且永遠不會改變這個數量：因為如果數量變化了，那么所有之前路由的值都會無效，文檔也再也找不到了
2、主分片與副分片之前的數據怎么同步呢？
如下 定義三個節點，我們有2個主分片，每個分片有2個副分片，為了保證數據完整性，ES會進行如下分布，這里我們用綠色標識主分片，矩形標識副分片，那么會出現如下分布，保證每個節點上都有完成的分片（主1 和主2 ）數據.
1、Client 發送寫操作到Node1
問題：為什么要發到Node1,比如新加入了一個節點，這節點間的有編排編號嗎？，如果是訪問帶有主節點的，也可以訪問Node2也可以，這之間有什么關聯嗎？
答：每個節點都有能力處理任意請求。 每個節點都知道集群中任一文檔位置，所以可以直接將請求轉發到需要的節點上，一開始進來都是任意一個節點，這個節點知道位置后，會作為協調節點轉發請求到對應的節點上。這里請求Node1是隨機節點，知道文檔存儲在主分片2上轉發到Node2,如果一開始就是Node2節點就不需轉發了，然后協調數據同步后，返回Node1再返回客戶端，寫操作都會直接找主分區所在的節點，我有點懷疑直接進入Node3呢？
2、根據_id發現數據應該存在存在主分片2上，於是轉到Node2，寫入數據
問題：新建、索引和刪除 請求都是 寫 操作， 必須在主分片上面完成之后才能被復制到相關的副本分片，ES應該每個節點上有應該有一個記錄主分片分布的節點記錄，如果設置的自動生成_id的情況，那么怎么去判斷位置？
3、數據同步，寫入Node2中的主分片2成功后，並行寫入2個副分片，等待兩個副分片都應答成功后，然后通知客戶端，防止網絡或者其他問題帶來的數據不一致
那么在數據一致性上Elasticsearch是怎么去處理的？
ES會要求有一定的副分片數量才會執行寫操作，結合上面的 同步副分區，可以設置
int( (primary + number_of_replicas) / 2 ) + 1 ，consistency 參數也可以設置 one（主分區ok即可寫入） 、all（所有主、副分區全部ok才執行寫入）、quorum 默認（大多數的主、副分區沒問題即可寫入，及上面的公式）
出現分布式就需要注意大數據一致性的問題以及，多修改數據丟失的問題？雖然上面的同步能處理數據最終一致性的問題，但是如果出現多個人修改，會導致數據掉丟失的情況。在實際過程我們又怎么來避免這種情況呢？如又這么一組數據
數據data 在 update data1 update data2 2個同時操作的時候會導致數據丟失，加入先get到數據 都是data 但是在update1 update2無論哪個先那個后實際上都會存在數據丟失 如果update1先，update2后，最后數據是 update2的 /myindex/mytable/123 { "myname":"liyouming“, "myage":25 } 如果update2先，update1后，最后數據是 update1的 /myindex/mytable/123 { "myname":"zhangsan“, "myage":22 } 但是實際上我們需要的數據應該是這樣 /myindex/mytable/123 { "myname":"zhangsan“, "myage":25 } 其實仔細想想在我們的實際業務管理系統中也會有這樣的問題，如果兩個人同時打開一個編輯界面同時修改，操作1 在不知道 操作2 修改內容的情況下直接修改，其中會覆蓋一部分的數據丟失掉了
那么ElasticSearch是怎么來處理這個問題的呢？
每個文檔都有一個 _version （版本）號，當文檔被修改時版本號遞增。 Elasticsearch 使用這個 _version 號來確保變更以正確順序得到執行。如果舊版本的文檔在新版本之后到達，它可以被簡單的忽略，我們可以利用 _version 號來確保 應用中相互沖突的變更不會導致數據丟失。
那么我們在來看下上面的demo
在我們查詢出來的時候獲取到版本號 _version 為1，在進行update1 或update2的時候帶上我們的版本號，那么其中后面執行的那個會出現修改失敗，這么就能保證數據丟失的情況了，假定數據update2修改成功了，那么我們得到的數據會是這樣 data2 ,upate1失敗后再次獲取信息 得到版本為2 再次修改成功得到data1最終修改
