标签（空格分隔）： Streaming-Processing
scalability, debug-ability, manageability, and efficient sharing of cluster resources with other data services。
- Storm的worker就是一个JVM进程，每个worker可以跑多个executor，目前根据Storm现有的调度机制，我们无法确定那个task被分配到了哪个worker上，哪台物理机器上。
- 由于不知道task被分配到哪个worker上，有可能是同一个，考虑join的情况，一个join task和一个output 到 DB Store或其他存储的task被分配到同一个worker，这样性能可能无法保证
- 当前正在跑的topology如果重启的话，之前分派在同一个worker的task由于toplogy重启，可不能不会再被分配到同一个worker上，这给debug带来了困难。
- Storm 提供自己实现的isolate 调度，但是要交于开发人员来分配集群资源是个及其不好的做法。
- 资源分配浪费。Storm假设每个worker都是homogenous，这种做法经常会造成在资源预的超额分配。例如3个spouts和1个bolt，加入每个spout和bolt各自需要5G和10G内存，这样的话，topoogy必须为每个worker预留15G的内存来跑一个spout和一个bolt，如果用户设置worker数为2，那么两个worker就要总共预留30G内存，但是实际上只需要 3*5 + 1 *10 = 25G内存，这样就浪费了5G。
- 如果对一个worker进行heap dump时，可能会阻塞worker hearbeats的发送，导致supervisor认为该worker心跳超时，kill 和重启了该worker
- worker用thread和queue来做tuple的接收和发送，每个worker有一个receive-thread接收上游tuple，一个全局send-thread负责往下游发送tuple，然后executor有一个logic-thread来执行用户的代码逻辑，最后有一个本地的send-thread来做logic-thread和全局send-thread做数据通信，到这里，一个tuple需要从进入一个worker到出来总共要通过4个thread转发。
Storm的NImbus任务很多很艰巨，包括调度，监听，分发JAR等等，topology多的时候，Nimbus将变成瓶颈。
- Nimbus调度器不支持worker细粒度的resource reservation和isolation。不同topology的worker被分配到了同一个物理node上，很有可能会相互影响。
- Storm利用Zookeeper来存储worker和supervisor以及executor的心跳信息。如果topology很多，每个topology的并发很多，这样Zookeeper就是瓶颈。
- 就是老生常谈的nimbus单点故障，Nimbus不是HA。
Storm没有backpressure机制，如果下游接收数据的component没有及时处理数据的话，发送者就会drop message。这是一种fail-fast机制，也很简单，但是有以下缺点：
未完待续，下次讲述Twitter的新利器——Heron的架构以及是如何解决上述Storm存在的问题的。
Twitter 新一代流处理利器——Heron 论文笔记之Storm Limitations
原文地址：http://blog.csdn.net/wzhg0508/article/details/46349323
