1. 當我們在說一致性，我們在說什麼？
在分佈式環境下，一致性指的是多個數據副本是否能保持一致的特性。
在一致性的條件下，系統在執行數據更新操作之後能夠從一致性狀態轉移到另一個一致性狀態。
對系統的一個數據更新成功之後，如果所有用戶都能夠讀取到最新的值，該系統就被認爲具有強一致性。
分佈式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分區容忍性（P：Partition Tolerance），最多隻能同時滿足其中兩項。
2. ES 的數據一致性問題
es選舉Master: ES選舉-類Bully算法
Master選舉：程序員小灰拜占庭將軍問題和Raft算法
ES 數據併發衝突控制是基於的樂觀鎖和版本號的機制
一個document第一次創建的時候，它的_version內部版本號就是1；以後，每次對這個document執行修改或者刪除操作，都會對這個_version版本號自動加1；哪怕是刪除，也會對這條數據的版本號加1(假刪除)。
客戶端對es數據做更新的時候，如果帶上了版本號，那帶的版本號與es中文檔的版本號一致才能修改成功，否則拋出異常。如果客戶端沒有帶上版本號，首先會讀取最新版本號才做更新嘗試，這個嘗試類似於CAS操作，可能需要嘗試很多次才能成功。樂觀鎖的好處是不需要互斥鎖的參與。
es節點更新之後會向副本節點同步更新數據(同步寫入)，直到所有副本都更新了才返回成功。
分片向副本同步數據
開個篇，待補充待完善
es節點之間強連通
Elasticsearch Master 節點的職責
- 由主節點負責ping 所有其他節點，判斷是否有節點已經掛掉
- 創建或刪除索引
- 決定分片在節點之間的分配
穩定的主節點對集羣的健康是非常重要的。雖然主節點也可以協調節點，路由搜索和從客戶端新增數據到數據節點，但最好不要使用這些專用的主節點。一個重要的原則是，儘可能做盡量少的工作。
對於大型的生產集羣來說，推薦使用一個專門的主節點來控制集羣，該節點將不處理任何用戶請求。
3. ElasticSearch 的數據實時性
ElasticSearch 是通過怎樣的手段做到數據的近實時搜索的？
一個Index由若干段組成,搜索的時候按段搜索,我們索引一條段後，每個段會通過fsync 操作持久化到磁盤，而fsync 操作比較耗時,如果每索引一條數據都做這個full commit(rsync)操作,提交和查詢的時延都非常之大,所以在這種情況下做不到實時的一個搜索。
FileSystem Cache 與 refresh
針對這個問題的解決是在Elasticsearch和磁盤之間引入一層稱爲FileSystem Cache的系統緩存，正是由於這層cache的存在才使得es能夠擁有更快搜索響應能力。
新的文檔數據寫入緩存區
緩存區的數據寫入一個新段
es中新增的document會被收集到indexing buffer區後被重寫成一個segment然在es中新增的document會被收集到indexing buffer區後被重寫成一個segment然後直接寫入filesystem cache中，這個操作是非常輕量級的，相對耗時較少，之後經過一定的間隔或外部觸發後纔會被flush到磁盤上，這個操作非常耗時。但只要sengment文件被寫入cache後，這個sengment就可以打開和查詢，從而確保在短時間內就可以搜到，而不用執行一個full commit也就是fsync操作，這是一個非常輕量級的處理方式而且是可以高頻次的被執行，而不會破壞es的性能。
在elasticsearch裏面，這個輕量級的寫入和打開一個cache中的segment的操作叫做refresh，默認情況下，es集羣中的每個shard會每隔1秒自動refresh一次，這就是我們爲什麼說es是近實時的搜索引擎而不是實時的，也就是說給索引插入一條數據後，我們需要等待1秒才能被搜到這條數據，這是es對寫入和查詢一個平衡的設置方式，這樣設置既提升了es的索引寫入效率同時也使得es能夠近實時檢索數據。