- 在拓扑提交过程中，不能实例化没有实现序列化接口的对象。可以通过传递参数的方式，在bolt的prepare中实例化
- 推荐一个worker运行2个task
- 减少拓扑层数，随着拓扑层数的增加，系统吞吐率下降，同时CPU利用率一直在上升，网络带宽未达到极限；
- 最好设置topology.max.spout.pending，这样可以避免长时间的响应，以及抖动。设置topology.max.spout.pending=5000;可以根据系统性能增减
- 在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架马车式架构
1.JStorm从消息中间件中取出数据，计算出结果，存储到外部存储
2.通常消息中间件推荐使用RocketMQ，Kafka，外部存储推荐使用HBase，Mysql
3.该架构，非常方便JStorm程序进行重启（如因为增加业务升级程序）
4.职责清晰化，减少和外部系统的交互，JStorm将计算结果存储到外部存储后，用户的查询就无需访问JStorm中服务进程，查询外部存储即可。
- 在实际计算中，常常发现需要做数据订正，因此在设计整个项目时，需要考虑重跑功能
1.在kafka等队列中，数据最好带时间戳
2.如果计算结果入hadoop或数据库，最好结果也含有时间戳
- 如果使用trasaction时，增加kafka/meta时， brokerId要按顺序，即新增机器brokerId要比之前的都要大，这样reassign spout消费brokerId时就不会发生错位。
- 非事务环境中，尽量使用IBasicBolt
- 计算并发度时，spout 按单task每秒500的QPS计算并发
全内存操作的task，按单task 每秒2000个QPS计算并发
有向外部输出结果的task，按外部系统承受能力进行计算并发。
- 对于MetaQ 和 Kafka，拉取的频率不要太小，低于100ms时，容易造成MetaQ/Kafka 空转次数偏多，一次获取数据Block大小推荐是2M或1M，太大内存GC压力比较大，太小效率比较低。
- 条件允许时，尽量让程序可以报警，比如某种特殊情况出现时，比如截止到凌晨2点，数据还没有同步到hadoop，发送报警出来
- 从jstorm 0.9.5.1 开始， 底层netty同时支持同步模式和异步模式，
1.异步模式， 性能更好， 但容易造成spout 出现fail， 适合在无acker模式下，storm.messaging.netty.sync.mode: false
2.同步模式， 底层是接收端收一条消息，才能发送一条消息， 适合在有acker模式下，storm.messaging.netty.sync.mode: true
作者：glowd
原文：https://blog.csdn.net/zengqiang1/article/details/78450895
版权声明：本文为博主原创文章，转载请附上博文链接！
