并发编程网 - ifeve.com

原文链接    译者：魏勇

本文详细讲解了配置 Storm 开发环境的相关信息。简单地说，配置过程包含以下几个步骤：

1. 下载 Storm 发行版，将其解压缩并复制到你的 PATH 环境变量的 bin 目录中（也可以根据需要自定义安装目录 —— 译者注）；
2. 如果需要在远程集群中运行拓扑，则需要在 ~/.storm/storm.yaml 文件中配置好集群的相关信息。

阅读全文

原文链接    译者：魏勇

在开发拓扑的时候，你需要在 classpath 中包含 Storm 的相关 jar 包。你可以将各个 jar 包直接包含到你的项目的 classpath 中，也可以使用 Maven 将 Storm 添加到依赖项中。Storm 已经集成到 Maven 的中心仓库中。你可以在项目的 pom.xml 中添加以下依赖来将 Storm 包含进项目中：

阅读全文

原文链接    译者：魏勇

在生产环境集群中运行拓扑的方式与本地模式非常相似，主要包括以下几个步骤：

阅读全文

原文链接    译者：魏勇

本文介绍了用户在使用 Storm 过程中遇到的问题与相应的解决方法。

阅读全文

原文链接    译者：魏勇

本地模式是一种在本地进程中模拟 Storm 集群的工作模式，对于开发和测试拓扑很有帮助。在本地模式下运行拓扑与在集群模式下运行拓扑的方式很相似。

阅读全文

原文链接    译者：魏勇

本文详细介绍了 Storm 集群的安装配置方法。如果需要在 AWS 上安装 Storm，你应该先了解一下 storm-deploy 项目。storm-deploy 可以自动完成 E2 上 Storm 集群的准备、配置、安装的全部过程，同时还设置好了 Ganglia，方便监控 CPU、磁盘以及网络的使用信息。

阅读全文

原文链接    译者：魏勇

与一般的 Storm API 一样，spout 也是 Trident 拓扑的数据来源。不过，为了实现更复杂的功能服务，Trident Spout 在普通的 Storm Spout 之上另外提供了一些 API 接口。

数据源、数据流以及基于数据流更新 state（比如数据库）的操作，他们之间的耦合关系是不可避免的。Trident State 一文中有这方面的详细解释，理解他们之间的这种联系对于理解 spout 的运作方式非常重要。

阅读全文

原文链接    译者：魏勇

Trident 中含有对状态化（stateful）的数据源进行读取和写入操作的一级抽象封装工具。这个所谓的状态（state）既可以保存在拓扑内部（保存在内存中并通过 HDFS 来实现备份），也可以存入像 Memcached 或者 Cassandra 这样的外部数据库中。而对于 Trident API 而言，这两种机制并没有任何区别。

阅读全文

原文链接    译者：魏勇

Trident 的核心数据模型是“流”（Stream），不过与普通的拓扑不同的是，这里的流是作为一连串 batch 来处理的。流是分布在集群中的不同节点上运行的，并且对流的操作也是在流的各个 partition 上并行运行的。

阅读全文

原文链接    译者：魏勇

Trident 是 Storm 的一种高度抽象的实时计算模型，它可以将高吞吐量（每秒百万级）数据输入、有状态的流式处理与低延时的分布式查询无缝结合起来。如果你了解 Pig 或者 Cascading 这样的高级批处理工具，你就会发现他们和 Trident 的概念非常相似。Trident 同样有联结（join）、聚合（aggregation）、分组（grouping）、函数（function）以及过滤器（filter）这些功能。Trident 为数据库或者其他持久化存储上层的状态化、增量式处理提供了基础原语。由于 Trident 有着一致的、恰好一次的语义，因此推断出 Trident 拓扑的状态也是一件很容易的事。

阅读全文

原文链接    译者：魏勇

一个运行中的拓扑是由什么构成的：工作进程（worker processes），执行器（executors）和任务（tasks）

在一个 Storm 集群中，Storm 主要通过以下三个部件来运行拓扑：

1. 工作进程（worker processes）
2. 执行器（executors）
3. 任务（tasks）

阅读全文

原文链接    译者：魏勇

本文通过问答的形式解释了 Storm 的容错性原理。

工作进程（worker）死亡时会发生什么？

工作进程死亡的时候，supervisor 会重新启动这个进程。如果在启动过程中仍然一直失败，并且无法向 Nimbus 发送心跳，Nimbus 就会将这个 worker 重新分配到其他机器上去。

阅读全文

原文链接    译者：魏勇

Storm 最佳实践

关于配置 Storm + Trident 的建议

• worker 的数量最好是服务器数量的倍数；topology 的总并发度(parallelism)最好是 worker 数量的倍数；Kafka 的分区数(partitions)最好是 Spout（特指 KafkaSpout）并发度的倍数
• 在每个机器（supervisor）上每个拓扑应用只配置一个 worker
• 在拓扑最开始运行的时候设置使用较少的大聚合器，并且最好是每个 worker 进程分配一个
• 使用独立的调度器（scheduler）来分配任务（关于Scheduler 的知识请参考 xumingming 的博客 —— 译者注）
• 在每个 worker 上只配置使用一个 acker —— 这是 0.9.x 版本的默认特性，不过在早期版本中有所不同
• 在配置文件中开启 GC 日志记录；如果一切正常，日志中记录的 major GC 应该会非常少
• 将 trident 的 batch interval 配置为你的集群的端到端时延的 50% 左右
• 开始时设置一个很小的 TOPOLOGY_MAX_SPOUT_PENDING（对于 trident 可以设置为 1，对于一般的 topology 可以设置为 executor 的数量），然后逐渐增大，直到数据流不再发生变化。这时你可能会发现结果大约等于 “2 × 吞吐率(每秒收到的消息数) × 端到端时延” （最小的额定容量的2倍）。

阅读全文

原文链接    译者：魏勇

本文介绍了 Storm 命令行客户端中的所有命令操作。如果想要了解怎样设置你的 Strom 客户端和远程集群的交互，请按照配置开发环境一文中的步骤操作。

阅读全文

原文链接    译者：魏勇

Storm 能够保证每一个由 Spout 发送的消息都能够得到完整地处理。本文详细解释了 Storm 如何实现这种保障机制，以及作为用户如何使用好 Storm 的可靠性机制。

阅读全文