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