# 常見 Topology 模式
這一頁列出了Strom topologies(拓撲)中的各種常見模式。
1. Batching
2. BasicBolt
3. In-memory caching + fields grouping combo (內存緩存+字段分組組合)
4. Streaming top N
5. TimeCacheMap for efficiently keeping a cache of things that have been recently updated(最近剛剛更新的 TimeCacheMap ,可以有效的存儲緩存數據)
6. CoordinatedBolt and KeyedFairBolt for Distributed RPC(分布式RPC)
### Batching
通常情況下為了效率或者其他原因,你想成批處理一組元組而不是單獨處理一組元組。例如,您希望對數據庫進行批處理更新,或者進行某種類型的流聚合。
如果您希望在數據處理中具有可靠性,那么正確的方法是在實例等待 bolt 進行處理時保留實例變量中的元組。完成批處理操作后,再確認所持有的所有元組。
如果bolt 發出元組,那么您可能會想使用多錨來確保可靠性。這要看具體的應用程序而定。有關可靠性如何工作的詳細信息,請參見[保證消息處理](Guaranteeing-message-processing.html)。
### BasicBolt
許多bolts 遵循類似的閱讀輸入元組模式,基于輸入元組發射零個或多個元組,然后在執行方法結束時會立即確認輸入元組。與此模式匹配的Bolts 類似功能和過濾器。這是一個通用模式,storm會為你暴露一個稱為[IBasicBolt](javadocs/org/apache/storm/topology/IBasicBolt.html) 接口 ,自動化模式。更多信息見[保證消息處理](Guaranteeing-message-processing.html)。
### In-memory caching + fields grouping combo(在內存中緩存+字段分組組合)
在Storm bolts 中使用內存緩存很常見。當把它與fields grouping 相結合時,緩存會變得特別強大。例如,假設你有一個bolt ,用于把短網址(如bit.ly,t.co,等)擴展為長的網址。你可以通過保存短URL的LRU,來緩存長URL的擴展 避免做同樣的HTTP請求 從而提高性能。假設組件“URLS”發出短URLS,組件“expand ”將短URL擴展為長URL并在內部保留緩存。考慮下面兩段代碼之間的區別:
```
builder.setBolt("expand", new ExpandUrl(), parallelism)
.shuffleGrouping(1);
```
```
builder.setBolt("expand", new ExpandUrl(), parallelism)
.fieldsGrouping("urls", new Fields("url"));
```
第二種方法將有更有效的緩存,因為相同的URL將始終指向相同的任務。這避免了任務中緩存的重復,使得短URL更可能命中緩存。
### Streaming top N
一個常見的連續計算Storm 是通過“streaming top N ”的某種排序來實現。假設有一個bolt ,它會發射這種形式的元組["value", "count"] ,并且您希望有一個基于頂部N元組的bolt來計數 。要做到這一點,最簡單的方法是有一個在流上執行全局組的bolt,并在內存中保存一個top N items列表。
顯然,這種方法不能在較大的流中應用,因為整個流必須完成一個任務。一個更好的計算方法是在流的分區上并行地執行上面的多個N‘s,然后合并上面的N‘s 個來得到全局的頂部N:
```
builder.setBolt("rank", new RankObjects(), parallelism)
.fieldsGrouping("objects", new Fields("value"));
builder.setBolt("merge", new MergeObjects())
.globalGrouping("rank");
```
這種模式之所以有效,是因為第一個bolt 所做的字段分組,使您在語義上需要正確的區分。你可以在storm-starter[這里](http://github.com/apache/storm/blob/master%0A/examples/storm-starter/src/jvm/org/apache/storm/starter/RollingTopWords.java) 中 看到這個案例。
然而如果你想處理已知的數據傾斜問題,可以使用partialkeygrouping代替fieldsgrouping 。他將分配兩個downstream bolts 來分布式負載以替代個使用單獨的一個。
```
builder.setBolt("count", new CountObjects(), parallelism)
.partialKeyGrouping("objects", new Fields("value"));
builder.setBolt("rank" new AggregateCountsAndRank(), parallelism)
.fieldsGrouping("count", new Fields("key"))
builder.setBolt("merge", new MergeRanksObjects())
.globalGrouping("rank");
```
topology 需要一個額外的處理層來聚合來自上游螺栓的部分計數,但現在只處理聚合值,所以bolt 不受數據傾斜引起的負載的影響。您可以在storm-starter[這里](http://github.com/apache/storm/blob/master%0A/examples/storm-starter/src/jvm/org/apache/storm/starter/SkewedRollingTopWords.java) 中看到這種模式的示例。
### TimeCacheMap for efficiently keeping a cache of things that have been recently updated (最近剛剛更新的 TimeCacheMap ,可以有效的存儲緩存數據)
有時你想在最近活動的項目中保留一個緩存,并且讓那些已經有一段時間沒用的的條目自動過期。timecachemap就是比較試用這個場景的數據結構,他提供了一種方式,可以在當你需要讓條目過期時添加回調函數。
### CoordinatedBolt and KeyedFairBolt for Distributed RPC(分布式RPC coordinatedbolt和keyedfairbolt)
當在storm頂部構建分布式RPC應用程序時,通常需要兩種常見模式。這些都是由在Storm codebase 中的“standard library” 的[CoordinatedBolt](javadocs/org/apache/storm/task/CoordinatedBolt.html)和[KeyedFairBolt](javadocs/org/apache/storm/task/KeyedFairBolt.html) 封裝的代碼 。
當你的bolt接收到任何給定請求的所有元組時,`CoordinatedBolt`封裝了包含你的邏輯以及算法的bolt 。 它大量使用direct streams 來做到這一點。
`CoordinatedBolt`也封裝了包含邏輯的bolt ,并確保您的topology 同時處理多個DRPC調用,而不是一次一次連續的執行。
有關詳細信息,請參閱[分布式 RPC](Distributed-RPC.html)。
- Storm 基礎
- 概念
- Scheduler(調度器)
- Configuration
- Guaranteeing Message Processing
- 守護進程容錯
- 命令行客戶端
- Storm UI REST API
- 理解 Storm Topology 的 Parallelism(并行度)
- FAQ
- Layers on Top of Storm
- Storm Trident
- Trident 教程
- Trident API 綜述
- Trident State
- Trident Spouts
- Trident RAS API
- Storm SQL
- Storm SQL 集成
- Storm SQL 示例
- Storm SQL 語言參考
- Storm SQL 內部實現
- Flux
- Storm 安裝和部署
- 設置Storm集群
- 本地模式
- 疑難解答
- 在生產集群上運行 Topology
- Maven
- 安全地運行 Apache Storm
- CGroup Enforcement
- Pacemaker
- 資源感知調度器 (Resource Aware Scheduler)
- 用于分析 Storm 的各種內部行為的 Metrics
- Windows 用戶指南
- Storm 中級
- 序列化
- 常見 Topology 模式
- Clojure DSL
- 使用沒有jvm的語言編輯storm
- Distributed RPC
- Transactional Topologies
- Hooks
- Storm Metrics
- Storm 狀態管理
- Windowing Support in Core Storm
- Joining Streams in Storm Core
- Storm Distributed Cache API
- Storm 調試
- 動態日志級別設置
- Storm Logs
- 動態員工分析
- 拓撲事件檢查器
- Storm 與外部系統, 以及其它庫的集成
- Storm Kafka Integration
- Storm Kafka 集成(0.10.x+)
- Storm HBase Integration
- Storm HDFS Integration
- Storm Hive 集成
- Storm Solr 集成
- Storm Cassandra 集成
- Storm JDBC 集成
- Storm JMS 集成
- Storm Redis 集成
- Azue Event Hubs 集成
- Storm Elasticsearch 集成
- Storm MQTT(Message Queuing Telemetry Transport, 消息隊列遙測傳輸) 集成
- Storm MongoDB 集成
- Storm OpenTSDB 集成
- Storm Kinesis 集成
- Storm Druid 集成
- Storm and Kestrel
- Container, Resource Management System Integration
- Storm 高級
- 針對 Storm 定義一個不是 JVM 的 DSL
- 多語言協議
- Storm 內部實現
- 翻譯進度