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, 不要配置到$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

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM