Elasticsearch中分布式的示例分析

這篇文章給大家分享的是有關Elasticsearch中分布式的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

可用性和擴展性

高可用

服務可用性—允許有節點停止服務

數據可用性—部分節點丟失，不會丟失數據

可擴展性

請求量提升/數據的不斷增長 ，可以實現水平擴展

節點

節點是一個es的實例

本質上就是一個JAVA進程

分片和副本

• 分片特性
  分片存儲部分數據，可以分布任意節點上；
  分片在創建索引時指定且不許更改，默認為5個；
  分片有主副之分，四線數據高可用；
  副本分片的數據由主分片同步，提高讀取吞吐量；

• 實例操作

集群設置：node1/node2/node3，且node1為主節點；創建索引：PUT test_index{  "settings":{    "number_of_shards":3, ##分片數為3    "number_of_replicas":1 ##副本數為1  }}分片和副本分布：node1-p0 r1 node2-p1 r2 node3-p2 r0

• 問題

1-在上述的分布式環境中，增加節點數是否提高test_index的數據容量？不能，因為只有3個分片，且已經分布在3臺節點上，新增節點無法使用；2-增加副本數是否可以提高test_index的讀取吞吐量？不能，新增的副本依然分布在三個節點上，利用同樣資源；3-建議：分片數過小，無法通過新增節點實現水平擴容；分片數過大，導致一個節點上存在多個分片，造成資源浪費；

集群狀態

• 集群狀態
  Green:健康狀態，所有主副分片正常分配；
  Yellow:主分片分配正常，但是副本分片分配不正常；
  Red:存在主分片未分配；

• 故障轉移

文檔分布式存儲

• 文檔到分片的映射
  文檔在分片中盡量分布均勻，充分利用資源；

腦裂問題

• 腦裂
  同一個集群中兩個master，維護不同的cluster state，網絡恢復后無法選擇正確的master；

• 實例操作

文檔搜索實時性

• refresh
  segment寫入磁盤耗時，借助文件系統緩存特性，將segment緩存并開放搜索實時性，稱為refresh；
  refresh之前將文檔存儲到一個buffer中，refresh時將buffer中的文檔清空生成segment；

• translog
  解決內存中segment未寫入磁盤就發生宕機問題；
  文檔寫入buffer時，同時將請求操作寫入translog，6.x默認每個請求都落盤；
  Es啟動時檢查translog文件，并從中恢復數據；
  

• flush
  負責將內存中的segmet寫入磁盤；
  將index buffer清空，其中的文檔生成一個新的segment，相當于一個refresh操作；
  更新commit point并寫入磁盤；
  執行fsync操作，將內存中的segment寫入磁盤；
  刪除舊的translog日志；
  

• 刪除與更新文檔
  segment一旦創建就不能更改，如何刪除與更新文檔呢?

• segment merge
  Es會定時在后臺進行segment merge操作，減少segment的數量；
  通過force_merge api實現手動強制做segment merge；

感謝各位的閱讀！關于“Elasticsearch中分布式的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！