1.grouping分组策略
stream grouping就是用来定义一个stream应该如果分配给Bolts上面的多个Tasks。
storm里面有6种类型的stream grouping:
1.1.Shuffle Grouping: 随机分组， 随机派发stream里面的tuple， 保证每个bolt接收到的tuple数目相同。轮询，平均分配。
1.2 Fields Grouping：按字段分组， 比如按userid来分组， 具有同样userid的tuple会被分到相同的Bolts， 而不同的userid则会被分配到不同的Bolts。
1.3 All Grouping： 广播发送， 对于每一个tuple， 所有的Bolts都会收到。
1.4 Global Grouping: 全局分组， 这个tuple被分配到storm中的一个bolt的其中一个task。再具体一点就是分配给id值最低的那个task。
1.5 Non Grouping: 不分组， 这个分组的意思是说stream不关心到底谁会收到它的tuple。目前这种分组和Shuffle grouping是一样的效果，不平均分配。
1.6 Direct Grouping: 直接分组， 这是一种比较特别的分组方法，用这种分组意味着消息的发送者举鼎由消息接收者的哪个task处理这个消息。 只有被声明为Direct Stream的消息流可以声明这种分组方法。而且这种消息tuple必须使用emitDirect方法来发射。消息处理者可以通过TopologyContext来或者处理它的消息的taskid (OutputCollector.emit方法也会返回taskid)
2.worker、executor和task之间的关系
备注：一个topology可以包含一个或多个worker(并行地跑在不同的machine上)，并且worker只能对应一个topology。
一个worker可以包含一个和多个executor,每个component(spout或bolt)至少对应于一个executor,同时一个executor只能对应于一个component.
task是具体的处理逻辑对象，一个executor线程可以执行一个或多个同类型的tasks
task代表最大并发度，一个component的task数是不会改变的，但是一个component的executor数目是会发生变化的，task数>=executor数，executor数代表实际并发送。
3.各个节点间的作用
3.1 nimbus主节点：
3.1.1 接收客户端提交的任务请求，任务由Nimbus进行分配，将分配信息提交到Zookeeper集群（在Zookeeper相应的znode节点上写入任务分配信息，由supervisor查看这些znode上的任务分配 信息，获取分配到的任务）
3.1.2 监控整个集群的状态（从Zookeeper集群中相应znode上读取supervisor、worker进程的状态信息数据）
3.1.3 容错：当任务在某些Supervisor节点上运行的时候由于Supervisor进程失效，重新将这些任务分配给其他supervisor运行
3.2 Supervisor：
3.2.1 需要定时将自己的运行状态信息（心跳信息）汇报给zookeeper（在Zookeeper相应的znode节点上写入心跳信息）
3.2.2 接收Nimbus分配给它的任务，负责启动、停止工作进程worker，其本身并不是执行任务的工作进程，worker的容错由Supervisor进程负责
3.3 worker进程：并不是常驻进程，不能通过手动启动
真正执行任务的进程 ,worker进程启动后，也会定时将状态信息汇报给zookeeper
3.4 executor 线程：
由worker进程来启动，executor负责执行客户提交到Storm集群上任务中Task(spout/bolt)
4.并发设置
4.1 设置worker工作进程并发
config.setNumWorkers(3);
4.2 设置executor工作线程并发
builder.setBolt(SPLITE_SBOLT, new SplitWordBolt(),2)
4.3 设置task任务级别的并发
builder.setBolt(SPLITE_SBOLT, new SplitWordBolt(),2).setNumTasks(4)
