Apache storm社区很高兴的宣布版本1.0.0稳定已经发布，可以从the downloads page下载。这个版本是Apache storm演变的一个重要的里程碑，包括大量的新特性，可用性和性能方面的改进，其中一些如下。

性能提升

该版本主要亮点之一就是性能较之前的版本有一个巨大的性能提升，Apache Storm 1.0 的性能较之前的版本提升16倍，延迟降低了60%。很显然，拓扑基于不同的使用案例和所依赖外部服务不同，性能差别很大，但大多数情况下，用户可以期待一个3X的性能提升比早期版本。

Pacemaker - Heartbeat Server

Pacemaker是一个可选的Storm守护线程，用于处理来自workers的心跳。随着Storm的集群规模的增大，Zookeeper会因为来自workers的大量心跳写入而成为瓶颈，在Zookeeper尝试保持一致性的同时，会产生大量的写磁盘操作和网络传输量。

因为心跳是一个短暂的性质，他们不需要持久化到磁盘或跨节点同步，存储在内存中即可。这正是Pacemaker的作用，Pacemaker的功能与简单的基于内存的键/值对存储一样，目录式键和字节数组值。

分布式缓存API

在过去，它是常见的,开发人员需要的将资源（如查找数据，机器学习模型等）打包成一个topology的jar文件。这种方法的问题是，更新数据需要重新打包和重新部署的拓扑结构。另一个问题是，有时数据可能非常大（千兆字节或更多），其负面影响拓扑的启动时间。

Storm 1.0 版本引入了分布式缓存API，允许文件在拓扑结构之间共享（BLOBs）。在分布式缓存中，文件可以在命令行的任何时间更新，而不需要重新部署拓扑。分布式缓存API允许文件从几个kb大小的几个GB，也支持压缩格式，如ZIP，GZIP。

Storm 1.0 配备了两个实现分布式缓存API：一个主管节点的本地文件系统的支持，和一个由Apache Hadoop HDFS支持。同时还支持实施细粒度的访问控制，通过ACL。

HA Nimbus

使用过Storm用户知道Storm Nimbus服务存在单点故障问题（Nimbus节点挂掉之后，不会影响正在运行的topology），然而，Nimbus节点挂掉之后，不能提交新的 topology和重新分配任务。

Storm 1.0 解决了这个问题，通过在集群中运行多个Nimbus实例和在Nimbus节点挂掉之后按照leader选举机制选举新的Nimbus节点，Nimbus节点可以在任何时间加入和离开集群。HA Nimbus利用分布式缓存API复制来保证在Nimbus节点宕机时topology资源可用 。

原生的流式窗口API

基于窗口型的计算在流式处理中被广泛使用，在流处理中，无限的数据量基于一些标准（比如时间）被划分成有限的数据集，一个计算被施加到一个组，有一个例子是计算出热门的话题。

窗口主要被用来做聚合，拼接，模式匹配等，窗口被视为in-memory表，可以被用于事件的添加和删除。

在过去的版本中，Storm依靠开发者自己开发窗口逻辑，没有一个高层次抽象推荐给开发者使用。

Apache Storm 1.0 现在包括一个本地的窗口API。窗口可以指定以下2个参数，窗口长度：窗口的长度或持续时间滑动间隔：窗口滑动的时间间隔

Storm支持基于时间宽度或事件计数的滑动和滚动窗口。

状态管理--带有自动检查点的有状态bolt

Storm 1.0 引入了一个新的带有自动检查点有状态的bolt API，有状态的bolt很容易实现（只要继承BaseStatefulBolt类即可），可以和topology中的无状态bolt结合。Storm自动的管理bolt的状态和恢复在事件中失败的状态。

Storm 1.0 自带状态实现，支持redis，未来发布的版本中将会加入额外的支持状态存储。

自动反压机制

在之前的Storm版本中，唯一的限制往topology的输入是开启ACKing并设置topology.max.spout.pending。对于一些用户来说，不需要at-least-once 的处理保证，这样的要求就会造成一个显著的性能损失。

Storm 1.0 包括一个新的基于可配置的高/低水印表示为一个任务的缓冲区大小的百分比自动反压机制。如果高水位达到，Storm 1.0 会减慢拓扑的spouts和当低水位时，停止节流。

Storm 的反压机制是实现独立的Spout API，所以现有的所有Spouts都被支持。

资源调度

基于Storm可插拔的拓扑调度API，Storm 1.0 增加了一个新的调度器实现，将内存（堆和堆）和集群中的可用的CPU资源考虑在内。资源感知调度器（又名“RAS调度器”）允许用户指定的内存和CPU为每个拓扑组件（Spouts/Bolts），和Storm将调度workers之间的tasks任务以最好地满足这些要求。

在未来，Storm社区计划扩大RAS实现支持网络资源和架意识等。

动态日志级别

Storm 1.0 现在允许用户和管理员可以动态地改变一个运行拓扑的日志级别设置，从Storm用户界面以及命令行。用户还可以指定一个可选的超时时间，这些变化将被自动恢复。由此产生的日志文件也很容易通过Storm的UI和logviewer服务来查找。

Tuple采样与调试

在调试一个拓扑结构的过程中，很多用户发现需要自己加入Storm“调试”bolts或trident功能，记录有关数据流经的拓扑信息，然后在生产部署时，只能删除或禁用它们。Storm 1.0 消除了种方式。

Storm的UI现在包括一个功能，允许你在从Storm的UI上取样流经一个拓扑或个别部件的一定百分比的tuples。采样的事件可以直接在Strom的用户界面查看，也可以保存到磁盘。

分布式日志搜索

Storm的用户界面的另一个改进是添加一个分布式日志搜索。这个搜索功能允许用户搜索在特定拓扑的所有日志文件，包括归档日志（以zip结尾的）。搜索结果将包括来自所有Supervisor节点的匹配结果。

动态Worker分析

最后，但肯定不是最不重要的，在Storm 1.0 的可用性改进是动态的worker分析。这个新功能允许用户直接从Storm用户界面请求数据，包括：    堆转储    JStack输出    JProfile记录

生成的文件，然后可供下载使用各种调试工具离线分析。现在还可以在Storm的用户界面重启worker。