ElasticSearch 筆記

　　

ES集羣腦裂出現的緣由:

 

1：網絡緣由

　　內網通常不會出現此問題，能夠監控內網流量狀態。外網的網絡出現問題的可能性大些。

2：節點負載

         主節點即負責管理集羣又要存儲數據，當訪問量大時可能會致使es實例反應不過來而中止響應，此時其餘節點在向主節點發送消息時得不到主節點的響應就會認爲主節點掛了，從而從新選擇主節點。

3：回收內存

         大規模回收內存時也會致使es集羣失去響應。

 

兩節點集羣腦裂的預防:

在一個兩節點集羣，你能夠添加一個新節點並把 node.data 參數設置爲「false」。這樣這個節點不會保存任何分片，但它仍然能夠被選爲主（默認行爲）。由於這個節點是一個無數據節點，因此它能夠放在一臺便宜服務器上。如今你就有了一個三節點的集羣，能夠安全的把minimum_master_nodes設置爲2，避免腦裂並且仍然能夠丟失一個節點而且不會丟失數據。

結論

腦裂問題很難被完全解決。在elasticsearch的問題列表裏仍然有關於這個的問題, 描述了在一個極端狀況下正確設置了minimum_master_nodes的參數時仍然產生了腦裂問題。 elasticsearch項目組正在致力於開發一個選主算法的更好的實現，但若是你已經在運行elasticsearch集羣了那麼你須要知道這個潛在的問題。

 

對於大型的生產集羣來講，推薦使用一個專門的主節點來控制集羣，該節點將不處理任何用戶請求。

 

部落節點：部落節點能夠跨越多個集羣，它能夠接收每一個集羣的狀態，而後合併成一個全局集羣的狀態，它能夠讀寫全部節點上的數據。

 

Elasticseach查詢分爲兩種，結構化查詢和全文查詢；

solr使用zk做爲分佈式管理器, elasticsearch本身維護分佈式管理(腦裂問題)

 

Z 階曲線經過交織點的座標值的二進制表示來簡單地計算多維度中的點的z值。一旦將數據被加到該排序中，任何一維數據結構，例如二叉搜索樹，B樹，跳躍表或（具備低有效位被截斷）哈希表 均可以用來處理數據。經過 Z 階曲線所獲得的順序能夠等同地被描述爲從四叉樹的深度優先遍歷獲得的順序。

這也是 Geohash 的另一個優勢，搜索查找鄰近點比較快。

 

kafka具備高的吞吐量，內部採用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操做，具備O(1)的複雜度，消息處理的效率很高。

rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不同，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操做；基於存儲的可靠性的要求存儲能夠採用內存或者硬盤。

Kafka是可靠的分佈式日誌存儲服務。用簡單的話來講，你能夠把Kafka看成可順序寫入的一大卷磁帶， 能夠隨時倒帶，快進到某個時間點重放

 

ELK通常部署:

 

ELK海量日誌部署:

Filebeat支持異步話, 增長消息隊列機制Kafka