Apache Storm，俗称 Hadoop Real-Time，最近给整了整，东西是好，但是因为没有老司机带，按照惯例踩了不少坑，在此记录以备忘。
Kafka Spout 多个executor不工作
这个case是在跑测试数据的时候发现的，当时是用Python写Kafka，测试环境上起了20个Kafka executor，结果死命只有一个executor在动，几度绝望过后联系系统部同事排查发现是可能是测试数据量不够大，Python写Kafka的时候只往一个partition写，而Storm在读Kafka的时候executor默认一一对应partition的，实际到了线上并无什么问题。这里的Kafka以及其Python driver是公司内部定制的，不确定开源版本的Kafka会不会有类似问题。
除了这个之外，在后来Bolt并发设置过高的时候也有出现过多个executor不工作，所以设置executor也要克制。
Tick 时间差参数设置不生效
一开始想着把Tick时间差参数化，这样就不用每次修改都要package，但是参数只能传给Topology 类，所以就把参数放在Topology conf里面，然后在prepare()方法里面取，最后在getComponentConfiguration()方法里面设置Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS，但是getComponentConfiguration()方法是在prepare()之前起的，所以prepare()里面的取值最后并没有用，所以要想参数化Tick的时间差，正解就是在setBolt的时候后面调用一个addConfiguration传参，不过公司内部定制过后的Storm好像是不支持setBolt的时候addConfiguration，最后看其实这个改动并不频繁，还是写死在代码里面了。
Topology性能调优
这个应该坑最多的地方了，因为文档也没法告诉你到底该怎么调，毕竟各人业务代码不一样，随处都可能有坑，有几个点可以注意一下：
- 并发数设置
这个应该就是最基本的了，一般就是在本地写个单元测试用一批数据从头跑到尾，观察各个Component的运行时间，然后大概分配一下executor，分配的时候注意总的executor数目不能太多，不然executor互相之间会抢占资源。如果有多个Spout的话就根据各个Spout的数据量大小来分配，这一步一般不会有太大问题。 - acker 并发设置
因为Storm内部以来acker来跟踪Spout发出的每一个Tuple的Tuple树是否处理完成，所以要注意分配足够多的executor给acker，在Storm UI里应该会有一个__acker，注意它的处理速度不要慢就行。 - 使用localOrShuffleGrouping 来取代 shuffleGrouping
使用localOrShuffleGrouping 的时候如果的目标Bolt在同一工作进程，则会走本地通信，以此减少网络开销。在用localOrShuffleGrouping的时候还得注意的就是如果下游的并发数远高于上游则有可能导致下游executor不工作。 - 设置Spout缓存队列
topology.max.spout.pending 这个参数就是用来设置当下游还有的多少个Tuple没有被处理的时候Spout的就停止发送数据，这个如果设置小了会导致下游bolt处于饥饿状态从而影响这个Topology的处理效率。 - 设置消息超时时间
topology.message.timeout.secs 这个参数是用来设置topology中的spout发送消息的最大处理超时时间，默认是30，因为我一开始是接手的同事之前的代码，而同事当时大概是因为数据量不太大的原因把这个设置成了300，然而如果这个参数设置过大，后面数据量一变大就很容易把Topology拖慢，像我碰到的情况就是一开始性能还可以2w+ Tuple/S，结果过了半个小时就慢下来了，只有几千 Tuple/S，我猜想大概是超时的Message太多然后timeout时间过长浪费了大部分资源。
除了上面这些坑以外，还踩了许多内部系统的坑，折腾了有两三个星期，不过最后还好成功通关，各方面性能都符合预期，嘿嘿~