从本篇开始，我们依次介绍Storm官方文档中的第一部分和第二部分，首先咱们开始使用入门的引言部分。

过去十年，数据处理领域发生了很大的变化，可以认为是发生了一次革命。MapReduce、Hadoop以及其他相关技术使得在存储和处理我们以前无法想象的大规模数据方面成为可能。然后不幸的是，这些数据处理技术并不是实时系统，而且他们命中注定也不是。无法将Hadoop转换成实时系统，因为实时数据处理和批处理在要求上有本质的不同。

然后，大规模地实时数据处理需求在商业应用上已经越来越迫切。数据处理生态中缺少”实时Hadoop“（即类似于Hadoop在批处理领域的通用解决方案）已经成为一个最大的遗憾。Storm弥补了这个遗憾。

在Storm出现之前，我们通常需要手工构建一个由队列和数据处理节点（我们将其称之为”worker“）构成的网络来实时处理数据。Worker从队列中接收消息并加以处理、或者更新数据库、亦或向其他队列发送新的消息以供下游进一步处理。然而这种方式存在一系列的局限性：

1、Tedious：咱们花费了大量的开发时间来配置如何发送消息、部署处理节点和用于在各节点之间其媒介作用的队列。恰恰需要我们花心思重点关注的实时处理逻辑却只占据了很少的比例。

2、Brittle：我们有责任确保每个处理节点和队列可靠持续运行，然后在这方面我们的容错处理很少，系统非常脆弱。

3、Painful to scale：当单个的处理节点或者队列吞吐量过高时，我们需要对其进行重新分配以使消息得以快速处理。我们需要重新配置其他的处理节点以使其知道新的消息发送地址，这就引入了迁移与新建的工作，而在这一过程中非常容易失败。因此，在面临大规模的业务场景下，传统方式会非常痛苦。

虽然，基于队列和处理节点的处理模式在面临大量消息的使用场景时非常容易发生故障，但是，基于消息的处理模式却是实时计算系统中一个非常基础的处理模式。现在的问题是：我们如何设计系统来达到如下几个目标：

1、不丢数据

2、大规模消息的可扩展

3、易于使用与维护

Storm搞定了上述目标，那下面我来看看Storm如何达成这些目标，从而了解其为什么如此重要。

Storm定义了一系列的原语用于处理实时计算。MapReduce对原语的抽象使得编写并行的批处理程序非常容易，类似的，Storm的原语也保证了编写并行的实时计算程序非常简单。

对于Storm，有如下几个关键的特点：

1、极其广泛的使用场景：Storm可以用于消息处理以及在处理过程中更新数据库（即通常所说的流式处理）、基于数据流执行持续查询并将结果以流的方式发送给客户端（即持续计算场景）、并行化查询（即DRPC）等。Storm非常小的原语集满足了大量使用场景的需求。

2、可伸缩性：Storm的伸缩性体现在通过水平扩展得以每秒处理大量消息。对于计算作业（即topology）而言，我们通过添加机器以及提高topology的并行度就可以完成水平扩展。例如：Storm集群有一个应用，目前运行在10个节点构成的集群上，每秒能够处理百万的消息，以及数百次的数据库访问。鉴于Storm自身在集群协调方面采用了Zookeeper，因此，其可以非常容易的扩大集群规模。

3、消息可靠性：对于一个实时系统而言，其需要保证数据被成功处理。一个存在丢数问题的系统在使用场景上会存在很大的局限。Storm可以保证每条消息都被处理，此特性也是Storm与其他实时系统（如S4）一个显著且直接的区别。

4、健壮性：与那些难以管理的系统（如Hadoop）不同，Storm运行与维护非常容易，这也是Storm项目的一个重要目标：改善Storm集群管理者的体验，使Storm集群易于管理。

5、容错：用户计算任务在运行过程中发生错误，Storm会对任务进行重新分配。Storm保证一个计算任务持久运行直至用户主动将其kill

6、编程语言无关性：对于一个平台而言，健壮性和伸缩性是一个基本要求。Storm支持以任意语言来编写计算任务（即Topology）以及处理组件（即Component），从而使得Storm使用尽可能地大众化。