# 常見 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)。