Storm 使用经验与性能优化（二）

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队列就可以完成，不用网络开销和序列化开销。