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莫名其妙的退出
nohup jstorm supervisor >/dev/null >& &
- 推荐使用admin用户启动所有的程序, 尤其是不要用root用户启动web ui,
- 在安装目录下,建议使用jstorm-current链接, 比如当前使用版本是jstorm 0.9.4, 则创建链接指向jstorm-0.9.4, 当以后升级时, 只需要将jstorm-current链接指向新的jstorm版本。
ln -s jstorm-0.9. jstorm-current
- 将JStorm的本地目录和日志配置到一个公共目录下, 比如/home/admin/jstorm_data 和/home/admin/logs, 不要配置到$JSTORM_HOME/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执行命令:
iptables -t nat -A PREROUTING -p tcp --dport -j REDIRECT --to-port
- Jvm GC 需要使用CMS GC 方式, JStorm默认已经设置, 使用Storm的朋友需要类似的设置,
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左右时,就开始大量抛异常,需要
# 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