1. 程式人生 > >elasticsearch 的兩種連線方式+三種客戶端

elasticsearch 的兩種連線方式+三種客戶端

 

所有語言

所有語言可以使用 RESTful API 通過埠 9200 和 Elasticsearch 進行通訊,你可以用你最喜愛的 web 客戶端訪問 Elasticsearch 。事實上,正如你所看到的,你甚至可以使用 curl 命令來和 Elasticsearch 互動。

1: HTTP客戶端(Rest Client)

HTTP在大多數程式語言中得到很好的支援,這是連線到Elasticsearch的最常見的方法。如果要使用HTTP,還有一個重要的選擇:使用一個現有的Elasticsearch基於HTTP的庫,或者只是建立一個小的包裝器,需要使用HTTP客戶端的操作。 由於HTTP是一個通用協議,並支援各種各樣的用例,一些重要的事情需要由客戶端實現:連線池和保持活動。需要連線池以避免必須支付每個請求的TCP連線建立成本。更重要的,如果它使用HTTPS,這帶來額外的加密握手成本。連線池經常需要保持活動支援,因為我們希望避免連線由於空閒而中斷。 雖然最初顯而易見的是,連線建立實際上是重要的,但是考慮建立TCP連線需要三次握手。簡單地說,使用50毫秒的ping時間,除了獲取和釋放本地資源(處理客戶端埠,連線管理等)所花費的時間之外,建立連線需要大約75毫秒 - 這個沒有考慮在兩端處理請求/響應(例如,序列化)所花費的時間。沒有連線池,這個時間被新增在每個請求的頂部。對於我們建議用於安全和隱私的HTTPS,連線建立開銷有時可以以秒為單位測量,這甚至更顯著。考慮到終端使用者的響應時間必須在100毫秒以下才能被觀察為“即時”的基本建議,即使非加密的開銷也使得這種限制幾乎不可能保持在內。 由Elasticsearch編寫和支援的官方(非Java)客戶端都使用HTTP底層與Elasticsearch進行通訊。一般建議是使用封裝HTTP API的正式客戶端,因為他們負責處理所有這些細節。 HTTP客戶端實現可能相當快,其中一些甚至與本機協議的速度競爭。 Elasticsearch的HTTP API被廣泛使用,並且具有相當多的社群支援。然而,效能取決於客戶端庫,並且通常需要進行配置或調整才能最大化。

 

Java語言 

兩個 Java 客戶端都是通過 9300 埠並使用 Elasticsearch 的原生 傳輸 協議和叢集互動。叢集中的節點通過埠 9300 彼此通訊。如果這個埠沒有開啟,節點將無法形成一個叢集。

2.1  節點客戶端(Node client)

節點客戶端實際上是一個叢集中的節點(但不儲存資料,不能成為主節點)。因為它是一個節點,它知道整個叢集狀態(所有節點駐留,分片分佈在哪些節點,資料在叢集中的具體位置等等),這意味著它可以執行 APIs 而且少了一個網路躍點。能夠直接轉發請求到對應的節點上。Node客戶端與transport client非常相似:它是官方Elasticsearch發行版的一部分,需要客戶端執行Java等,但也有一些顯著的差異。 如果群集對傳輸客戶端是否已連線到群集中的某個節點非常不感興趣,那麼節點客戶端將被視為群集的一部分。這意味著節點客戶端的存在被儲存在群集狀態,並且群集中的所有其他節點將嘗試建立到客戶端的幾個tcp連線。如果群集很大或使用多個客戶端,這可能是一個顯著的缺點。 這可能看起來有點荒謬,但是目前需要它,以便使伺服器節點能夠將對叢集狀態的更改傳播到客戶端。其最終結果是,節點客戶端始終具有最新的叢集狀態和與Elasticsearch叢集中每個其他節點的連線,這使得它能夠在本地執行操作路由,是其自身請求的協調器等等。這會為每個請求跳過網路跳轉,並導致叢集中其餘節點的工作量減少。

2.2 傳輸客戶端(Transport client)

傳輸客戶端作為一種輕量級客戶端,本身不加入叢集,只是簡單的傳送請求到遠端叢集中的節點,作為一個叢集和應用程式之間的通訊層。它知道 API 並能自動幫你在節點之間輪詢,幫你嗅探叢集等等。但它是叢集 外部的 ,和 REST 客戶端類似。我們訪問的節點負責收集各節點返回的資料(query fetch merge),最後一起返回給客戶端。構造transportClient時候,需要指定sniff是否為true。Transport是連線到Elasticsearch的本地方法之一。它是官方Elasticsearch分發的一部分,因此需要客戶端用Java編寫(或至少在JVM上執行)。 它非常快,在JVM上本機執行。序列化是有效的,傳送到/從Elasticsearch例項的訊息和操作中幾乎沒有開銷。它需要保持Elasticsearch伺服器和客戶端版本有些同步。在Elasticsearch 1.0之前,將需要完全相同的版本,但較新的版本(1.0和更高版本)支援版本之間的互動。由於異常序列化和更新之間的其他潛在細微差異,在客戶端和伺服器上執行相同的JVM更新版本也是有益的。 目前不支援加密或身份驗證,但是宣佈不久會滿足這些需求。要在Found.no託管叢集上使用傳輸客戶端,可以使用elasticsearch自定義傳輸模組,該模組負責加密,身份驗證和保持活動。