Storm 1.0.0版本增加了很多新的特性，可用性以及效能也得到了很大的改善，該版本是Storm發展歷程上一個里程碑式的版本，主要特點如下。

效能提升

Storm 1.0.0版本最大的亮點就是效能提升，和之前的版本先比，Storm 1.0的速度能夠提升至16倍，延遲能夠降低至60%。Storm的拓撲效能和應用案例以及依賴的外部服務相關，但是對於大部分應用，相對於之前的版本，效能能夠實現3倍的提升。

Pacemaker-心跳伺服器

Pacemaker在Storm中是一個可選的後臺程序，用來處理Worker心跳。當Storm的叢集規模很大時，所有Worker都向Zookeeper傳送心跳，由於Zookeeper上的資料是寫磁碟的，而且為了實現資料的一致性，Zookeeper中Leader節點與Follow節點要進行通訊，也來帶來大量的網路通訊開銷，所以Zookeeper就容易成為一個性能瓶頸。
由於心跳資料一般是臨時的，所以不需要將其持久化到硬碟上，也不需要跨節點實現資料的同步。把心跳資料儲存到記憶體就行，Pacemaker主要完成的就是這個功能。Pacemaker提供了簡單的基於記憶體的鍵/值儲存，儲存模式類似Zookeeper，Key通過目錄的形式維護，Value就是位元組資料。

分散式快取API

在之前的版本中，Storm開發者一般將拓撲所需要的資源（如查詢資料、機器學習模型）和拓撲打包成一個Topology Jar包。這種實現方式帶來的問題就是更新困難，如果想更新拓撲所依賴的資源，就得重新打包和部署。另一個問題，如果依賴的資料很大（GB或更大）,這會極大的增加拓撲的時啟動時間。
Storm 1.0 版本採用分散式快取API來實現檔案（BLOBs）在多個拓撲之間的共享。分散式快取中的檔案可以通過命令列更新，無需重新部署拓撲。分散式快取中檔案大小可以是幾KB, 也可以是幾GB, 同時也支援ZIP和GZIP壓縮格式。
Storm 1.0支援兩種方式實現分散式快取API。一種是基於Supervisor節點上的本地檔案系統，另外一種基於HDFS實現。這兩種實現都支援細粒度的 ACL 訪問控制。

Nimbus HA

Storm之前的版本中，Nimbus節點存在單點失敗的問題（Nimbus節點掛掉不會影響正在執行的拓撲），但是如果Nimbus節點不存在，使用者不能提交新的拓撲，之前拓撲的任務也不能實現重新分配。
在Storm 1.0中，採用HA Nimbus來解決單點失敗問題。在叢集中執行多個Nimbus 服務例項，當Nimbus節點掛掉時，重新選舉出新的Nimubs 節點，Nimbus主機可以隨時加入或者離開叢集。HA Nimbus通過採取分散式快取API來實現資料的備份，保證拓撲資源的可用性。

原生流式視窗API

基於視窗的計算在流處理中非常普遍，連續的資料流可通過特定的準則（如時間）劃分為離散的多批資料，針對每一批資料可以進行單獨計算。一個典型例子就是計算過去一小時內最流行的Twitter主題。
視窗計算可用來實現聚合，連線，模式匹配等等。視窗可以看做一個基於記憶體的表，基於一定的策略（如時間），事件可以加入到表中也可以從表中刪除。
之前的版本中，Storm開發者需要自己構建視窗計算邏輯，缺少一些高層的抽象，基於這個高層抽象使用者在拓撲中可以以一種標準的方式定義視窗。
Storm 1.0版本中提供了原生的流式視窗API, 視窗定義主要包含兩個引數： 視窗長度和視窗滑動間隔。Storm支援滑動視窗和滾動視窗兩種方式，視窗大小可以基於時間長度或者事件個數。

狀態管理-自動Checkpoint的有狀態的Bolt

Storm 1.0引入了有狀態的Bolt API, 並且支援自動Checkpoint。有狀態的Bolt很容易實現，只需要繼承 BaseStatefulBolt 類即可，在拓撲中，有狀態的Bolt和無狀態的Bolt可以一起使用。Storm可以自動管理Bolt的狀態，比如說自動Checkpoint，而且當發生失敗時，Storm可以恢復Bolt的狀態。
Storm 1.0可以通過記憶體和Redis來實現狀態的管理，之後的版本中，會考慮增加其他的狀態儲存方式。

自動反壓機制

之前的版本中，限制注入到拓撲的資料流量的方式是啟用ACKing機制，並且設定topology.max.spout.pending引數。 當用例不需要實現at-least-once語義容錯時，採用這種方式會極大的降低效能。
Storm 1.0引入了基於高/低水位的自動反壓機制，這裡的水位可通過Task的緩衝區大小來表示。當緩衝區達到高水位時，反壓機制自動觸發，降低Spout的資料注入速率，直到達到低水位為止。
Storm的反壓機制和Spout API是獨立的，所以所有已經存在的Spout都支援自動反壓。

資源感知排程器

Storm支援可插拔的拓撲排程器，Storm 1.0提供了基於資源的排程器，該排程器考慮到了叢集中的記憶體（堆內和堆外）和CPU資源。資源感知排程器（RAS）允許使用者為拓撲元件（Spout/Bolt）指定所需的記憶體和CPU資源，Storm會在不同的Worker之間排程拓撲Task，最大程度上滿足這些Task的資源需求。
未來，Storm社群將會擴充套件RAS實現，考慮網路資源開銷和機架感知。

動態的日誌等級

Storm 1.0允許使用者和管理員動態的調整正在執行的拓撲的日誌等級，這種調整可以通過Storm UI或者命令列實現，使用者也可以配置可選的超時時間，一旦超時，這種改變會自動恢復。日誌檔案可以通過Storm UI或者logviewer服務查詢。

Tuple取樣和除錯

在拓撲的除錯過程中，許多Storm使用者採取增加 Debug Bolt或者Trident 函式來記錄拓撲中的資料流資訊，Storm 1.0中提供了新的拓撲除錯功能。
Storm UI提供了這樣的一個功能，允許使用者對流入到拓撲或者特定的元件中的Tuples進行比例取樣，這些取樣資料可以直接從Storm UI觀測到，也可以存入到硬碟中。

分散式的日誌查詢

Storm UI增加的另一個功能就是分散式的日誌查詢，查詢物件可以是特定拓撲的所有日誌檔案，查詢結果包含所有Supervisor節點的匹配結果。

動態的Worker效能分析

另外一個功能提升就是動態的Worker效能分析，這個新特性允許使用者通過Storm UI獲取Worker的分析資料，包括：
- Heap Dumps
- JStack 輸出
- JProfile 記錄
這些分析資料可以直接下載，用來離線分析，通過Storm UI也可以重啟Workers。