共计 1465 个字符，预计需要花费 4 分钟才能阅读完成。
这篇文章给大家介绍 Storm 和 JStorm 该如何理解，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
简单的概述 Storm 就是：JStorm 比 Storm 更稳定，更强大，更快，Storm 上跑的程序，一行代码不变可以运行在 JStorm 上。直白的将 JStorm 是阿里巴巴的团队基于 Storm 的二次开发产物，相当于他们的 Tengine 是基于 Ngix 开发的一样。
现有 Storm 无法满足一些需求
现有 storm 调度太简单粗暴，无法定制化
Storm 任务分配不平衡
RPC OOM 一直没有解决
监控太简单
对 ZK 访问频繁
JStorm 相比 Storm 更稳定
Nimbus 实现 HA：当一台 nimbus 挂了，自动热切到备份 nimbus
原生 Storm RPC：Zeromq 使用堆外内存，导致 OS 内存不够，Netty 导致 OOM；JStorm 底层 RPC 采用 netty + disruptor 保证发送速度和接受速度是匹配的
新上线的任务不会冲击老的任务：新调度从 cpu，memory，disk，net 四个角度对任务进行分配，已经分配好的新任务，无需去抢占老任务的 cpu，memory，disk 和 net
Supervisor 主线
Spout/Bolt 的 open/prepar
所有 IO, 序列化，反序列化
减少对 ZK 的访问量：去掉大量无用的 watch；task 的心跳时间延长一倍；Task 心跳检测无需全 ZK 扫描。
JStorm 相比 Storm 调度更强大
彻底解决了 storm 任务分配不均衡问题
从 4 个维度进行任务分配：CPU、Memory、Disk、Net
默认一个 task，一个 cpu slot。当 task 消耗更多的 cpu 时，可以申请更多 cpu slot
默认一个 task，一个 memory slot。当 task 需要更多内存时，可以申请更多内存 slot
默认 task，不申请 disk slot。当 task 磁盘 IO 较重时，可以申请 disk slot
可以强制某个 component 的 task 运行在不同的节点上
可以强制 topology 运行在单独一个节点上
可以自定义任务分配，提前预约任务分配到哪台机器上，哪个端口，多少个 cpu slot，多少内存，是否申请磁盘
可以预约上一次成功运行时的任务分配，上次 task 分配了什么资源，这次还是使用这些资源
JStorm 相比 Storm 性能更好
JStorm 0.9.0 性能非常的好，使用 netty 时单 worker 发送最大速度为 11 万 QPS，使用 zeromq 时，最大速度为 12 万 QPS。
JStorm 0.9.0 在使用 Netty 的情况下，比 Storm 0.9.0 使用 netty 情况下，快 10%，并且 JStorm netty 是稳定的而 Storm 的 Netty 是不稳定的
在使用 ZeroMQ 的情况下，JStorm 0.9.0 比 Storm 0.9.0 快 30%
性能提升的原因：
Zeromq 减少一次内存拷贝
增加反序列化线程
重写采样代码，大幅减少采样影响
优化 ack 代码
优化缓冲 map 性能
Java 比 clojure 更底层
JStorm 的其他优化点
资源隔离。不同部门，使用不同的组名，每个组有自己的 Quato；不同组的资源隔离；采用 cgroups 硬隔离
Classloader。解决应用的类和 Jstorm 的类发生冲突，应用的类在自己的类空间中
Task 内部异步化。Worker 内部全流水线模式，Spout nextTuple 和 ack/fail 运行在不同线程
关于 Storm 和 JStorm 该如何理解就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
