首先，需要建立一个新的项目，就用一个Maven项目来展示。已经将以下依赖项添加到 pom.xml 文件中：
首先创建一个使用由Storm提供的 TopologyBuilder 的拓扑：
为了设置拓扑喷嘴，调用 TopologyBuilder 实例上的 setSpout 方法，传递一个喷嘴ID和一个喷嘴实例。
这是进入图形计算的切入点。这也可能是一个 KafkaSpout 。 现在有信息进入系统，就想消化它。有时间在拓扑中添加一些螺栓。 把每一个螺栓连接到拓扑，将提供如下信息：
2和3很快就会提到。 那么接下来看看带有所有螺栓的拓扑：
每一次添加一个螺栓到拓扑，都调用 setBolt 。
然后，给螺栓命名，并为该螺栓提供一个实例。该实例是根据每个螺栓所需逻辑实现的类。接下来看一下这样的螺栓。
每个螺栓，已经连接到另一个螺栓或喷嘴，并提供输入。
在验证螺栓的情况下，有两种可能的结果（有效的或无效的），根据每个可能的结果，已经创建了一个只在特定流（验证螺栓正在向其发送消息）上侦听消息的螺栓。
现在来观察一个螺栓的实现。为了符合Storm的架构，需要执行什么？
这里可以看到已经扩展了 BaseRichBolt 类。为了符合其定义，必须实现三种方法。 正如它名字暗示的那样，这个 prepare 方法是一个占位符，一旦元组到达它，就可以执行螺栓所需的任何必要的初始化，以实现恰当的功能。在大多数情况下，至少会将输出收集器引用保存到局部变量中。输出收集器允许发出新的元组到下面的螺栓。 它也允许 确认 一个元组。Storm会将任何未确认的元组视为一个未处理的数据结构，以便重新处理。 execute 方法在每个元组传递时（由Storm基础结构）调用一次。在execute方法中将使用元组，在需要的情况下发出任何新的元组，最后，确认传入的元组。
当想要传递一个特定的字段到下一个螺栓时， declareOutputFields 方法是必需的。例如， PackageGenerationBolt 传递以一个字段名为“ShipmentRequest”的装运请求到下一个螺栓（ShipmentRequestBolt）时，要知道如何引用：
最后，将拓扑提交到集群并运行它。在这个例子中，提交给一个专门为调试而开发的本地集群：
一旦拓扑经过测试和调试，就可以安全地将其部署到 “真实”的Storm集群。 这可以通过几种方式来完成。 一般来说，需要将拓扑连同所有相关的依赖项打包到jar文件中，并将其传递给Storm集群。通过使用命令行来完成更简单。 如果想看到一个“真实的”的demo，请查看 这里 。 如何进行分布式计算？ 太神奇了！现在明白了，把许多计算分解成图形的逻辑和物理形式并不是很难，因为顶点以“标准”形式（序列化元组）进行通信。 现在也知道代码是如何在Storm集群上执行的。 在将拓扑提交给集群后，打包成一个jar文件，拓扑组件（即spouts和bolt）被部署到各个storm工作节点（由主节点决定），并在工作节点中实例化——封装在任务线程中，存在执行过程中。
Storm基础架构知道拓扑内流动的数据流。这个基础架构还通过螺栓跟踪元组确认，为我们提供了可靠的消息传递系统。 内在的并行性：作为并行度的流图形计算的好处之一是，可以在应用程序中清晰地显示单独的计算路径。 看看这里：
有什么东西阻止并行处理两种不同的数据流吗？当然没有，这是Storm的完美任务！ 流是 Storm中的 一种并行的程度 。所有的流元组都将流经相关的螺栓（如拓扑所描述的那样），而不知道拓扑中的其它流。 螺栓（bolt）的实例 这是一个好的开始，是不是？不同的流可以分别单独处理。然而，还有另外一种并行度—在 任务层面 的并行度。作为一个优秀的学生，应该记住任务可以是喷嘴或螺栓的形式。 定义拓扑时，可以声明每个喷嘴或螺栓所需的并行度。
请注意，不希望任务没有控制的按需产生！太多的任务（即线程）会引入过度并行，并可能导致集群“慢下来”，最终让应用程序变得无法响应。 在使用Storm的并行度功能之前，请考虑 想达到的并行度 ， 并提供可用的资源 。 假设有3个Storm工作进程节点，并且部署了一个具有一个并行度设置为2的单个喷嘴的拓扑，以及5个并行度设置为2的螺栓 — storm将为喷嘴生成2个任务，每个螺栓生成5 * 2 = 10 个任务。 这意味着将有12个任务，storm集群将试图均匀地分布在3个工作节点上（下图没有画出所有的线以避免混乱）。
作为内部“秩序者”的分组 还是回到 分组 的概念。 之前已经看到，当创建一个螺栓时，已经指定了它的“输入”螺栓：
但是这样做的方式还不清楚，正如我们所说的那样，需要一个“随机分组”
奇怪，不是吗？分组与之前建立的图形拓扑有什么关系？难道不是所有的流元组都只是从一个螺栓流到另一个螺栓吗？ 那么请记住，喷嘴和螺栓可以有多个实例，以便进行分布式并行计算。 虽然 喷嘴 或 螺栓 在逻辑上是一个原子计算单元，但它的物理实现并不一定。 分组是定义两个不同拓扑元素之间的元组流的方式。它将定义输入实体和目标实体的实例（任务）之间的元组是如何流动的。 例如，“shuffleGrouping”将随机发送元组到螺栓实例。 提醒一下，在讨论分组时，讨论的是两个实体之间的数据流，并且只有两个实体。 在这里，可以看到每个元组是如何随机地转移到一个螺栓实例（任务），从PackageGenerationBolt到ShipmentRequestBolt。
一个最有趣的分组选项是“字段”分组，在这个分组中指定要将元组分组的特定字段。例如，分组 ShipmentRequestBolt 到基于字段“WarehouseId”的 PackageGenerationRequest 。由于这种“字段”的分组策略，所有带有相同 WarehouseId 值的元组，在输入元组时始终被定向到相同的 ShipmentRequestBolt 任务实例。 还有其它有趣的分组方法可以在 这里查看 。 结论 感谢大家与我一起度过这段短暂的旅程，总体地回顾了图形计算的概念和Apache Storm更具体的细节。在写这篇文章的时候，我一直牢记“保持简单”，假设一旦“理解了”这个想法并理解了这个工具，将能够决定你是否需要对Storm进行更深入的研究。这也是我提到额外的阅读和我的Pluralsight课程的原因。 我们从理解图形计算是什么以及它起源于何处开始了这一旅程。特别是理解了它在计算机科学领域是多么深奥的概念。 一旦确信（希望），我们已经开始讨论支持基础架构的好处，以便可靠地将应用程序作为图形计算实现。 我们介绍了Apache Storm这样一种技术。 storm在逻辑层、拓扑层和物理层——物理集群本身进行了回顾。 理解了拓扑如何在整个集群中传播，并在物理层的最终抽象层（任务）中执行。 然后讨论了Storm如何提供并行度— 无论是在流级别和还是在特定任务级别（喷嘴或螺栓）。 看一些代码，我试图传递使用storm的简单和美丽。 希望已经成功地吸引了你。
来自：http://www.iteye.com/news/32830 |
