jstorm开发+运维经验总结

1、开发经验总结

 ——12 Sep 2014 · 8
revisions

在jstorm中， spout中nextTuple和ack/fail运行在不同的线程中， 从而鼓励用户在nextTuple里面执行block的操作， 原生的storm，nextTuple和ack/fail在同一个线程，不允许nextTuple/ack/fail执行任何block的操作，否则就会出现数据超时，但带来的问题是，当没有数据时，
整个spout就不停的在空跑，极大的浪费了cpu， 因此，jstorm更改了storm的spout设计，鼓励用户block操作（比如从队列中take消息），从而节省cpu。

在架构上，推荐 “消息中间件 + jstorm + 外部存储” 3架马车式架构
JStorm从消息中间件中取出数据，计算出结果，存储到外部存储上
通常消息中间件推荐使用RocketMQ，Kafka
外部存储推荐使用HBase，Mysql
该架构，非常方便JStorm程序进行重启（如因为增加业务升级程序）
职责清晰化，减少和外部系统的交互，JStorm将计算结果存储到外部存储后，用户的查询就无需访问JStorm中服务进程，查询外部存储即可。 *在实际计算中，常常发现需要做数据订正，因此在设计整个项目时，需要考虑重跑功能 *在meta中，数据最好带时间戳 *如果计算结果入hadoop或数据库，最好结果也含有时间戳

如果使用异步kafka/meta客户端(listener方式)时，当增加/重启meta时，均需要重启topology

如果使用trasaction时，增加kafka/meta时， brokerId要按顺序，即新增机器brokerId要比之前的都要大，这样reassign spout消费brokerId时就不会发生错位。
非事务环境中，尽量使用IBasicBolt
计算并发度时，
spout 按单task每秒500的QPS计算并发
全内存操作的task，按单task 每秒2000个QPS计算并发
有向外部输出结果的task，按外部系统承受能力进行计算并发。

对于MetaQ 和 Kafka推荐一个worker运行2个task
拉取的频率不要太小，低于100ms时，容易造成MetaQ/Kafka 空转次数偏多
一次获取数据Block大小推荐是2M或1M，太大内存GC压力比较大，太小效率比较低。

条件允许时，尽量让程序可以报警，比如某种特殊情况出现时，比如截止到凌晨2点，数据还没有同步到hadoop，发送报警出来
从jstorm 0.9.5.1 开始， 底层netty同时支持同步模式和异步模式，
异步模式， 性能更好， 但容易造成spout 出现fail， 适合在无acker模式下，storm.messaging.netty.sync.mode: false
同步模式， 底层是接收端收一条消息，才能发送一条消息， 适合在有acker模式下，storm.messaging.netty.sync.mode: true

常见经验

使用zookeeper时， 建议使用curator，但不要使用过高的curator版本
数据热点问题
 
 

2、运维经验总结

—— 23 Sep 2014 · 9
revisions

启动supervisor或nimbus最好是以后台方式启动， 避免终端退出时向jstorm发送信号，导致jstorm莫名其妙的退出

1 nohup jstorm supervisor >/dev/null 2>&1 &

推荐使用admin用户启动所有的程序， 尤其是不要用root用户启动web ui，
在安装目录下，建议使用jstorm-current链接， 比如当前使用版本是jstorm 0.9.4， 则创建链接指向jstorm-0.9.4， 当以后升级时， 只需要将jstorm-current链接指向新的jstorm版本。

1 ln -s jstorm-0.9.4 jstorm-current

将JStorm的本地目录和日志配置到一个公共目录下， 比如/home/admin/jstorm_data 和/home/admin/logs， 不要配置到JSTORMHOME/data和JSTORMHOME/data和JSTORM_HOME/logs，当升级时，替换整个目录时，
容易丢失所有的本地数据和日志。
JStorm支持环境变量JSTORM_CONF_DIR, 当设置了该变量时， 会从该目录里读取storm.yaml文件， 因此建议设置该变量，该变量指定的目录存放配置文件storm.yaml，
以后每次升级时，就可以简单的替换目录就可以了
建议不超过1个月，强制重启一下supervisor， 因为supervisor是一个daemon进程， 不停的创建子进程，当使用时间过长时， 文件打开的句柄会非常多，导致启动worker的时间会变慢，因此，建议每隔一周，强制重启一次supervisor
JStorm web ui推荐使用apache tomcat 7.x， 默认的端口是8080， 如果需要将80 端口重定向到8080时， 可以用root执行命令：

1 iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

Jvm GC 需要使用CMS GC 方式， JStorm默认已经设置， 使用Storm的朋友需要类似的设置，

1 worker.childopts: "-Xms1g -Xmx1g -Xmn378m -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=65"

对于一些重要的应用，可以对大集群进行分组， 修改配置文件的 “storm.zookeeper.root” 和 “nimbus.host”
Zeromq推荐2.1.7
64位java 就需要使用64位zeromq
在64位OS上使用32位java， 编译zeromq 增加flag –m32

对于应用使用ZK较频繁的，需要将JStorm的ZK 和应用的ZK 隔离起来，不混在一起使用
nimbus节点上建议不运行supervisor， 并建议把nimbus放置到ZK 所在的机器上运行
推荐slot数为 ”CPU 核 - 1“， 假设24核CPU， 则slot为23
配置cronjob，定时检查nimbus和supervisor，一旦进程死去，自动重启
ZK 的maxClientCnxns=500
Linux对外连接端口数限制，TCP client对外发起连接数达到28000左右时，就开始大量抛异常，需要

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

 
参考链接：
开发经验总结：https://github.com/alibaba/jstorm/wiki/%E5%BC%80%E5%8F%91%E7%BB%8F%E9%AA%8C%E6%80%BB%E7%BB%93
运维经验总结：https://github.com/alibaba/jstorm/wiki/%E8%BF%90%E7%BB%B4%E7%BB%8F%E9%AA%8C%E6%80%BB%E7%BB%93