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, 不要配置到$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執行命令:
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