Apache Storm 官方文檔 —— Trident Spouts

標籤：apache   並發編程   https   tsp   更新   伺服器列表   計數   .com   設定   

轉載自並發編程網 – ifeve.com本文連結地址: Apache Storm 官方文檔 —— Trident Spouts

與一般的 Storm API 一樣，spout 也是 Trident 拓撲的資料來源。不過，為了實現更複雜的功能服務，Trident Spout 在普通的 Storm Spout 之上另外提供了一些 API 介面。

資料來源、資料流以及基於資料流更新 state（比如資料庫）的操作，他們之間的耦合關係是不可避免的。Trident State 一文中有這方面的詳細解釋，理解他們之間的這種聯絡對於理解 spout 的運作方式非常重要。

 

Trident 拓撲中的大部分 spout 都是非事務型 spout。在 Trident 拓撲中可以使用普通的 IRichSpout 介面來建立資料流：

TridentTopology topology = new TridentTopology();topology.newStream("myspoutid", new MyRichSpout());

Trident 拓撲中的所有 spout 都必須有一個唯一的標識，而且這個標識必須在整個 Storm 叢集中都是唯一的。Trident 需要使用這個標識來儲存 spout 從 ZooKeeper 中消費的中繼資料（metadata），包括 txid 以及其他相關的 spout 中繼資料。

你可以使用以下配置項來設定用於儲存 spout 中繼資料的 ZooKeeper 地址（一般情況下不需要設定以下選項，因為 Storm 預設會直接使用叢集的 ZooKeeper 伺服器來儲存資料 —— 譯者注）：

1. transactional.zookeeper.servers：ZooKeeper 的伺服器列表
2. transactional.zookeeper.port：ZooKeeper 叢集的連接埠
3. transactional.zookeeper.root：中繼資料在 ZooKeeper 中儲存的根目錄。中繼資料會直接儲存在該設定目錄下。

管道

預設情況下，Trident 每次處理只一個 batch，知道該 batch 處理成功或者失敗之後才會開始處理其他的 batch。你可以通過將 batch 管道化來提高吞吐率，降低每個 batch 的處理延時。同時處理的 batch 的最大數量可以通過topology.max.spout.pending 來進行配置。

不過，即使在同時處理多個 batch 的情況下，Trident 也會按照 batch 的順序來更新 state。例如，假如你正在處理一個將全域計數結果整合并更新到資料庫中的任務，那麼在你向資料庫中更新 batch1 的計數結果時，你同時可以繼續處理 batch2、batch3 甚至 batch10 的計數工作。不過，Trident 只會在 batch1 的 state 更新結束之後才會處理後續 batch 的 state 更新操作。這是實現恰好一次處理的語義的必要基礎，我們已經在 Trident State 一文中討論了這一點。

Trident spout 類型

下面列出了一些可用的 spout API 介面：

1. ITridentSpout：這是最常用的 API，支援事務型和模糊事務型的語義實現。不過一般會根據需要使用它的某個已有的實現，而不是直接實現該介面。
2. IBatchSpout：非事務型 spout，每次會輸出一個 batch 的 tuple。
3. IPartitionedTridentSpout：可以從分布式資料來源（比如一個叢集或者 Kafka 伺服器）讀取資料的事務型 spout。
4. OpaquePartitionedTridentSpout：可以從分布式資料來源讀取資料的模糊事務型 spout。

當然，正如這篇教程的開頭提到的，除了這些 API 之外，你還可以使用普通的 IRichSpout。

Apache Storm 官方文檔 —— Trident Spouts