1. What - what is JStorm ?　

Overview:

　　JStorm is a distributed real-time computing engine, similar to the Hadoop MapReduce system. The user implements a task according to the specified programming specifications, and then submits the task to the JStorm system. JStorm runs the task and runs it 7*24 hours . Once a worker in the middle fails unexpectedly, the scheduler immediately assigns a new worker to replace the failed worker. Therefore, from an application point of view, a JStorm application is a distributed application that complies with a certain programming specification. From a system perspective, JStorm is a scheduling system similar to MapReduce. From the data point of view, it is a set of pipeline-based message processing mechanism. Real-time computing is now the most popular direction in the field of big data, because people's requirements for data are getting higher and higher, and the requirements for real-time performance are getting faster and faster. The traditional Hadoop Map Reduce is gradually unable to meet the demand, so the demand in this field is continuously.

　　Before the emergence of Storm and JStorm , there were many real-time computing engines on the market, but since the emergence of Storm and JStorm , it can basically be said that the arena is unified.

Its advantages:

The development is very fast : the interface is simple and easy to use. As long as you follow the programming specifications of Topology, Spout, and Bolt, you can develop an application with excellent scalability. The underlying rpc, redundancy between workers, data shunting and other actions are completely unnecessary. .
Excellent scalability : When the speed of the first-level processing unit is directly configured, the performance can be linearly expanded.
Robust : When a worker fails or a machine fails, a new worker is automatically assigned to replace the failed worker; the scheduler Nimbus adopts master-slave backup and supports eagerness .
Data accuracy : Acker mechanism can be used to ensure that data is not lost. If there are more requirements for accuracy, a transaction mechanism is used to ensure the accuracy of the data.

Application scenario: The way JStorm processes data is message-based pipeline processing, so it is especially suitable for stateless computing , that is, all the data that the computing unit depends on can be found in the received messages, and preferably one data stream does not depend on another data stream. flow.
　　

Log analysis : analyze specific data from the log, and store the analysis results in an external storage such as a database. At present, the mainstream log analysis technology uses JStorm or Storm
Pipeline system : transfer a data from one system to another system, such as synchronizing a database to Hadoop
Message converter : Convert the received message according to a certain format and store it in another system such as message middleware
Statistical analyzer : Extract a field from the log or message, then perform count or sum calculation, and finally store the statistical value in external memory. Intermediate processing can be more complex.
......

JStorm Architecture:

　　JStorm 从设计的角度，就是一个典型的调度系统。

　　在这个系统中，

- Nimbus是作为调度器角色
- Supervisor 作为worker的代理角色，负责杀死worker和运行worker
- Worker是task的容器
- Task是真正任务的执行者
- ZK 是整个系统中的协调者

具体参考下图：

来自阿里的流处理框架：JStorm

　　关于流处理框架，在先前的文章汇总已经介绍过Strom，今天学习的是来自阿里的的流处理框架JStorm。简单的概述JStorm就是：JStorm 比Storm更稳定，更强大，更快，Storm上跑的程序，一行代码不变可以运行在JStorm上。直白的讲JStorm是阿里巴巴的团队基于Storm的二次开发产物，相当于他们的Tengine是基于Nginx开发的一样。以下为阿里巴巴团队放弃直接使用Storm选择自行开发JStorm的原因：

2、Why——为什么启动JStorm项目？___与storm的区别

阿里拥有自己的实时计算引擎

类似于hadoop 中的MR
开源storm响应太慢
开源社区的速度完全跟不上Ali的需求
降低未来运维成本
提供更多技术支持，加快内部业务响应速度

现有Storm无法满足一些需求

现有storm调度太简单粗暴，无法定制化
Storm 任务分配不平衡
RPC OOM（OOM - Out of Memory，内存溢出 ——俗称雪崩问题）一直没有解决
监控太简单
对ZK 访问频繁

现状

　　在整个阿里巴巴集团，1000+的物理机上运行着Storm，一淘(200+)，CDO(200+)，支付宝(150+)，B2B(50+)，阿里妈妈(50+)，共享事业群(50+)，其他等。

WHY之一句话概述：JStorm比Storm更稳定，功能更强大，更快！(Storm上跑的程序可以一行代码不变运行在JStorm上)

　　JStorm相比Storm更稳定

Nimbus 实现HA：当一台nimbus挂了，自动热切到备份nimbus ——Nimbus HA
原生Storm RPC：Zeromq 使用堆外内存，导致OS 内存不够，Netty 导致OOM；JStorm底层RPC 采用netty + disruptor，保证发送速度和接受速度是匹配的，彻底解决雪崩问题
现有Strom，在添加supervisor或者supervisor shutdown时，会触发任务rebalance；提交新任务时，当worker数不够时，触发其他任务做rebalance。——在JStorm中不会发生，使得数据流更稳定
新上线的任务不会冲击老的任务：新调度从cpu，memory，disk，net 四个角度对任务进行分配；已经分配好的新任务，无需去抢占老任务的cpu，memory，disk和net ——任务之间影响小
Supervisor主线 ——more catch
Spout/Bolt 的open/prepare ——more catch
所有IO, 序列化，反序列化 ——more catch
减少对ZK的访问量：去掉大量无用的watch；task的心跳时间延长一倍；Task心跳检测无需全ZK扫描。

　　JStorm相比Storm调度更强大

彻底解决了storm 任务分配不均衡问题
从4个维度进行任务分配：CPU、Memory、Disk、Net
默认一个task，一个cpu slot。当task消耗更多的cpu时，可以申请更多cpu slot
- 解决新上线的任务去抢占老任务的cpu
- 一淘有些task内部起很多线程，单task消耗太多cpu
默认一个task，一个memory slot。当task需要更多内存时，可以申请更多内存slot
- 先海狗项目中，slot task 需要8G内存，而且其他任务2G内存就够了
默认task，不申请disk slot。当task 磁盘IO较重时，可以申请disk slot
- 海狗/实时同步项目中，task有较重的本地磁盘读写操作
可以强制某个component的task 运行在不同的节点上
- 聚石塔，海狗项目，某些task提供web Service服务，为了端口不冲突，因此必须强制这些task运行在不同节点上
可以强制topology运行在单独一个节点上
- 节省网络带宽
- Tlog中大量小topology，为了减少网络开销，强制任务分配到一个节点上
可以自定义任务分配：提前预约任务分配到哪台机器上，哪个端口，多少个cpu slot，多少内存，是否申请磁盘
- 海狗项目中，部分task期望分配到某些节点上
可以预约上一次成功运行时的任务分配：上次task分配了什么资源，这次还是使用这些资源
- CDO很多任务期待重启后，仍使用老的节点，端口

　　Task内部异步化

Worker内部全流水线模式
Spout nextTuple和ack/fail运行在不同线程

- EagleEye中，在nextTuple做sleep和wait操作不会block ack/fail动作

　　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更底层

附注：和storm编程方式的改变：

　　编程接口改变：当topology.max.spout.pending 设置不为1时（包括topology.max.spout.pending设置为null），spout内部将额外启动一个线程单独执行ack或fail操作，从而nextTuple在单独一个线程中执行，因此允许在nextTuple中执行block动作，而原生的storm，nextTuple/ack/fail 都在一个线程中执行，当数据量不大时，nextTuple立即返回，而ack、fail同样也容易没有数据，进而导致CPU 大量空转，白白浪费CPU，而在JStorm中， nextTuple可以以block方式获取数据，比如从disruptor中或BlockingQueue中获取数据，当没有数据时，直接block住，节省了大量CPU。

　　但因此带来一个问题，处理ack/fail 和nextTuple时，必须小心线程安全性。

　　附属：当topology.max.spout.pending为1时，恢复为spout一个线程，即nextTuple/ack/fail 运行在一个线程中。

JStorm的其他优化点

资源隔离。不同部门，使用不同的组名，每个组有自己的Quato；不同组的资源隔离；采用cgroups 硬隔离
Classloader。解决应用的类和Jstorm的类发生冲突，应用的类在自己的类空间中
Task 内部异步化。Worker 内部全流水线模式，Spout nextTuple和ack/fail运行在不同线程

JStorm与其它产品的比较：

　　Flume 是一个成熟的系统，主要focus在管道上，将数据从一个数据源传输到另外一个数据源，系统提供大量现成的插件做管道作用。当然也可以做一些计算和分析，但插件的开发没有Jstorm便捷和迅速。

　　S4 就是一个半成品，健壮性还可以，但数据准确性较糟糕，无法保证数据不丢失，这个特性让S4 大受限制，也导致了S4开源很多年，但发展一直不是很迅速。

　　AKKA 是一个actor模型，也是一个不错的系统，在这个actor模型基本上，你想做任何事情都没有问题，但问题是你需要做更多的工作，topology怎么生成，怎么序列化。数据怎么流（随机，还是group by）等等。

　　Spark 是一个轻量的内存MR，更偏重批量数据处理。

3、JStorm性能优化：

选型：
按照性能来说， trident < transaction < 使用ack机制普通接口 < 关掉ack机制的普通接口，因此，首先要权衡一下应该选用什么方式来完成任务。

如果“使用ack机制普通接口”时，可以尝试关掉ack机制，查看性能如何，如果性能有大幅提升，则预示着瓶颈不在spout，有可能是Acker的并发少了，或者业务处理逻辑慢了。
增加并发：可以简单增加并发，查看是否能够增加处理能力
让task分配更加均匀：当使用fieldGrouping方式时，有可能造成有的task任务重，有的task任务轻，因此让整个数据流变慢，尽量让task之间压力均匀。
使用MetaQ或Kafka时：对于MetaQ和Kafka，一个分区只能一个线程消费，因此有可能简单的增加并发无法解决问题，可以尝试增加MetaQ和Kafka的分区数。

4、常见问题：

4.1 性能问题

　　参考上面3中JStorm性能优化

4.2 资源不够

　　当报告 ”No supervisor resource is enough for component “，则意味着资源不够如果是仅仅是测试环境，可以将supervisor的cpu 和memory slot设置大，

　　在jstorm中，一个task默认会消耗一个cpu slot和一个memory slot，而一台机器上默认的cpu slot是(cpu 核数 -1）， memory slot数（物理内存大小 * 75%/1g）, 如果一个worker上运行task比较多时，需要将memory slot size设小（默认是1G），比如512M, memory.slot.per.size: 535298048

1 #if it is null, then it will be detect by system
2  supervisor.cpu.slot.num: null
3 
4  #if it is null, then it will be detect by system
5  supervisor.mem.slot.num: null
6 
7 # support disk slot
8 # if it is null, it will use $(storm.local.dir)/worker_shared_data
9  supervisor.disk.slot: null

4.3 序列化问题

　　所有spout，bolt，configuration，发送的消息（Tuple）都必须实现Serializable，否则就会出现序列化错误.

　　如果是spout或bolt的成员变量没有实现Serializable时，但又必须使用时，可以对该变量申明时，增加transient 修饰符，然后在open或prepare时，进行实例化

4.4 Log4j 冲突

　　0.9.0 开始，JStorm依旧使用Log4J，但storm使用Logbak，因此应用程序如果有依赖log4j-over-slf4j.jar，则需要exclude 所有log4j-over-slf4j.jar依赖，下个版本将自定义classloader，就不用担心这个问题。

 1 SLF4J: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path, preempting StackOverflowError. 
 2 SLF4J: See also 
 3 http://www.slf4j.org/codes.html#log4jDelegationLoop for more details.
 4 Exception in thread "main" java.lang.ExceptionInInitializerError
 5         at org.apache.log4j.Logger.getLogger(Logger.java:39)
 6         at org.apache.log4j.Logger.getLogger(Logger.java:43)
 7         at com.alibaba.jstorm.daemon.worker.Worker.<clinit>(Worker.java:32)
 8 Caused by: java.lang.IllegalStateException: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path, preempting StackOverflowError. See also 
 9 http://www.slf4j.org/codes.html#log4jDelegationLoop for more details.
10         at org.apache.log4j.Log4jLoggerFactory.<clinit>(Log4jLoggerFactory.java:49)
11         ... 3 more
12 Could not find the main class: com.alibaba.jstorm.daemon.worker.Worker.  Program will exit.

4.5 类冲突

　　如果应用程序使用和JStorm相同的jar 但版本不一样时，建议打开classloader，修改配置文件

1 topology.enable.classloader: true

　　或者

1 ConfigExtension.setEnableTopologyClassLoader(conf, true);

　　JStorm默认是关掉classloader，因此JStorm会强制使用JStorm依赖的jar

4.6 提交任务后，等待几分钟后，web ui始终没有显示对应的task

　　有3种情况：

　　4.6.1用户程序初始化太慢

　　如果有用户程序的日志输出，则表明是用户的初始化太慢或者出错，查看日志即可。另外对于MetaQ 1.x的应用程序，Spout会recover ~/.meta_recover/目录下文件，可以直接删除这些消费失败的问题，加速启动。

　　4.6.2通常是用户jar冲突或初始化发生问题

　　　　打开supervisor 日志，找出启动worker命令，单独执行，然后检查是否有问题。类似下图：

　　4.6.3检查是不是storm和jstorm使用相同的本地目录

　　　　检查配置项 ”storm.local.dir“，是不是storm和jstorm使用相同的本地目录，如果相同，则将二者分开

4.7 提示端口被绑定

　　有2种情况：

　　4.7.1多个worker抢占一个端口

　　　　假设是6800 端口被占，可以执行命令 “ps -ef|grep 6800” 检查是否有多个进程，如果有多个进程，则手动杀死他们

　　4.7.2系统打开太多的connection

　　　　Linux对外连接端口数限制，TCP client对外发起连接数达到28000左右时，就开始大量抛异常，需要

1 # echo "10000 65535" > /proc/sys/net/ipv4/ip_local_port_range

5、TODO list

Quato，每个group配额
Storm on yarn
应用自定义Hook
权限管理
logview
classloader
upgrade Netty to netty4

参考链接：

Github源码：https://github.com/alibaba/jstorm/

中文文档：https://github.com/alibaba/jstorm/wiki/JStorm-Chinese-Documentation

Comparison of Storm and Storm