2)使用组件的并行度代替线程池
Storm自身是一个分布式的多线程框架,对每个Spout和Bolt,我们都可以设置其并发度,也支持通过rebalance命令来动态调整其并发度,把负载分摊到多个Worker上。如果自己在组件内部采用线程池做一些计算密集型的任务,比如JSON解析,有可能使得某些组件的资源消耗特别高,其他的又很低,导致Worker之间资源消耗不均衡,这种情况在组件的并行度比较低的时候更明显。比如某个Bolt设置了1个并行度,但在Bolt中又启动了线程池。这样导致的一种后果就是集群中分配了这个Bolt的Worker进程可能会把机器的资源都消耗光了,影响到其他Topology在这台机器上的任务的运行。如果真有计算密集型的任务,我们可以把组件的并发度调大点,Worker的数量也相应提高,让计算分配到多个节点上。
为了避免某个Topology的某些组件把整个机器的资源都消耗光的情况,除了不在组件内部启动线程池来做计算以外,也可以通过CGroup对每个Worker的资源使用量做控制。
3) 不要用DRPC批量处理大数据
DRPC提供了应用程序和Storm Topology之间交互的接口。可供其他应用直接调用,使用Storm的并发性来处理数据,然后将结果返回给调用的客户端。这种方式在数据量不大的情况下,通常不会有问题,而当需要处理批量大数据的时候,问题就比较明显了。
(1) 处理数据的Topology在超时之前可能无法返回计算的结果。
(2)批量处理数据,可能使得集群的负载短暂偏高,处理完毕后,又降低回来,负载均衡性差。
4)不要在Spout中处理耗时的操作
Spout中nextTuple方法会发射数据流,在启用Ack的情况下,fail方法和ack方法会被触发。需要明确一点,在Storm中Spout是单线程(JStorm的Spout分为了3个线程,分别执行nextTuple方法、fail方法和ack方法)。如果nextTuple方法非常耗时,某个消息被成功执行完毕后,Acker会给Spout发送消息,Spout若无法及时消费,可能造成ACK消息超时后被丢弃,然后Spout反而认为这个消息执行失败了,造成逻辑错误。反之若fail方法或者ack方法的操作耗时较多,则会影响Spout发射数据,造成Topology吞吐量降低
5)优先使用localOrShuffleGrouping
localOrShuffleGrouping是指如果目标Bolt中的一个或者多个Task和当前产生数据的Task在同一个Worker进程里面,那么就走内部的线程间通信,将Tuple直接发给在当前Worker进程的目的Task,否则,同ShuffleGrouping。localOrShuffleGrouping的数据传输性性能优于shuffleGrouping,因为在Worker内部传输,只需要通过Disruptor队列就可以完成,不用网络开销和序列化开销。